Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Supabase to Clerk to Better Auth

blog.val.town

Post reply on HN
Print view View original

121–130 of 259 posts

Re: From Supabase to Clerk to Better Auth

#121

Post by SkyPuncher »

jarym wrote: post #65
SkyPuncher wrote: post #52

Earlier quoted context omitted.

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.

"home built auth system" is bound to have "random SSO issues". You fix them, that's how things mature.

Yep, it’s just a drag. It’s not our core product value so any effort we put into it is a drag.

Re: From Supabase to Clerk to Better Auth

#122

Post by jdwyah »

cyberax wrote: post #4

> Some important context is that Clerk is a major success. They just raised 50 million dollars and they have lots of satisfied users. And even more users who are looking to escape. Clerk is just a mess. They are trying to cram EVERYTHING into their libraries: Web3 crap, Stripe, etc. Clerk's JS blob is now triggering the browser inspectors for being slow to load. Every time when we upgraded React, Clerk libraries were…

Man, glad I chose WorkOS instead. I’ve been a happy camper there but have wondered about Clerk bc it felt hotter. Turns out hot isn’t always good.

Re: From Supabase to Clerk to Better Auth

#123

Post by small_scombrus »

_heimdall wrote: post #119

I'm surprised to see so many top comments here promoting building your own auth. For years I've only heard "never roll your own auth."

There are few hard and fast rules, but "never use something that could change as a primary key" and "never roll your own Auth" will always be true

Re: From Supabase to Clerk to Better Auth

#125

Post by sally_glance »

manishsharan wrote: post #57

Has anyone used Keycloak for actual production? I have often thought about it but I stick to Auth0 just because I don't know if Keycloak has a good track record?

I've seen it used in production by larger orgs. The scale where you plan for around 6 months of migration, customization and integration of your legacy zoo with 7 different user account DBs. On one hand, all of these projects were successful and now run it in production. On the other, they all really needed the 6 months to whip it into shape.

Edit: Meaning I would use it if you need to get up and running quickly, but it's a solid foundation to build on long-term.

Re: From Supabase to Clerk to Better Auth

#126

Post by DimmieMan »

_heimdall wrote: post #119

I'm surprised to see so many top comments here promoting building your own auth. For years I've only heard "never roll your own auth."

I think it's a correction, There's multiple levels of interpretation:

1. Don't roll your own crypto

2. Don't roll your own auth strategy

3. Don't Roll your own auth code

4. Don't host your own auth infrastructure.

For the last few years level 4 has been aggressively pushed with a lot of advertising spend to push people towards prohibitively expensive hosted providers. Donning a tinfoil hat for a moment, auth as a service companies have made everything seem substantially more difficult than it is too for simple needs.

Now we're seeing a correction back to 2 and 3 as people way up the risks of SaaS vs just using a easier to manage local library and discovering it's not as scary as it's been made out to be if you follow now fairly well established patterns.

the providers aren't going anywhere, people still need them for a variety of reasons but their time as the default is ending and whether this is good is to be determined.

Re: From Supabase to Clerk to Better Auth

#127

Post by [deleted] »

mvkel wrote: post #37
tornikeo wrote: post #35

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

Start any greenfield project, hand-coded auth takes up 50% of the development time of the entire MVP

[deleted]

Re: From Supabase to Clerk to Better Auth

#128

Post by JSR_FDED »

So let me be the one to invite ridicule and scorn by admitting I wrote my own auth code. It was fiddly and boring at the same time. It also wasn’t rocket science, and it works well. I’ll be the first to admit that there are cases where this is a bad idea, I’m just responding to the chants of never roll your own auth.

Knowing every single line of code involved allowed me to add some location-based functionality for one client, provide tailored logging to meet the needs of another client, and my favorite was winning a deal against much bigger competitors by being able to integrate with an absolutely ancient legacy system.

Just like “Goto considered harmful”, DRY, YAGNI, etc - they’re great at making you slow down and think. But they’re not inviolable.

Re: From Supabase to Clerk to Better Auth

#129

Post by f3408fh »

jarek83 wrote: post #70
tornikeo wrote: post #35

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

I must as intelligent as you because I also never understood why things like supabase even exist. I believe this shows how much front-end dev world is detached from how things can simple and secure by default.

Yeah you’re a bit confused. Supabase has nothing to do with frontend other than providing SDKs and some frontend components to integrate with their backend.

Re: From Supabase to Clerk to Better Auth

#130

Post by ipnon »

JSR_FDED wrote: post #128

So let me be the one to invite ridicule and scorn by admitting I wrote my own auth code. It was fiddly and boring at the same time. It also wasn’t rocket science, and it works well. I’ll be the first to admit that there are cases where this is a bad idea, I’m just responding to the chants of never roll your own auth. Knowing every single line of code involved allowed me to add some location-based functionality for on…

It’s not that crazy! Or hard. If you can store a hashed password in your users table, and keep the salt secret, you have working auth.
Post reply on HN