Stateless Websocket Client about surrealdb.js HOT 7 CLOSED

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 / ...?

from surrealdb.js.

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...)

from surrealdb.js.

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!

from surrealdb.js.

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

from surrealdb.js.

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

from surrealdb.js.

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)

from surrealdb.js.

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

from surrealdb.js.