[tomwojcik]

That doesn't make sense. Django-allauth is the standard for non-rest Auth flow, django-rest-auth and djoser for rest API Auth flow. Each implementation is tailored for a slightly different case.

There's a reason why only admin views are kind of built in and if you want you can expose admin to the end user and it supports the entire Auth flow out of the box.

[tomwojcik]

I can't seem to be able to edit from mobile, I'm actually not sure if you can create a user using /admin out of the box. Anyway, it's a MTVC framework. Views and templates are coupled, and Django provides a user registration form if you want. Of course no one uses that since big projects are using Django for its orm and only need the rest API. The 2 libs I mentioned above are easy to plug in, but they rely on drf, so in order to battery-include the feature you want, Django would have to merge with drf first.

[andrewstuart]

Batteries included means the stuff you need for most uses is already included.

The fact that there are many possible add ins to solve this doesn't address the fact that Django does not include core functionality for web applications.

[kurjam]

You mentioned running nodejs + typescript over extensive frameworks like django now. Curious if you chose to write your own framework or are you using something from nodejs space to do "batteries included" thing for you?

Asking because I've had some experience with nest.js and even though it's fun it often feels hackish and a bit messy even when solving standard issues like authorization that's not a simple app wide RBAC.

[andrewstuart]

I don't really know what is different.

I can say that nodejs and TypeScript and pure SQL is so simple and straightforward that I seem to need almost nothing in terms of "framework". I just write endpoints with a query behind them.

On reflection I spent alot of development time hacking around in Django models/forms and the ORM and really almost none of that is needed if you just write straight SQL with Postgres. It's just unnecessary complexity - once you cut all that guff out then things start to become REALLY simple. Request/auth/query/response.

I put auth into a separate web application which gets called by Caddy (or you coudl use Nginx) as an auth subrequest. This makes auth extremely easy, and gives a very powerful decoupling and separation of concerns.

For many years I have thought, finally, that's the last time I need to write a user signup/forgot password/signin flow, but every project still seems to need it written, so I do that myself.

This approach of super simple, just talking to Postgres also would work well with Python but I have come to really like TypeScript more than Python. The latest Python projects I wrote were pretty much Starlette with asynpg talking to Postgres and no ORM or other fluff - that's a pretty nice combination, and asyncpg is the fastest Postgres driver for Python by a country mile which is also nice.

If I wanted RBAC then I would intercept all my SQL queries and wrap them in Postgres RBAC environment variables that implement the Postgres constraints. I've done this before with Django, it worked pretty well, but I think it would be nicer and cleaner in a system without ORM or database abstraction of any form.

[__pache__]

I don't understand how what you're describing is batteries included where Django isn't?

It's typically not practical to solve "auth flows" in a centralized way -- needs are so different for different projects. There are tons of third party modules you can just plug in...

[andrewstuart]

My batteries included comment related to Django, nothing else.

[reducesuffering]

Personally, Next.js with NextAuth and Prisma for ORM is a much better full stack dev experience for me. Django templates are their own DSL, adding JS is more annoying and less powerful to do than React/JSX, Django Auth is cumbersome, Django Rest Framework will immediately feel like an old Java EE OOP way of doing REST or JSON API...