[holler]

DRF has been around a long time at this point, and that's been a common stack (albeit with other frontend frameworks 10 years ago).

In recent times I'm a fan of Starlette, which is what the popular FastAPI lib is built on top of, and created by same author as DRF.

[ggregoire]

I used to make my APIs with Starlette/FastAPI, didn't know it was the same author!

Nowadays I just use PostgREST for all my new APIs. It's a phenomenal piece of software, save me so much time.

[darkteflon]

Are there any footguns to be aware of when integrating PostgREST with an existing “low-JS” Django project, do you know? I’m considering it for headless access to an existing Django-ORM managed Postgres instance by a data orchestrator (i.e., not for the web UI). I’d like to be able to keep using Django auth in particular and just wondering if there’s any risk of impedance mismatch (in which case I’ll probably go with django-ninja).

[ggregoire]

Doesn't seem impossible to make it work with Django, but I doubt you can reuse Django Auth.

PostgREST uses the roles and privileges of PostgreSQL to verify if a request is allowed. So, while you can indeed add a PostgREST on top of the schemas generated by Django ORM, you would still have to manually create those roles, grant them some privileges and them assign those roles to your existing users (I'm not familiar with Django but, I guess, that would mean adding a field "role" to the Django model, applying the migration and then manually filling the column "role" in DB with the role you wanna give to each user). And then you would need a login endpoint that returns a JWT token containing the role assigned to this user, and then use this JWT token for all your requests. That's how auth and permissions work in PostgREST and it's one of the big benefits of using it IMO.

Also, I personally like to make views and expose those views to the PostgREST API, instead of exposing directly the tables. But exposing the tables generated by Django ORM would work too.