Stateless Websocket Client

[adileo]

Right now each client created through this SDK is opening a stateful websocket connection to SurrealDb where you need to login or switch the namespace/db before performing any operation.

await db.signin({...})
await db.use('test', 'test');

This works well in a situation where the connection is created from multiple devices, or you need real-time data, but seems to add a bit of overhead in a backend server situation (eg. API) where you need to handle multiple concurrent connections across different users, namespaces or databases. Each combination will require a new client to be opened, cached and closed server side, resulting in a lot of overhead. Essentially a single server will have hundreds, if not thusands, of websocket connections opened to the same SurrealDb instance.
Maybe this could be solved by allowing to override the user/namespace/db on each specific SQL request.

Right now I'm working around this by creating a custom Typescript SDK based on the REST interface of Surrealdb, but wanted to be sure that I'm not missing something here or if it is already possible with the current websocket connection.

Thanks

[mathe42]

The overhead is smaller than you think (if you use http2).

The connection is reused with http2 so you have only 1 connection to your server! But you are right if you have 1000 or more connections that is bad.

Solution: Use only 1 db-user in your backend server! (And therefore 1 connection)

Also why don't connect directly to surrealdb by your app / webpage / ...?

[adileo]

Thanks for your promptly reply, really appreciated :)

I've thought about using one connection only, but then I have to call the method await db.use('namespace123', 'db123') each time before handling an API request to switch between different dbs or namespaces, as far as I've seen there is a message submission through websocket to SurrealDb to switch the Namespace and DB each time, so it doesn't seem 100% efficient.

Since I'm building a multi-tenant app some parts of the app are in common (eg. users, billing, etc..) while other are namespaced on the tenant side, hence the requirement of having the APIs to perform operations across namespaces/users on multiple incoming API requests without opening a lot of connections.

I'm not connecting directly from the frontend mainly for 3 reasons:

• Server side rendering for authenticated users
• Public facing REST API (therefore the requirement to have a middleware between the client, 3rd party code, and the DB)
• I prefer to have a middleware between the client and the DB also for flexibility purposes (monitoring, extensibility, complex authorization checks, etc...)

[mathe42]

If you change ns + db yes that will not be optimal....

Would something like surrealdb/surrealdb#247 help you?

For your last point:

1. monitoring -> just add a reverseproxy infront of surrealdb that can log / monitor stuff
2. complex authorization checks -> I could not think of a use case that surrealdb can not handle... The permissons syntax is not well documented but powerfull!

[adileo]

It seems an interesting feature. Great insights for point 1 and 2, of course the documentation doesn't help a lot but by looking at the code it's seems a very promising project.

At the end I ended up creating my SDK ORM library:
https://github.com/adileo/surrealdb-ts-client

[martinschaer]

I think this is still an open issue. A stateless connection would be useful when deploying a Next.js app to Vercel. I'm working on a next-auth adapter for SurrealDB and it's not working on stateless cloud functions. I need just a few and very specific queries, so I'll do the fetches myself.

This ORM provides stateless connection for SurrealDB: https://github.com/StarlaneStudios/cirql

[martinschaer]

Hi @kearfy @tobiemh 👋 Could we reconsider this? In some scenarios its required a stateless connection to surreal from nodejs (like with next-auth on vercel nextauthjs/next-auth#6251). The current official nodejs driver only supports websockets.

A good example is cirql (https://cirql.starlane.studio/docs/guide/stateless)

[kearfy]

Heya, I'm refactoring the whole socket bit of the library in #95 and also changing things up so we can have a sort-of interchangable class for WS and HTTP (the methods are different of course, so it will never be entirely the same, oh well)
Anyways, will also be adding an HTTP class in there to allow this kind of stuff