deno vs. js library

[oberbeck]

Hi, I just came across the Deno, NodeJS and the JS repository. Do you think it is really necessary to maintain three separate code bases? I would suggest to create a basic TypeScript version with abstract external dependencies. What do you think?

Here is just one example how both repositories are already facing the same issues and are being maintained with redundant issues:
Deno: #4
JS: surrealdb/surrealdb.js#5

[mathe42]

I was not aware that there are 3! JS/TS-Libs (just thought Node, Deno) I think it is a good idea to combine them into a single codebase.

(I think the only code-change is how the web-socket is created)

So my suggestion would be to have a build script that generates the different versions (Browser, Node, Deno).

[oberbeck]

I am relatively new to SurrealDB so I am not sure if the client and server sides should be separate?

I come with a background in Firestore; there we have a client and an admin SDK. The admin SDK is more for server side usage with complete access to the DB. The client SDK is for direct front-end access secured through the user's auth and the DB rules.

[mathe42]

You could do that but you don't have to... My opinion is 1 Client for all. That is less to maintain...

[oberbeck]

Fair.

So the goal is to have a basic TypeScript setup which builds into

• Deno/TypeScript
• JavaScript + Typings

How to deal with external dependencies?
So far we are talking about nanoid and ws.

Ideas:

• remove external dependencies all together to be as lean as possible?
• pack dependencies into builds
• abstract dependencies pointing to specific package managers

[mathe42]

nanoId can be replaced by some simple Code. The id don't have to be crypto-random pseudo-random should be fine...

For ws that is the node websocket extension there is no way to remove it. For that we need a buildtool-solution. But with rollup (Not so familiar with webpack) this would be quite simple. (So don't overthink that for now)

[Chooks22]

• remove external dependencies all together to be as lean as possible?

nanoid would be easy enough to remove, we don't even need pseudo-random a simple incrementing id should be enough.
ws though, would need a special case for node.

• pack dependencies into builds

If this means publishing modules so that the dependencies are inlined in one file, I would advice against it.
It would be worse dx for devs to debug a single massive file, not to mention harder for other bundlers to optimize.

• abstract dependencies pointing to specific package managers

Putting nanoid aside, would it be possible for external deno modules to use import maps? If so it would be easy to point isomorphic-ws to a file containing export default WebSocket, then node/browsers wouldn't need other workarounds.

[mathe42]

@Choooks22 Agree for nanoid. I don't think we need any other dependencies.

With that in mind why do we need a Browser and a Deno build? I think that could be the same build. So with typescript in https://github.com/surrealdb/surrealdb.js we would have the following files (have currently other names but you get the idea):

./dist/browser.js
./dist/browser.d.ts
./dist/node.js
./dist/node.d.ts

And then we could simply add a
./dist/deno.ts with:

// @deno-types='./dist/browser.d.ts'
export * from './dist/browser.js'

On top of the 3 builds (deno, browser, node) we can then build platformspecific caching etc. if needed.

[mathe42]

Additional information:

1. https://github.com/surrealdb/surrealdb.node is currently empty
2. With https://github.com/surrealdb/surrealdb.js/blob/main/webpack.config.js the other implementation has already solved the problem with ws and Websocket

[oberbeck]

(Disclaimer: I have to admit, I am not experienced with deno; but more with "classic" Node/Web projects.)

Why don't we just create a deps.ts file like described here: https://medium.com/deno-the-complete-reference/dependency-management-in-deno-48f1c91ad84d

Then we could have 4 of these files that are simply switched on build.
deps.ts --> abstract implementation all files use
deps.node.ts --> used as deps.ts for node builds
deps.deno.ts --> used as deps.ts for deno builds
deps.web.ts --> used as deps.ts for web builds

edit: ok, so that's basically what's being done here: https://github.com/surrealdb/surrealdb.js/tree/main/src/websocket
So I think I'm going to look into adding deno to this setup

edit: as deno supports WebAssembly out of the box, there might actually be no need for a deno connector all together, no?

[Chooks22]

I got a working node/deno/browser repo by essentially making the repo deno compatible, then just inserting an import WebSocket from 'isomorphic-ws' at build time using rollup for node/browser.

[oberbeck]

I got a working node/deno/browser repo by essentially making the repo deno compatible, then just inserting an import WebSocket from 'isomorphic-ws' at build time using rollup for node/browser.

cool, I think I have just done something similar, just without the need for isomorphic-ws.

I have added a deno build to the js repo ie. simply replacing the websocket import with demos native WebSocket class.

[oberbeck]

Would suggest to start on a basic test setup for all three environments to assure everything is still working as expected, what do you think?

[Chooks22]

Would suggest to start on a basic test setup for all three environments to assure everything is still working as expected, what do you think?

With the amount of issues this discussion is related to, kinda hard without a solid base yet, since solving this would be the solid base.

Related issues/pr namely:

• TypeScript issues
  • Constructor interface. #3
  • javascript surrealdb.js#1
  • feat: add types to (nearly) everything #4
  • Start converting js to ts surrealdb.js#5
• Build issues
  • Vite falling back to node ws (doesn't exist) on client side surrealdb.js#11
  • Eliminate the need for nanoid module surrealdb.js#12

[mathe42]

We have 3 Targets Deno, Browser, Node and for Node 2 potential formats (cjs, esm).

With nanoid removed the only depenencie is ws. I like the idea with the dep.[target].ts file. That would be future prove. The selection of the correct file would be down to a rollup or webpack build. I will start with my implementation (#4) and propose a setup with the 3 targets...

[mathe42]

I created a working example in #6.

Please have a look!

[mathe42]

Before I invest more time into it I would like to here some feedback from a surrealdb Team-Member so I don't waste time...