> Flask has a stigma for not being that good when building larger apps
Not sure how to quantify that "large" but I've worked on some api backend services written in Flask with a quarter million lines of python code and not feeling "outgrowing" Flask. Granted, it took some good design and effort to make all piece s work together. These days, horizontally scale apps is the way to go.
In my experience, Django is less suitable for large projects than Flask.
The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations, business logic and the interface layer.
This is manageable in the small, but when you hit scale, this tight coupling adds a whole bunch of unnecessary complexity to your system. Good luck trying to tune your database when any template can trigger hundreds of db calls!
Django is great for building Django apps. That is, if you're starting a greenfield project and don't have to integration with an existing database schema, and you like the Django ORM, and you like Django templates, and your data model maps cleanly onto a relational DB, and you can use the admin site more or less as-is without having to customize much, then it's lovely! I'm not being sarcastic: it really is. We've successfully rolled out several CRUD apps so that our internal employees can tweak settings and update stuff without waiting for engineering to get around to it.
That said, I'd rather gnaw off my own ankle than develop a production, customer-facing website that breaks any of the preconditions I listed above. Every time I've needed to deviate from the Django Way of doing things, it's felt like I'm swimming upstream against a rapids. For those kinds of projects, I love Flask very, very much.
You can use what you need and replace the rest. Or use Flask or something else. I'm not arguing for one or the other, but just mentioning that you don't need all of those mentioned conditions for Django.
This is a false statement that Django is unsuitable for large projects. I have been working on a fairly large Django Project for 5 years now and it has been a pleasure using Django to build good and stable features that actually scale.
> The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations, business logic and the interface layer.
It totally depends how your architect your application and how you write code.
Any framework you choose, you need to write good code, keep an eye on db operations, enable caching where it is required and you will survive the scale just fine. All the arguments are exactly same in the favor of slack.
Do not spread the FUD that using a framework can magically make your application scale. I have seen very bad and very good code in both Django and flask. If you want your application to scale, you need to carefully work on it there is no silver bullet.
If you want something similar to Flask component wise that scales well and allows for nice structuring patterns try Pyramid (https://trypyramid.com/). It it is really well thought out framework, you can use it to build single file applications if you want but it really shines when you use Pyramids mechanisms that allow for extending applications and their composition.
That being said when you are careful you can probably end up with reasonably structured applications in either Django, Pyramid or Flask.
Newly released version of PyPi is built in Pyramid.
I was about to post something similar, but this nicely summarizes my feelings. Even with DRF (for REST APIs) the extreme coupling at all layers makes things painful, though it's possible to reduce that pain a little with some carefully enforced rules.
(I would like to see a way of disabling QuerySet traversing, so that if you try to access something that you didn't already prefetch_related/select_related then you just hit an error (and therefore fix it before you go live). The behaviour of just happily issuing hundreds of DB queries in a single request really hides a bunch of architectural and performance issues.)
That said, as the sibling comment says, if you need a simple- to moderate-complexity, mostly CRUD API, and particularly if you need it fast, then Django is a great tool.
I've worked on a couple codebases approaching that a few hundred k. But at that point we've usually done major refactor, usually resulting in a codebase with a level of magnitude less lines.
I'm not saying exceeding 500k lines is impossible, but it seems like a very large system for a well written codebase with low duplicity. I would love to see what the codebase looks like for such a system written with Flask.
There are a lot of different types of software being made in python.
I've managed to do python for 10 years only working on one codebase that size, and I'm not sure it counts - it was made by low skilled devs (we were encouraged not to do anything "clever", like use the language features) mostly cutting and pasting existing code.
You've got to love companies that have the don't be "clever" attitude... Whats the point of hiring skilled workers to just dumb them down. I've stopped counting the companies that openly stated, "we don't pay you to think," only to see them stuck in an endless loop of mediocrity.
Our policy is to avoid cleverness - think "code golf" - that is going to be opaque and hard to reason about at 2AM when things are on fire. We don't shy away from language features, but if you have a PR with multiply-nested generator expressions, for instance, someone will usually ask you to unroll that into a set of explicit loops.
Not sure how to quantify that "large" but I've worked on some api backend services written in Flask with a quarter million lines of python code and not feeling "outgrowing" Flask. Granted, it took some good design and effort to make all piece s work together. These days, horizontally scale apps is the way to go.