It's brave trying FastAPI if you haven't tried it before. Going async is going to be quite different and you need to be more careful when designing your API. Most people will never need it.

This is why most folks just needing a plain Python API without anything else, they usually go for Flask, which is vastly simpler. For a more complete web app or site, I would recommend Django.

Out of naive curiosity of considering your first stack vs. Django: What makes Django so way ahead of the curve?

The ORM is so so so much better designed that SQLAlchemy v2. Performing queries, joins, executing in transactions all feels clean and concise. The latter feels dated and I find it hard to believe there's not a widely accepted replacement yet.

In terms of views, route configuration and Django's class-based views are sorely missed when using FastAPI. The dependency pattern is janky and if you follow the recommended pattern of defining your routes in decorators it's not obvious where your URL structure is even coming from.

We could probably do with a "SQLAlchemy for Django users" article. SQLAlchemy is much more powerful and flexible than Django. After using SQLAlchemy it's hard to even consider an active record style ORM like Django an ORM at all. SQLAlchemy can truly map relational data onto objects and uses the unit of work pattern to coordinate updates. Django just feels like writing raw SQL but in nicer Python syntax. The details of relational models leak directly into the business logic and there isn't really much you can do about it. In short, SQLAlchemy is a different beast. If all you need is Django then you're probably only doing CRUD and you should just use Django.

The problem with sqla is that you need to deal with the session object all the time. Doing it right is not that easy, and never as concise.

SQLA is cleaner and more powerful, but when you just need CRUD, django wins.

Django definitely wins at CRUD because that's what it is. It calls itself a web framework but really it's a web-crud-app framework. Flask and Pyramid are web frameworks.

Dealing with the session object seems a small price to pay for the flexibility in architecture that it gets you.

Hmmm any specific syntax examples of pain points in Sqlalchemy? Having used both, they feel similar to me so I’d love your view!

`from sqlalchemy.orm import and_`

`options(selectinload(...))`

to name a couple goofy ones

Sqlalchemy definitely is more verbose.

django-ninja will give you a fastapi like experience without the hassle