I agree with the comments saying you should use React. I always come back to it and never regret using it.
That said, there are some time killers you might not be anticipating up front (and this is true of basically whatever framework you use).
You will jump right past a ton of frustration and fatigue by using a starter template such as create-react-app, next.js's starter script, or remix.run's starter script. This saves you from so much config boilerplate, it's absolutely insane.
It's good to decide how the frontend and backend will communicate early on, which will inform the "starter template" decision. For example, if you know you need your API to be written in Go, it makes sense to use create-react-app in anticipation of a client-side only codebase. If you don't need an external API and would prefer to have a node server tightly integrated with your frontend code (which can be an enormous time saver) with all the bells and whistles (SSR, static rendering), next.js or remix would be appropriate. Of course, you can still choose to have a node server coupled with your app even if you plan to use an external API if you want things like SSR.
And keep in mind that even if you do use an external API, cookie-based authentication works just fine if the backend supports it (as with Django Rest Framework).
I typically end up using Django as a backend for the sane migrations, built-in auth, and extensible admin. I find the JavaScript ecosystem in general to be _fucking terrible_ when it comes to managing databases (though there is some ongoing work in this space), and I haven't found a real competitor to Django's auth or admin for early productivity literally anywhere.
Mull these things over for a while before you write any real code.
Prisma and NextAuth.js are first class modern Typescript replacements for Django’s ORM and auth respectively. Django’s only competitive advantage is its Admin and common convention.
Prisma is pretty good, but the migrations system doesn't really compare. If your answer to many (any?) migrations is "blow away the existing database", that's not gonna work for me. Another thing that's not gonna work for me is generating each migration by hand with SQL specific to the dialect that youre using in development, now that I'm spoiled with Django's auto-migrations. I've had good success with Prisma by using Django to simply manage the schema and using `prisma pull db` (though Prisma unfortunately errors if you are using the default type for primary keys, AutoBigInteger because it can't handle BigNumber). Prisma is basically the ORM I had in mind when I said "there has been work in this space", FYI.
I have only used NextAuth a tiny bit, but it wasn't clear to me how to, for example, extend the user model to add fields to users. I would appreciate it if you have any resources you could point me to for an example or explanation on how to achieve that. I also did not find documentation about how to add my own authentication adapter (or plugin or whatever language they use).
How does your random link to a Prisma schema relate to next-auth? Did that come from next-auth documentation?
Cool, how do I make a provider? That's pretty anemic documentation. I feel literally 0% more informed about the process. Obviously I could go through the fucking source code to find out how custom oauth providers were implemented!
But I don't care about oauth 99% of the time! What I actually want is username/password login with session cookies. How do I do that?
> The Credentials provider allows you to handle signing in with arbitrary credentials, such as a username and password, domain, or two factor authentication or hardware device (e.g. YubiKey U2F / FIDO).
> It is intended to support use cases where you have an existing system you need to authenticate users against.
What if I want session cookies instead of JWT? And there's no default schema (which is because it has no baked in ORM or database management, to be fair), so I have to go through the boilerplate of defining it in in every new project. And I'll have to figure out how to do permission based access and groups. This is all table stakes, for me. Next Auth isn't actually taking care of any of the hard parts of my use case.
It just doesn't have the bare minimum that I need it to have to be a suitable replacement.
That said, there are some time killers you might not be anticipating up front (and this is true of basically whatever framework you use).
You will jump right past a ton of frustration and fatigue by using a starter template such as create-react-app, next.js's starter script, or remix.run's starter script. This saves you from so much config boilerplate, it's absolutely insane.
It's good to decide how the frontend and backend will communicate early on, which will inform the "starter template" decision. For example, if you know you need your API to be written in Go, it makes sense to use create-react-app in anticipation of a client-side only codebase. If you don't need an external API and would prefer to have a node server tightly integrated with your frontend code (which can be an enormous time saver) with all the bells and whistles (SSR, static rendering), next.js or remix would be appropriate. Of course, you can still choose to have a node server coupled with your app even if you plan to use an external API if you want things like SSR.
And keep in mind that even if you do use an external API, cookie-based authentication works just fine if the backend supports it (as with Django Rest Framework).
I typically end up using Django as a backend for the sane migrations, built-in auth, and extensible admin. I find the JavaScript ecosystem in general to be _fucking terrible_ when it comes to managing databases (though there is some ongoing work in this space), and I haven't found a real competitor to Django's auth or admin for early productivity literally anywhere.
Mull these things over for a while before you write any real code.