As a long time python dev, I’m now not certain why I would use python for a web app, over typescript on Next, other than familiarity. Sharing types between the server and client, and only having to manage _one_ software ecosystem is great.
1. The data layer, if you want a high-quality ORM and migrations
SQLAlchemy + Alembic (or Django ORM + its built-in migrations) are battle-tested systems that I trust will scale to large teams and not break my data.
If you're more of the persuasion to write raw SQL, or to just use a SQL query builder, Python is less of a draw these days (although SQLAlchemy's query builder is quite nice and can be used independent of its ORM).
2. Ties to the data science + machine learning universe
If your back-end intersects with these in ways that are not cleanly separable into services, Python might be a good (or the only) option. Even if you can cleanly separate, you're effectively committed to managing Python on the back-end.
3. Stability
For good and ill, the JavaScript ecosystem churns far more rapidly.
4. Familiarity
To your point: there's nothing wrong about optimizing for creature comforts and/or velocity from just having done it before and fired the foot-guns.
---
I agree that using a single language provides an advantage at the API boundary. Curiously, my experience is that most modern javascript frameworks (like NextJS) don't have a lot to say about how to structure this in practice. Maybe that's fine, but I'd love to see some opinions emerge in the ecosystem.
Amongst other things, I typically want to:
- Share types (typescript `interface`s, etc.) between the front-end and back-end (while avoiding accidentally bundling back-end code into the front)
- Have run-time types (via `zod`, `io-ts`, whatever) for (at minimum) API request structures so I can validate my inputs
- Have a story about how API validation failures are shipped back to the client (and how the client exposes them to the users, e.g. error messages when filling out form fields)
- Differentiate between API types and my underlying data model (the `User` in my database is somewhat to very different from the `APIUser` I ship to my client)
In the python universe, Django, Flask, and FastAPI all have well developed opinions about run-time types, validation failures, and API types vs. data models.
Most of the queries I've done using Django can be optimized at the application code level to be fast and efficient without even touching SQL. There were a few instances at the two Django shops I've worked where we optimized one or two queries by writing raw SQL, but the number of times I've seen that in a codebase can be counted on one hand.
The SQL/stored proc method, on the other hand, doesn't come with any way to do migrations or version your database by default (AFAIK). So now you have to write migration code and come up with some kind of versioning system by hand.
Wish I had more experience with SQLAlchemy/Alembic. I've tried using it on little things here and there but since I've always known Django, that's what I usually go with.