Live data from Hacker News

From Supabase to Clerk to Better Auth

blog.val.town

51–60 of 259 posts

Re: From Supabase to Clerk to Better Auth

#51

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.

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

#52

Can 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

It’s just a few fields until it’s not.

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

#53

Earlier 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".

I strongly disagree. If you’re selling to other businesses, much of that is an expectation.

Re: From Supabase to Clerk to Better Auth

#54
post #19

Hey, 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?

Not who you're replying to but browsers do way too much. Load the code you're given and don't do anything else.

Re: From Supabase to Clerk to Better Auth

#55
post #5

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

I use better auth for a side project i'm working on. It's open source, you can pay them to manage your user/auth tables if you want or you can run it all on your own db.

Re: From Supabase to Clerk to Better Auth

#56

Earlier 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

Take this post down immediately ! /jk

Re: From Supabase to Clerk to Better Auth

#58
post #19

Hey, 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

Hey hey! Qq: you guys plan to support Python backends or is there a way for us to do this?

Re: From Supabase to Clerk to Better Auth

#59

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

> 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
post #42

> 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…

Learned this one the hard way during the last major CloudFlare outage. I don't use them, but their outage bricked my app for hours anyway because the Auth0 public keys used to verify JWTs were served behind CloudFlare, breaking the entire auth chain. Fun!
Post reply on HN