I've been developing with Django since the 0.90 days and, to be honest, I've seen a lot of scalability issues with Django itself once you get big enough.
Those issues all relate to how Django is an all-in-one solution with a lot of modules, which you start dropping one by one as you use different solutions.
For example, Django's cache layer is great, but as you scale you'll want to use Redis clients directly rather than the memcached abstraction.
The ORM is fantastic (and much more intuitive than SQLAlchemy). But as you scale, you'll want to use Postgres' more powerful features without worrying about compatibility with MySQL / SQLite. (Django has made progress in that area with contrib.postgres, but it's still only scratching the surface)
Forms? Templates? Staticfiles? If you're using a JS (Webpack and the like) frontend, forget about this stuff. You're better off not serving the frontend with Django at all, it'll only cause more trouble than is worth.
URL routing... again, nowadays even that is done in Javascript. And doing it in two places at the same time is a pain. Long term, you might drop that too.
What's left? The model layer, and the admin that accompanies it. I wouldn't trade the Django admin for the world but it also has a lot of scalability issues and although it's very declaratively customizable, it's much harder to customize specific models.
The auth layer is also probably something you'll keep for a long time, but it's littered with things you will probably not use such as the whole groups/permissions system, or the adminlogs auditing system (which is super cool but the API is very hard to use outside the Admin).
The problem with Flask is it's missing in the "what's left" parts. And if you use Flask, you're missing out on the entire Django ecosystem of apps that make heavy use of the model layer.
But you dear reader statistically will most likely not hit any of these scalability issues (aside from the frontend ones). So don't feel bad picking Django, it's an excellent framework regardless.
> ORM is fantastic (and much more intuitive than SQLAlchemy)
Any articles or blog posts you can recommend to give some examples or comparison?
> entire Django ecosystem of apps that make heavy use of the model layer.
Exactly why I don't want to use the django system. I'm happy with the python ecosystem and have yet to find a django only module where no other alternative exist.
Its not that django is a bad web framework; on the contrary, to be honest. I'm just already invested in other modules that django decided to re-invent/design to fit their needs better.
> Any articles or blog posts you can recommend to give some examples or comparison?
Not really sorry, it's all personal experience.
> I'm happy with the python ecosystem and have yet to find a django only module where no other alternative exist.
What about all the cases where you need support from database schemas? For example let's say you want to have access to Stripe subscriptions from Python and cache them to your database, you'll need something like dj-stripe. There's nothing "in Python" other than an API client because the Python stdlib doesn't have a model ORM.
> For example let's say you want to have access to Stripe subscriptions from Python
I will use the official stripe flask checkout example[0].
> and cache them to your database, you'll need something like dj-stripe. There's nothing "in Python" other than an API client because the Python stdlib doesn't have a model ORM.
With their OpenAPI definitions[1] to create the needed sqla model boilerplate, which creates the needed pgsql tables. For change log of my models it is kept in my py model files and xml with sql diff using a cheat where I implemented a Liquibase python wrapper[3].
I'm lucky where I work in a not to enterprise env so self-rolled solutions is sometimes acceptable and we try to keep it sane.
> I will use the official stripe flask checkout example[0]. [...] to create the needed sqla model boilerplate, which creates the needed pgsql tables
Ok, so let's say someone else wants to apply this pattern (it's extremely common after all). Should they do the same thing as you did?
Should the next guy as well? Where does it stop? At some point, you write a library right?
Well that library will end up containing the ORM models. So your choice ends up being between "I will roll my own models" (whether they're autogen'd from openapi or not doesn't matter) and "I will use someone else's models". You're back at exactly the same point as earlier, none of this actually achieved anything, other than give you extra work.
The point I was trying to originally make is that saying you'll do it "in pure Python" instead of "in Django" doesn't actually work. If by "Python" you mean "SQLAlchemy" that makes more sense.
At the end of the day, I wish the Django ORM were ripped out of Django so we could have libraries that depend on Django's ORM without them depending on the entire Django stack. There's also a lot of demand for the other side of this, which is having Django's ORM be replaceable by SQLAlchemy. Then you're no longer talking about "Django vs Flask", but "djangorm vs sqlalchemy".
The final step after this would be to have the Django ORM support SQLAlchemy's model declarations. The Django and SQLA model declarations are already very similar. Then we live in a world where you can swap out the ORM API at the application layer, but have libraries that are compatible with both and don't need to be reimplemented for both Django and SQLAlchemy. (I strongly believe the distinction between the two model APIs is not useful right now due to how similar they are)
Normally a flask-ext forms around a established python library. Yes now we are back at the tight integration problem, but at-least your knowledge of the py library will not be lost in another eco-system.
> I wish the Django ORM were ripped out of Django so we could have libraries that depend on Django's ORM without them depending on the entire Django stack... Django ORM support SQLAlchemy's model declarations... Then we live in a world where you can swap out the ORM API at the application layer, but have libraries that are compatible with both and don't need to be reimplemented for both Django and SQLAlchemy.
Those issues all relate to how Django is an all-in-one solution with a lot of modules, which you start dropping one by one as you use different solutions.
For example, Django's cache layer is great, but as you scale you'll want to use Redis clients directly rather than the memcached abstraction.
The ORM is fantastic (and much more intuitive than SQLAlchemy). But as you scale, you'll want to use Postgres' more powerful features without worrying about compatibility with MySQL / SQLite. (Django has made progress in that area with contrib.postgres, but it's still only scratching the surface)
Forms? Templates? Staticfiles? If you're using a JS (Webpack and the like) frontend, forget about this stuff. You're better off not serving the frontend with Django at all, it'll only cause more trouble than is worth.
URL routing... again, nowadays even that is done in Javascript. And doing it in two places at the same time is a pain. Long term, you might drop that too.
What's left? The model layer, and the admin that accompanies it. I wouldn't trade the Django admin for the world but it also has a lot of scalability issues and although it's very declaratively customizable, it's much harder to customize specific models.
The auth layer is also probably something you'll keep for a long time, but it's littered with things you will probably not use such as the whole groups/permissions system, or the adminlogs auditing system (which is super cool but the API is very hard to use outside the Admin).
The problem with Flask is it's missing in the "what's left" parts. And if you use Flask, you're missing out on the entire Django ecosystem of apps that make heavy use of the model layer.
But you dear reader statistically will most likely not hit any of these scalability issues (aside from the frontend ones). So don't feel bad picking Django, it's an excellent framework regardless.