3 ms·

My employer made me switch from Flask to Django providing non-scalability reason. I asked around on a few online forums and they told me that flask has no such

My employer made me switch from Flask to Django providing non-scalability reason. I asked around on a few online forums and they told me that flask has no such issues. There was an article where somebody from DISQUS explained how they were able to use flask in production without much hassel and there's no reason to switch to django. My employer told me to not use flask as it is not production grade. The problem was to implement a few web APIs. I switched, reluctantly. I am still not convinced though, given that I have very recently started using Flask/Django, it may come to me at a later time.

scrollaway 8y ago
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.
- oneweekwonder 8y ago
  > 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.
  - scrollaway 8y ago
    > 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.
    - oneweekwonder 8y ago
      > 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. [0]: https://stripe.com/docs/checkout/flask https://stripe.com/docs/checkout/flask [1]: https://github.com/stripe/openapi https://github.com/stripe/openapi [3]: https://github.com/Morabaraba/python-liquibase https://github.com/Morabaraba/python-liquibase
amerille 8y ago
Disqus is built with Django, isn't it? I've always read that and I've seen articles about it last year. Or do they use a chimera between Django and Flask? It's easy to find Django's "csrfmiddlewaretoken" input hidden in some of their forms, such as the authentication ones.
mundanevoice 8y ago
This is sad. Flask is a very nice microframework that does not have any of these scalability limitations for which your employer asked you to switch to Django. I have used both Flask and Django for a long time, so I think I could contribute a couple of points in this regard. - Django with a very good documentation and batteries included helps to build a lot of functionality in less time without having to look anywhere else. In the same time, flask being a microframework, you need to look for the batteries yourself and it takes experience and knowledge to know which components to use and which to avoid. - None of these two frameworks will magically fix the scaling issues or are free to scaling issues.When you hit issues with scaling, you need to find the bottleneck and fix it. There is no other magic bullet here. I would suggest do not be religious about things and try both of them without any bias in your personal projects and then evaluate. Do not form an opinion without knowing something yourself.
papito 8y ago
Ah, "hit and run management"...

scrollaway 8y ago

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.

oneweekwonder 8y ago
> 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.
- scrollaway 8y ago
  > 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.
  - oneweekwonder 8y ago
    > 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. [0]: https://stripe.com/docs/checkout/flask https://stripe.com/docs/checkout/flask [1]: https://github.com/stripe/openapi https://github.com/stripe/openapi [3]: https://github.com/Morabaraba/python-liquibase https://github.com/Morabaraba/python-liquibase

amerille 8y ago

Disqus is built with Django, isn't it? I've always read that and I've seen articles about it last year. Or do they use a chimera between Django and Flask? It's easy to find Django's "csrfmiddlewaretoken" input hidden in some of their forms, such as the authentication ones.

mundanevoice 8y ago

This is sad. Flask is a very nice microframework that does not have any of these scalability limitations for which your employer asked you to switch to Django. I have used both Flask and Django for a long time, so I think I could contribute a couple of points in this regard. - Django with a very good documentation and batteries included helps to build a lot of functionality in less time without having to look anywhere else. In the same time, flask being a microframework, you need to look for the batteries yourself and it takes experience and knowledge to know which components to use and which to avoid. - None of these two frameworks will magically fix the scaling issues or are free to scaling issues.When you hit issues with scaling, you need to find the bottleneck and fix it. There is no other magic bullet here. I would suggest do not be religious about things and try both of them without any bias in your personal projects and then evaluate. Do not form an opinion without knowing something yourself.

papito 8y ago

Ah, "hit and run management"...