2 ms·

I see some of the same problems in Django; it's so productive at first, the ecosystem is great, DevX is delightful, and when your app is simple enough that a la

I see some of the same problems in Django; it's so productive at first, the ecosystem is great, DevX is delightful, and when your app is simple enough that a layered architecture feels like way too much boilerplate, you can just write amazing simple code. A great example is Simon Wilson's recent post https://til.simonwillison.net/django/building-a-blog-in-django https://til.simonwillison.net/django/building-a-blog-in-djan... - the views.py is :chefs-kiss:. However when you get to multiple teams and multiple 100s of kloc, the architectural demands start to get stronger, and Django can become a bit hard to work with. If you have a shallow wide domain, then it's not really a problem; just stick to fat models with controllers, and everything is OK, you just add more models. But when your domain is deep, with layers of concepts, and lots of interaction between different subsets of models, you start to want to pull out an Application Layer to wrap your Domain Layer. Tactically it also starts to be really hard to guarantee you're not doing O(N) queries, and I've found django-seal to be a great solution (seal a QuerySet after fetching so you can't accidentally do follow-up queries, forcing you to build everything into a single query with select_related/prefetch_related). However when you look at how complex the implementation of the *_related caching is, you start to wonder if a simpler, more flexible ORM like SQLAlchemy would serve you better. I think "how many loc is your app" would be a helpful qualifier for these discussions, as I suspect lots of people waving the "I love Rails" flag are writing smaller apps, and the "I won't use Rails again" are working on 1m loc projects. Right tool for the job, both opinions can be valid at the same time when qualified with "... for apps of size ~X".

1letterunixname 3y ago
Instagram's backend is (mostly) a single, giant Django app. So it is possible to put together massive apps in it. I didn't have the time to delve into the architecture. What I find lacking in most MVC backend frameworks lack is the componentization and composition of business rules in and across individual models. dry-rb and trailblazer were good efforts in this direction, but the reality is most backend apps in production stay mired in low-level implementation effort and duplicated code with whatever the MVC framework provides. Also, the presenter pattern tends to require a bolting on in most frameworks.
- theptip 3y ago
  It’s certainly possible, but is it a good idea? Would be interested in general sentiment from those working in that codebase. (Though FB uses Hack so I think there is a general tendency at Meta to scale whatever happens to have been used to build the first version, rather than decompose and rewrite some pieces.) IG’s Django must be pretty weird since the ORM will be driving Tao/Ent, rather than a normal SQL database? I wonder what the code looks like.
- bbrmaley 3y ago
  they ditched orm in favor of own implementation years ago
postpawl 3y ago
“simpler, more flexible ORM like SQLAlchemy would serve you better” SQLAlchemy is way more complex and does more stuff (more robust connection pooling for example). There are a lot more complex things you can do with prefetching related rows with SQLAlchemy (there’s like 5+ different ways to do it?). You’ve actually used sql alchemy for a project? It’s great, I just wouldn’t describe it as simpler.
- theptip 3y ago
  Yeah perhaps “simple” isn’t the right way of putting it, the learning curve is way worse. Maybe “less opinionated” is what I’m getting at; it has smaller, more composable building blocks and while the ORM API surface itself is in some sense more complex, it doesn’t have the kitchen sink of ActiveRecord integration that Django does. It seems to me that when you pick an implementation, you perhaps have a little more boilerplate than Django, and then the slice of the SQLAlchemy API you end up using is smaller and more explicit. So the app’s usage of the ORM ends up being simpler (even though you might have to write a little bit of framework code yourself). (Yes, I’ve used both, Django more though.)

1letterunixname 3y ago

Instagram's backend is (mostly) a single, giant Django app. So it is possible to put together massive apps in it. I didn't have the time to delve into the architecture. What I find lacking in most MVC backend frameworks lack is the componentization and composition of business rules in and across individual models. dry-rb and trailblazer were good efforts in this direction, but the reality is most backend apps in production stay mired in low-level implementation effort and duplicated code with whatever the MVC framework provides. Also, the presenter pattern tends to require a bolting on in most frameworks.

theptip 3y ago
It’s certainly possible, but is it a good idea? Would be interested in general sentiment from those working in that codebase. (Though FB uses Hack so I think there is a general tendency at Meta to scale whatever happens to have been used to build the first version, rather than decompose and rewrite some pieces.) IG’s Django must be pretty weird since the ORM will be driving Tao/Ent, rather than a normal SQL database? I wonder what the code looks like.
bbrmaley 3y ago
they ditched orm in favor of own implementation years ago

postpawl 3y ago

“simpler, more flexible ORM like SQLAlchemy would serve you better” SQLAlchemy is way more complex and does more stuff (more robust connection pooling for example). There are a lot more complex things you can do with prefetching related rows with SQLAlchemy (there’s like 5+ different ways to do it?). You’ve actually used sql alchemy for a project? It’s great, I just wouldn’t describe it as simpler.

theptip 3y ago
Yeah perhaps “simple” isn’t the right way of putting it, the learning curve is way worse. Maybe “less opinionated” is what I’m getting at; it has smaller, more composable building blocks and while the ORM API surface itself is in some sense more complex, it doesn’t have the kitchen sink of ActiveRecord integration that Django does. It seems to me that when you pick an implementation, you perhaps have a little more boilerplate than Django, and then the slice of the SQLAlchemy API you end up using is smaller and more explicit. So the app’s usage of the ORM ends up being simpler (even though you might have to write a little bit of framework code yourself). (Yes, I’ve used both, Django more though.)