Fast?

[bugproof]

Fast?

[lane711]

One of my early POCs had over a million records and it was still screaming fast. Not sure when I'll get time to dig into this but its on my list.

FWIW - I am using SonicJs for a production project. One table has about 6k records and the queries against it that return 20 records at a time take about 240ms so it looks like there may be an issue specifically with the demo.

[lane711]

You're right, something going on with the demo. Will look into this asap. Thanks for bringing this up

[Giggiux]

I'm writing to say that I'm very interested in understanding why the demo seems slow, whether it's a scalability issue of D1/KV or an external one. As I'm a massive fan of Cloudflare's stack, I was wondering whether to use SonicJS or not, but if it doesn't scale well, I cannot use it for my specific use case 🤔

[osseonews]

I think that one of the things that slows down this application, and I believe will certainly break it at scale, is that in your server.ts you have an app.use(*) that passes every single API request to the initializeLucia. This means that even API endpoints that are publicly accessible, e.g. posts, have to go thru Lucia. Lucia is very database intensive (checks the session on every request), and this is not good for D1, or any SQLite database for that matter, for some use cases.

In my opinion, Lucia is great for the admin routes and for the API's that are not accessible, because these will most likely not have a huge amount of requests (depends on number of users of course, but I imagine there is always only a handful of users accessing the CMS for 99% of companies. But, to pass publicly accessible routes thru here is asking for issues because of the amount of requests and subsequent useless database reads to D1 that a publicly available API will potentially receive (even at a small scale).

I think a better approach here would be to ONLY pass the admin routes and private API routes, e.g. /users/ thru Lucia. For the publicly available routes, like posts, you should not pass them thru Lucia. What you would do is verify a JWT token that is passed as a bearer. This is the approach used by every major company nowadays, e.g. Shopify. So the way to do it is simple: create an admin route that will generate a JWT based on an ENV secret and some payload (eventually you can attach access rights to this token also). In the admin dashboard create a simple form that will generate this. Then this "public" JWT can be copied to any third-party app and must be sent as a bearer in the header to a publicly accessible route Then for every publicly accessible route, just verity this JWT before showing data. This will provide a good level of security.

[lane711]

@osseonews You may very well be correct, thanks for your input. If that is what is happening we need to cache those reads or as you mentioned, eliminate them if possible.

We do have multiple use cases to cover in terms of access control, but we still need that functionality to be highly performance and scalable
https://sonicjs.com/access-control

[osseonews]

Yeah, the access control is an amazing feature, but for publicly accessible routes I think it will be overkill, unless it's a create/edit route. So I guess the logic should be first determine if something is "read: true", if not then obviously do all the auth work, if it is "read:true", but not a create/edit, then just pass it thru without going thru Lucia. For edits/create, obviously you need to pass thru auth. Anyway, I think it would just be easier to create JWT's for auth. It's how something like Supabase works, and nobody has any issues with it. Lucia is good for getting the initial authentication, but I think JWT is better for ongoing auth, especially for public endpoing.