Earlier quoted context omitted.
It takes like an hour. So that's a quick mvp then
Social logins, email logins, password resets, multi-tenant, organizations, many to many users to organizations, etc etc. Not necessary for MVP, but can definitely be painful hacking in later if the MVP hits.
From Supabase to Clerk to Better Auth
51–60 of 259 posts
Re: From Supabase to Clerk to Better Auth
#52Can someone more intelligent then me tell me why should I offload my postgres users table to some 3rd party provider? Like what is so hard about keeping that table in my VM on hetzner that I have to give it off to someone else? It's not payments, it's just a few fields of data
SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec.
For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.
Re: From Supabase to Clerk to Better Auth
#53Earlier quoted context omitted.
Social logins, email logins, password resets, multi-tenant, organizations, many to many users to organizations, etc etc. Not necessary for MVP, but can definitely be painful hacking in later if the MVP hits.
By the time you're so big you need all of that, there will be other people at the table to "hack that in".
Re: From Supabase to Clerk to Better Auth
#54Hey, Bereket from Better Auth here. I started Better Auth to solve this exact issue for myself, and it later turned into a company. It always give me joy to just see others getting the same value from it :) There is a lot to work on, would love to know what we can improve
Do you think the complexity of auth in the browser, is because browsers don't do enough?
Re: From Supabase to Clerk to Better Auth
#55Earlier quoted context omitted.
Lol wut? you get all of your auth data in your own db in 1 cli command. You are not tied to any on db provider. On top of that you get hundreds of auth features like oauth providers (I use it to allow users to log in via google, apple, github) and the best part it's free. Not saying Supabase and Clerk are bad, but they cost money. With better auth you pay exactly $0 for all of this.
Or I could use a web framework that offers that out of the box, and its free and lives in my database, wherever I want.
Re: From Supabase to Clerk to Better Auth
#56Earlier quoted context omitted.
What framework offers all those auth features OOTB?
I remember Laravel with Socialite [0]. Laravel is what I usually reach for Web SaaS MVP. You only need a VPS and a managed database for testing out the market and can scale a lot without increasing expenses that much.. [0]: https://laravel.com/docs/13.x/socialite
Re: From Supabase to Clerk to Better Auth
#57Re: From Supabase to Clerk to Better Auth
#58Hey, Bereket from Better Auth here. I started Better Auth to solve this exact issue for myself, and it later turned into a company. It always give me joy to just see others getting the same value from it :) There is a lot to work on, would love to know what we can improve
Re: From Supabase to Clerk to Better Auth
#59Earlier quoted context omitted.
Why pay someone to build a house? I’m sure you could do it yourself…but that doesn’t mean that is the best use of your time in all cases. The analogy is basic but apt; not everyone needs or wants to run (or create) every mechanism. I don’t do all of my own hosting either and it’s not because I couldn’t, it’s that it isn’t worthwhile in my cases. To expand a bit more: if a business is faced with a choice to save some…
>that doesn’t mean it’s the best use of your time in all cases Okay, so… what are those cases? I’m also curious.
If you're willing to make a third party SaaS's uptime the ceiling for your own org, you can delegate auth. Github might not be a good choice for SSO.
If you're not threatened by per-user-per-month fees, you can delegate auth.
If your threat model is compatible with a third party having visibility into your user's network location and the frequency and duration of their activities across your org, you can delegate auth. (Okta will probably not inform your competitor that your main sales guy is in North Carolina this week and has logged in from the conference room wifi of your competitor's main client.)
If you can trust the third party to not allow an interloper to bypass your requirements, you can delegate auth.
Re: From Supabase to Clerk to Better Auth
#60> A hard lesson you learn building a complex system is that its reliability is the minimum of the combined reliability of its critical parts. It's worse than that, the combined availability is the product of all components in the critical path. If your software, the authentication layer, and the cloud provider each have 99% availability, and any one of them can bring your service down, then your final availability is…