Hey. I really like this library especially the pas...
# support-questions
m
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.
r
Hey @mamousavi 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.
m
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.
r
> 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.
n
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
m
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.
r
yes correct.
w
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
m
I can imagine. I'm deploying containers on a PaaS though.
Here's a suggestion: I think it's possible to rewrite all of the functionalities of the core as Postgres SQL functions that run directly in the database and eliminate the need for an additional service. Of course this would tie the SDK to Postgres but it isn't really a problem. Users still have full custody over their data.
r
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.
If you really want to eliminate the core for your specific use case, you can override all the recipe functions that talk to the core with your own logic that talks to your db.
m
> 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 * šŸ˜† .
r
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
So is the actual issue that we use Java vs gotrue using golang?
Also talking about webhooks, why donā€™t you like them?
m
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.
r
Hmm. Alright! Thanks for the feedback.
What are your thoughts on webhooks?
Why do you prefer ā€œwhole lib living in the backendā€ vs making webhook API?
Cause the webhooks also live on your backend
m
It's simpler. No need to create an endpoint.
r
And what are some issues with creating endpoints? Any specific reason or just extra cognitive load?
m
For me simplicity rules. But also my serverless platform bills by the request count. šŸ˜†
r
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?
m
Of course.
r
So itā€™s just simplicity then? Just not needing to create and manage extra APIs
m
That's the main point.
r
Gotcha
m
Thanks for the amazing support. Keep up the great work. šŸ˜‰
r
Thanks!