5 ms·

For context I'm someone who spent nearly 20 years doing almost exclusively python dev, attended the first DjangoCon in 2008, ran the Django community blog durin

by clint 4y ago

For context I'm someone who spent nearly 20 years doing almost exclusively python dev, attended the first DjangoCon in 2008, ran the Django community blog during its formation heyday back in the mid 2000's and built tons of Django modules, apps, sites etc, have commits on the Project from way-back, tech edited Django books, etc... Did rails for a short while in 2010-2012 and absolutely hated it then spent 2012-2020 doing mostly Python/Flask dev for huge fintech companies on AWS. I now use Javascript/React/Nextjs on Firebase/Google Cloud. So much less hassle, tons more libraries and what seems like an exponentially larger ecosystem. There's still weird shit with transpiling typescript to javascript etc... but overall I enjoy JS dev much more these days.

christiangenco 4y ago
I had a similar journey but with Rails and ended up in a similar place. React+Nextjs on Firebase makes the deployment and scaling steps so much easier than on Rails. I'm very conscious of the platform risk of depending so much on Firebase but gosh darn it they've spoiled me.
alexalx666 4y ago
Be aware that firebase or aws are only good until you have actual traffic. So in many cases you just loose time you spent understanding their managed infra. I would advice to go with Linode. As a bonus you get to lean new techs that are not tied to crazy managed pricing :)
- afgrant 4y ago
  I would be interested in hearing of any instance where Firebase costs created financial hardship.
- moneywoes 4y ago
  Any tutorials for handling next js and a private server ( like linode)
- uncommonGeo 4y ago
  If the traffic to your app is generating a significant Firebase bill then you have probably moved from MVP to successful app territory. Would you rather start managing more infra or focus on keep building features that add value to the app?
squidsoup 4y ago
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

by clint 4y ago

christiangenco 4y ago

I had a similar journey but with Rails and ended up in a similar place. React+Nextjs on Firebase makes the deployment and scaling steps so much easier than on Rails. I'm very conscious of the platform risk of depending so much on Firebase but gosh darn it they've spoiled me.

alexalx666 4y ago

Be aware that firebase or aws are only good until you have actual traffic. So in many cases you just loose time you spent understanding their managed infra. I would advice to go with Linode. As a bonus you get to lean new techs that are not tied to crazy managed pricing :)

afgrant 4y ago
I would be interested in hearing of any instance where Firebase costs created financial hardship.
moneywoes 4y ago
Any tutorials for handling next js and a private server ( like linode)
uncommonGeo 4y ago
If the traffic to your app is generating a significant Firebase bill then you have probably moved from MVP to successful app territory. Would you rather start managing more infra or focus on keep building features that add value to the app?

squidsoup 4y ago

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