From Supabase to Clerk to Better Auth

zuzululu

what do you get from Better Auth btw? When I used it last year, I still found it lacking and it seemed to be run by one guy.

cyberax

> 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 the biggest pain with their transitive dependencies. We had issues with Stripe libraries with conflicting versions, etc. And forget about debugging it. The libraries are obfuscated, and the TS code is impenetrable mess of abstractions to support "isomorphic" code that can run transparently on the frontend and backend. And their platform itself is lacking important functionality, like freaking audit logs and versioning. Somebody (probably) accidentally changed a setting in their console, and we couldn't trace back when it happened or who did it. Edit: oh yeah, and don't forget their unreliability. I had to wake up on Sunday to deal with Clerk failing the API calls for token refreshes last week.

supermdguy

Better auth is great! I love how it's way more hackable than using a something like Clerk. We were able to add a plugin to allow auth via iframe postMessage (embedded in a CRM) and everything worked seamlessly.

wxw

I enjoyed the Supabase migration article from a while ago ( https://blog.val.town/blog/migrating-from-supabase ) as well. There's a shortage of good, honest writing on long-term engineering decisions, please keep up the blog!

kandros

Does Better Auth still have the weird design to be everything “request header based”? I remember running admin scripts and tests to be very hacky due to it cause if you skipped that plugins wouldn’t run

moomoo11

I've just stuck with Auth0 for years now. Easy to use and high reliability. Some of these other providers are not the best at reliability.

rbbydotdev

Tom's articles are always a good read. Anyone remember Auth0 and passportjs? The churn of auth services is never ending, but I suppose so are the standards.

cpursley

If you're in Elixir-land, I've put together a few packages to help migrating from Supabase (or other stacks): - https://github.com/agoodway/introspex (generate Ecto Schemas from postgres tables) - https://github.com/agoodway/pgrest (Supabase/PostgREST compatible query engine) I also found this helpful in the migration: https://github.com/supabase-community/supabase-ex Nothing for auth, I basically did a one-off script for that. Phoenix auth stuff that comes out of the box is great.

bekacru

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

WilcoKruijer

You could almost call the comparison between Clerk and Better Auth unfair. One is a service and one is a library, apples to oranges. Any third-party service integrated into a stack is a liability, libraries as well, but to a lesser degree. It’s about time for more services to be replaced by libraries. Better Auth really shows how to do that imo, it’s a library that integrates on the frontend, backend, and database. This is why it’s so good.

snide

This is why I'm so thankful I went with Lucia early. They sort of sunset their library and replaced it with documentation (and some small utilities) for how to manage and host authentication for yourself. It's always presented as some big, scary thing you can't manage yourself, but I found that taking the week to learn how security and basic salting works, I was able to feel more confident about how everything worked.

dakolli

The homepage of val.town says "Zapier for know-code engineers".. Is KNOW -code engineer a term?

melonpan7

If anything I feel like Clerk adoption is becoming the norm in recent years. I started using it about a year ago and found it to have troublesome reliability.

elAhmo

Using Clerk, quite unhappy with it. No proper RBAC (roles are tied to organizations, not stored on user itself, so you cannot have a concept of global admin or something like that, unless you use metadata for storing arbitrary key value paris), and more than once in the past weeks/months it had a downtime causing the whole app to fail. Would think twice before using it in the future.

tornikeo

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

BoppreH

> 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 just 97%. With eleven components like that you have zero nines of availability. That's why reducing components and going for reliable solutions is so important. I'm happy that the team took this path.

dzonga

in rails I just authentication-zero. no need for 3rd party provider.

manishsharan

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?

oncensher

Had a similar journey recently. Started with Stack Auth, found it unusable in production due to extremely hard rate limits and bad performance even when not rate limited. Switched to WorkOS AuthKit, which works much better and supports useful enterprise features. But inclined to BetterAuth for new projects. - Syncing external auth provider state with your user state is a bug center. It helps to keep as little state as possible in the auth provider, but there is still some. - Refreshing JWT access tokens every few minutes is another bug center and honestly there is no need to do this if you control your own auth. - WorkOS does not have a complete API. It is built on the assumption that you have one product per billing account and a fixed number of environments (staging, production, and they can give you another one if you ask support). You have to whitelist redirect and other URLs in the dashboard, and there doesn't seem to be an easy way for agents to do it. Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have. Sometimes it is inevitable, like for payments, or if you need specialized databases for performance reasons. But for auth there is really no good reason if good libraries are available. To people who say that using a service will help you get started faster, none of the problems I hit with auth services had to do with having high scale -- most of them hit before I even launched.

notbekacru

When is the Better Auth to WorkOS to Vanilla Auth post coming