5 ms·

I am bummed by this, basically sounds like they’re sunsetting future development into Auth.js. I tried Better Auth and it was not usable for what I wanted to d

I am bummed by this, basically sounds like they’re sunsetting future development into Auth.js. I tried Better Auth and it was not usable for what I wanted to do - I manage my own database schema and expose it through a permissioned GraphQL API. With Auth.js I just needed to implement a documented set of functions with specified input and output types, like creating users, storing tokens, etc. - however I wanted to - and then it all just worked with my own custom GraphQL API as the backend. But with Better Auth it’s all insanely general, where the data types are “whatever a particular plugin wants” meaning the any type in TypeScript; and the only thing you can do is delegate responsibility for design of database schemas and execution of data migrations to whatever plugin developers decide you need for the particular authentication methods you support. Way beyond the pale for an auth library in my opinion, I thought I was dumb and just didn’t understand the library but when I asked the community about it, they told me that’s by design - plugins determine their own data model. This isn’t a matter of me having a weird use case with the whole GraphQL thing, I can’t imagine anyone who takes their data modeling/security seriously would be fine with delegating that kind of control to plugin developers. (Yes I know you can make your own adapters, but the interface for that is literally “implement a general purpose SQL-like query executor” where the models that you’re querying/mutating are arbitrary strings - so basically no control over your schema. It literally just takes in a code: string value for eval’ing your migrations! Insane! [1]) When I saw the announcements before about Better Auth, emphasizing not that it was innovative nor technically good in any way, but instead focusing on the fact that its developer was self-taught and has only been coding for a few years [2], I tried to restrain myself from assuming anything about how it might be designed, especially since it seems everyone was hyping it up… but I’m not so confident my prejudices were totally wrong. I guess this is marginally better than the status quo where Auth.js was basically unmaintained and not being developed further at all. Which is to say, the state of open source auth libraries in JS is surprisingly poor. [1] https://github.com/better-auth/better-auth/blob/f6cbdcc84ee5d2971fdcc8b23ff7c174f88cf45b/packages/better-auth/src/types/adapter.ts#L28 https://github.com/better-auth/better-auth/blob/f6cbdcc84ee5... [2] https://techcrunch.com/2025/06/25/this-self-taught-ethiopian-dev-built-an-authentication-tool-and-got-into-yc/ https://techcrunch.com/2025/06/25/this-self-taught-ethiopian...

bekacru 1y ago
1. We won’t sunset Auth.js unless we’re confident that anyone currently using it can migrate to Better Auth without any issues, which is quite difficult right now. So we don’t expect to do that anytime soon and chances are we will never require everyone to migrate. 2. The features we offer through plugins don’t exist in NextAuth, so that shouldn’t be a problem. You can use the core library for almost all of NextAuth’s features, and we provide most plugins first-party. Of course, you can choose not to use a plugin, write your own, copy and modify one, or only use the first-party ones we provide. We handle the database so you can own your auth without writing the logic yourself. 3. Auth.js hasn’t been actively maintained for a while. Our main reason for bringing it under Better Auth was to avoid a sudden deprecation, as that would directly harm the open-source auth ecosystem by eroding trust. Something we’ve already seen happen on a smaller scale with Lucia Auth.
- presentation 1y ago
  I guess what I’m saying is that I think the part about delegating databases to Better Auth relegates it to being only useful for throwaway projects and companies with low quality technical vision, and there is no actively developed alternative that can do any better. Patches are better than nothing but I am disappointed with the state of auth in JS.
  - bekacru 1y ago
    NextAuth has supported delegating your db for years, companies like cal.com, deel.com and many others use that directly (not just for stateless jwt). I don’t really see the difference here, except that we handle more for you. And of course, If you don’t want to delegate your database, you can keep using NextAuth with stateless auth and we plan to add support for that as well. There are already many companies with lots of users and revenue using Better Auth from simple auth setups to organizations, billing and what not. If your question is more about whether we should allow database adapters to be written directly by developers (some people ask that) that’s just not realistic at the scale of what we handle. No one is realistically going to write hundreds of queries manually

bekacru 1y ago

1. We won’t sunset Auth.js unless we’re confident that anyone currently using it can migrate to Better Auth without any issues, which is quite difficult right now. So we don’t expect to do that anytime soon and chances are we will never require everyone to migrate. 2. The features we offer through plugins don’t exist in NextAuth, so that shouldn’t be a problem. You can use the core library for almost all of NextAuth’s features, and we provide most plugins first-party. Of course, you can choose not to use a plugin, write your own, copy and modify one, or only use the first-party ones we provide. We handle the database so you can own your auth without writing the logic yourself. 3. Auth.js hasn’t been actively maintained for a while. Our main reason for bringing it under Better Auth was to avoid a sudden deprecation, as that would directly harm the open-source auth ecosystem by eroding trust. Something we’ve already seen happen on a smaller scale with Lucia Auth.

presentation 1y ago
I guess what I’m saying is that I think the part about delegating databases to Better Auth relegates it to being only useful for throwaway projects and companies with low quality technical vision, and there is no actively developed alternative that can do any better. Patches are better than nothing but I am disappointed with the state of auth in JS.
- bekacru 1y ago
  NextAuth has supported delegating your db for years, companies like cal.com, deel.com and many others use that directly (not just for stateless jwt). I don’t really see the difference here, except that we handle more for you. And of course, If you don’t want to delegate your database, you can keep using NextAuth with stateless auth and we plan to add support for that as well. There are already many companies with lots of users and revenue using Better Auth from simple auth setups to organizations, billing and what not. If your question is more about whether we should allow database adapters to be written directly by developers (some people ask that) that’s just not realistic at the scale of what we handle. No one is realistically going to write hundreds of queries manually