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.

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.

Using a passwordless login from scratch (magic link + Google OAuth2, sessions stored in Postgres without an external auth vendor) gets us around that altogether. The fears about why one would avoid it are generally not justified. Deliverability is the only true problem. Address that, with a proper provider for transactions, and we’re in boring territory – which is the most delightful kind.

To move from Clerk to Better Auth is logical if the choice is between sovereignty and convenience. It’s the core problem that any group doesn’t want to confront right away: “How much of this am I truly willing to own?”

just beautiful. nothing to add, clap clap

In both cases you are buying into somebody else's solution. That complex framework is complex because the company behind it threw everything and the kitchen sink at it. You don't actually need most of what it needs. And that company makes money by adding more crap to it, via certification, training and consulting. It's complex by design. You can't just sit down and use it. You have to study it first. Become an expert in using it. If you've ever used Keycloak, Spring Security, or similarly convoluted solutions, you know what I'm talking about.

And then that walled garden thing (auth0 or whatever is in fashion these days) is super simple to use. Just do magic steps 1 2 and 3 and you are good to go. But don't deviate from the happy path! There is a happy path. Either you are a perfect match for it or you aren't.

The middle ground is realizing that a users table with a bcrypt encrypted password column and a few other bits and bobs isn't all that hard. Building some sane flows around resetting passwords, 2FA, emailing login links, etc. Easy.

You can actually vibe code most of this stuff these days. And I've done all this manually in the past as well. I've implemented SSO, Oauth (1 & 2), OpenID Connect, etc. I've implemented API call counting, rate limiting, 2FA, etc. I use some frameworks for most of the heavy lifting and dealing with hashing, JWTs, and all the rest. Most of the rest is just simple API plumbing. Most of these flows aren't all that complex. You need good tests and a good understanding of what the system is supposed to do. But that's a constant in this space. Trying to use somebody else's really complicated solution without that is not going to be easier, better, or faster.

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

The reason why it work for me is that it's finally a open-source solution that is on par or better with commercial. When I've selected Clerk originally the reason was that there wasn't open-source alternative, and I won't roll my own auth, I'm not suicidal. But now? I really don't see a single reason why I would pick Clerk, Auth0, Kinde, ...

Would think twice before using it in the future.

Anyone remember Auth0 and passportjs?

The churn of auth services is never ending, but I suppose so are the standards.

More like "its failures are the total of its critical components' failures" when you've got two nines on your least reliable component so most likely any critical component failure will be exclusive.

Be very very wary of any vendor selling something built on this Supabase + Clerk stack. That alone is a very strong indicator they do not understand basic security or data protection.

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.

no need for 3rd party provider.

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

Easy to use and high reliability. Some of these other providers are not the best at reliability.

Lastly - here's the law of mother nature:

Software funded by VCs will milk you and will milk you dry. Not now, not tomorrow maybe decade or two later when the hot potato being passed around reaches to the last party holding the bag that now needs its money back with all that others had their 10x returns already taken from them by soldng them at an inflated price to the last party holding the bag.

Clerk's pricing should be evidence enough.