Some potential reasons:
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.
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.