[pphysch]

I use Django at $DAYJOB for multiple projects and love it but definitely see its age. I would never migrate to something "slightly different" like this.

I have a different approach to "modernizing Django", which is to write a spiritual successor ORM from scratch, which is Postgres-only and be "closer to the metal" while maintaining a porcelain Python API. Sounds insane, but "just use Postgres" is real and it already has a number of killer features that aren't possible in (core) Django due to its complexity and commitment to a standard SQL abstraction.

[fud101]

interested in this approach. do you get task queues for free? what else?

[pphysch]

- a much more Pythonic control flow than Django: there's no big settings.py file that does a bunch of magic. "Management commands" are just regular python scripts that get executed within your apps context. Can run in Jupyter notebooks. Much less OOP and framework complexity overall.

- task queues via LISTEN; NOTIFY; SELECT FOR UPDATE;, which builds off the above. Your worker processes don't have to load the entire app, just the parts it needs.

- fully typed using the latest generic type support

- first class support for dropping to raw SQL, the ORM isn't trying to reinvent everything Postgres can do. Mostly waiting for PEP 750 before finishing this feature.

- even more JSON field support, including a subclass called "Attributes" that exposes declared keys as Python attributes. CHECK JSONschema support via a Postgres extension.

- RLS integration, including a "tenant" context manager so you can do `with transaction(tenant_id="foobar"):` and all queries run in the block will be constrained by what that tenant can access according to RLS policies defined on each model. Mainly a first line of defence, but adventurous devs could give tenants read-only SQL access to their tenant data (e.g. for an analytics service).

- a Model base class called "Entity" which uses UUIDv7 for PKs and implements many powerful features, like generic FKs, soft-deleting, changelogs

- model-level support for JSON de/ser, so you don't need a separate DRF

- not trying to reinvent a WSGI/ASGI web framework, instead it tries to integrate nicely with starlette or whatever with some session support.

- migrations, postgis, maybe bitemporal fields, and so on