8 ms·

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

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.

davepeck 4y ago
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.
- vonseel 4y ago
  On 1 - I've worked at startups using Django ORM and banking companies using MSSQL stored procs. I don't understand why anyone would ever go the stored proc/raw SQL way unless they absolutely needed the performance. And if you do need the performance, you can always dip down to that level from whatever ORM you are using. 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.
speakfreely 4y ago
What to you use for ORM/database migrations with Next.js apps?

davepeck 4y ago

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.

vonseel 4y ago
On 1 - I've worked at startups using Django ORM and banking companies using MSSQL stored procs. I don't understand why anyone would ever go the stored proc/raw SQL way unless they absolutely needed the performance. And if you do need the performance, you can always dip down to that level from whatever ORM you are using. 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.

speakfreely 4y ago

What to you use for ORM/database migrations with Next.js apps?