In any event I wasn’t saying all medical imaging is state of the art, I was saying it is another field where people prefer newer tech.
Downstream is getting better with items such as AI advancements and more sophisticated mechanisms to transfer data between systems both on-prem and cloud-based, however utilization of all of this tend to be stifled a ton by the standard issue of tech moving faster than policy. My frustration/disgruntlement is due to this issue more than anything.
Thanks for the insight and the reminder that my bubble of experience isn't the world - seriously.
Using Django with React is not as easy as a full-stack framework like Next.js. Modern tech stacks are now generally moving towards either full-stack JS frameworks like Next.js, Remix, Astro, etc and/or serverless with things like railway.app, fly.io, Cloudflare Workers, Deno Deploy, Supabase, neon.tech, etc.
Many features of "old school" frameworks are becoming redundant or are being replaced by options with better DX.
[0]: https://idom-docs.herokuapp.com/docs/index.html [1]: https://github.com/idom-team/django-idom
Is it this one?
https://djangopackages.org/grids/g/multi-tenancy/
I know there is a paid one.
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.
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. Familiarity
To your point: there's nothing wrong about optimizing for creature comforts and/or velocity from just having done it before.
---
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.
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.
I love Django. It's criminally underrated.
Side project if anyone's interested in peeping it: https://www.fpgajobs.com
I used to use Flask, but I changed over to Django at the end of 2022. Super happy I did. It wasn’t painless, but the benefits have been totally worth it.
Built in migrations. Can’t possibly overstate how much this has helped ease deployment. Most of the live debug and prod edits I had to do on the older app were due to db migrations not being shipped with the app.
A baked in ORM with lots of backend optimizations like pagination that keep your queries fast, plus convenience functions for model creation and retrieval (long live get_or_create)
There was a learning curve to all of this, and the complexity of all this in the tutorial scared me away at first, but having seen how the other half lives with Flask, where there are no guardrails for anything, I really appreciate having a framework that solves these kinds of challenges for me.
Ok, well, maybe there are some answers, but it’s always like “Install, configure, and integrate this third party plugin”. Ain’t nobody who’s side-hustlin’ got time for that.
I’ve gotten a handful of people hired through the site, though, and the thank you notes from them have definitely been the greatest reward. :)