Hey. I really like this library especially the passwordless recipe. One thing that doesn't quite make sense to me is that most auth solutions are implemented as a standalone API service which the frontend can directly talk to, but with ST you have to implement the endpoints using the backend sdk which is perfectly fine but that essentially renders the core useless. In theory you can just integrate all of the functionalities of the core directly into the backend sdk and completely get rid of an additional service.

Hey @Deleted User the endpoints are exposed via the backend SDKs as well. if you add the SuperTokens middlware to your app that we provide, it will expose those APIs for the frontend. Those APIs in turn talk to the core for operations that require a db. That being said, you can override all the functions of the recipe to talk to your own db if you want, and then you don't need the core - but as you would expect, this is quite a lot of work.

Thx. I was aware of the middleware and when I said implement i meant expose. As for the second point, are there any examples/reference that i can look into? Honestly I'd rather do some extra work than pay for additional db and service hosting.

> when I said implement i meant expose. What do you mean by expose? The middleware does that too. You can call those APIs from the frontend. > As for the second point, are there any examples/reference that i can look into? Well, no specific examples of this, but you can checkout https://supertokens.com/docs/passwordless/advanced-customizations/backend-functions-override/about > Honestly I'd rather do some extra work than pay for additional db and service. you can connect the core to your own db as well.

depending on your hosting situation, you could just add another schema to your current DB and hook supertokens into that schema, instead of its own DB

I checked it out but it seemed to me that the core is not only responsible for talking to db but some other functionalities like generating otp/magic link is also done by the core. As you said that'd be way too work.

yes correct.

I am selfhosting the core on the same machine with my backend and I use the same database for the core and my backend, all in a 5$/mo vps. Didnt come across any performance issues yet

I can imagine. I'm deploying containers on a PaaS though.

Hmmmm. But then the different backend SDKs would have to all repeat the queries. And we do want to support other dbs as well. Even mongodb in the future.

> But then the different backend SDKs would have to all repeat the queries. They wouldn't. Queries are written as a SQL function once and different SDKs can just call them. https://www.postgresql.org/docs/current/sql-createfunction.html > And we do want to support other dbs as well. That's the tradeoff. Postgres is a real beast though, Supabase has literally built a company with it. > you can override all the recipe functions that talk to the core with your own logic that talks to your db. That's possible for simple email password, but much harder for passwordless. I switched to GoTrue for now, but I really like this library since it lives almost entirely in your backend and needs no webhooks; Although the core is a real pain in the * 😆 .

Well, even with gotrue, you have to run a service, similar to how you run the core? And if you are using managed service of supabase, we also provide a managed service which runs the code for you

I've mentioned this before, gotrue is a standalone API service that the frontend can directly talk to. It's just that the current ST architecture doesn't make sense to me.

Hmm. Alright! Thanks for the feedback.

It's simpler. No need to create an endpoint.

And what are some issues with creating endpoints? Any specific reason or just extra cognitive load?

For me simplicity rules. But also my serverless platform bills by the request count. 😆

Hmm I see. But the relative cost of the number of webhook calls from auth server vs calls from your app’s frontend is very very low right?

Of course.

So it’s just simplicity then? Just not needing to create and manage extra APIs

That's the main point.

Gotcha

Thanks for the amazing support. Keep up the great work. 😉

Thanks!