7 ms·

Flask has a stigma for not being that good when building larger apps, but honestly Flask scales really well for that type of use case (coming from a development

by nickjj 9y ago

Flask has a stigma for not being that good when building larger apps, but honestly Flask scales really well for that type of use case (coming from a development / maintenance point of view). I have some pretty large Flask apps with dozens of top level dependencies and models spanning across many thousands of lines of code. Even if I don't touch the code base for a few months, it's easy to jump back into it. I'm also a huge fan of Rails, but truthfully I find Flask apps to be easier to reason about and hack on once they grow to a decent size, simply because Blueprints make it really straight forward and intuitive to modularize your application without increasing the complexity of everything by using micro-services. If anyone wants to jump into Flask and start building real world apps, you may want to check out https://buildasaasappwithflask.com/ https://buildasaasappwithflask.com/. It's a full blown course where we build a SAAS application using Flask and Docker. I recently added a free RESTful API bonus section to the course and now that Flask 1.0 out, I'll be adding another free update which will cover updating all of the packages in the main app. Just going to wait for the dust to settle on the 1.0 release first.

devy 9y ago
> 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.
- hultner 9y ago
  That sounds like a helleva large codebase, especially for Python. What did the application do? How large was the dev team?
  - ageofwant 9y ago
    I have worked on several Python code bases exceeding 500k lines. Not sure why you think that's uncommon.
    - stuaxo 9y ago
      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.
      - ekovarski 9y ago
        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.
        hultner 9y ago
        A company that doesn't pay it's engineers to think is surely doomed from achieving any significant innovation. Doesn't seem like viable strategy at all, I'd run the other way if I were approach by such a company.
        kstrauser 9y ago
        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.
    - hultner 9y ago
      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.
- yen223 9y ago
  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!
  - kstrauser 9y ago
    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.
    - cabalamat 9y ago
      > 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. I agree -- if you use Django, you have to do it the Django way. Flask is more flexible.
    - JoshMnem 9y ago
      You don't need Django's ORM, templates, and admin section to build a Django app. Check out this example of a single-file Django project: https://www.safaribooksonline.com/library/view/lightweight-django/9781491946275/ch01.html https://www.safaribooksonline.com/library/view/lightweight-d... It's from a good book called Lightweight Django.
nicodjimenez 9y ago
Flask _does_ scale really well with lines of codes. However the limitations of Python w.r.t. async log really start to show once you step beyond simple CRUD apps.
- Rapzid 9y ago
  This was my experience. Just exited a startup that relied on Python heavily. Built a flask-restful based back end with SQL Alchemy.. Never had any issues with flask per say, but it made me happy I know languages with far better tooling and concurrency experience/performance :)
  - chucky_z 9y ago
    Did you ever attempt to use PyPy? Flask works with it, and in my experience the handful of times I've needed Python to be more performant, PyPy got me there easily. My use-case was I was doing a heavy part of an ETL pipeline out of MySQL and it was taking an unreasonable amount of time. PyPy was a roughly ~8x speedup, which ended up being faster than doing direct manipulation with MySQL via the cli (!!!).
    - oneweekwonder 9y ago
      For interest sake, can SQLAlchemy run on PyPy; pgsql driver support? thanks,
      - sirn 9y ago
        SQLAlchemy can run on PyPy, but you have to use pg8000 (pure Python) or psycopg2cffi (cffi port) instead of psycopg2 for pg.
      - fermigier 9y ago
        I haven't used it in production (only made some benchmarks), but the recommended approach is to use the pg8000 driver (https://github.com/mfenniak/pg8000 https://github.com/mfenniak/pg8000) with pypy, instead of psycopg.
kamac 9y ago
This reference to buildasaasappwithflask.com deserves a disclaimer (I assume you're the author - the initials match)
- grzm 9y ago
  The sentences immediately following the URL makes it pretty clear the commenter's relationship with the site: > "It's a full blown course where we build a SAAS application using Flask and Docker. I recently added a free RESTful API bonus section to the course and now that Flask 1.0 out, I'll be adding another free update which will cover updating all of the packages in the main app."
  - kamac 9y ago
    I'm sorry, it's been a long day and I apparently can't read anymore.
kstrauser 9y ago
> Flask has a stigma for not being that good when building larger apps I've never heard that before. It's been the go-to backend server at the last few companies I've worked for, and it's the first Python web framework I reach for when I need to roll out a new service. I think its explicitness is hugely wonderful for maintenance: given a route, it's straightforward to figure out exactly what code is being called.
- iampims 9y ago
  I think its explicitness is hugely wonderful for maintenance I find all the magic really off-putting in Flask…
  - abhishekjha 9y ago
    I thought what the parent comment meant was that there's little to no magic in Flask compared to some macro-framework like Django/Spring. Can you get any more explicit than Flask and still be called a framework, without hitting the socket levels?
    - aserafini 9y ago
      There's a bit of magic in Flask - the global object is an example.
      - mianos 9y ago
        This one trips up every podcast host and blogger. It is not a global object, it just pretends to be with some wrapper magic. Like an attribute method it is not a simple variable.
        jononor 9y ago
        Which is even more magic... I don't get why the request and context isn't just passed as parameters. Explicit is better than implicit!
coldtea 9y ago
>Flask has a stigma for not being that good when building larger apps If it has such a stigma, I've never heard or read about it.
_diyu 9y ago
I think that's more because Flask is a micro web framework whereas Rails is a macro web framework. Sinatra, Express, and Compojure are micro frameworks in the same vein as Flask, and they encourage simplicity of mental model over batteries-included comprehensiveness of features that you find in Rails, Sails, and Django. In general I prefer some kind of a middle ground but I don't think there's middle-ground frameworks actually out there, I think you have to kind of build on top of Flask/Sinatra/Express by throwing some-batteries-included libraries on top of them to get there. But yeah I also find it easier to reason about than having a whole lot of convention-over-configuration rules memorized.
- pbreit 9y ago
  It's bizarre there are few or no offerings in that elusive middle ground. Rails & Django seems a little heavy. Flask & Express a little lite. I've never written an app that did not need user management, sessions, admin, db access, form processing, views/templating. Web2py is the best I've found (python).
  - girvo 9y ago
    This is one of the reasons I liked Silex back when I was a PHP dev. It’s a simple micro framework, but built on the same underlying components as Symfony, so porting libraries from one to the other is simple. Add a tiny bit of structure to take the guesswork out of how to lay out your app (or module — it’s very easy to load one Silex app into another), and it nicely meets that “in between” you’re talking about! https://github.com/studionone/flint/blob/master/README.md https://github.com/studionone/flint/blob/master/README.md
  - Cyph0n 9y ago
    In the Python world, Pyramid seems to fit the bill of a middle-ground framework.
  - oneweekwonder 9y ago
    Will the needs not be satisfied with flask ext, approved or not[0]? For example: user management, sessions, admin(flask-admin), db access(SQLAlchemy), form processing(wtforms), views/templating(jinja). [0]: http://flask.pocoo.org/extensions/ http://flask.pocoo.org/extensions/
abhishekjha 9y ago
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 9y 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.
procinct 9y ago
How do other users of Flask handle async calls to third party APIs? I use celery which works okay but it still feels quite clunky.
- oneweekwonder 9y ago
  Both the solutions I use is mq and py based: mqttwarn[0] and celery. What feels clunky about celery? The third party broker? Bunch of "magic" code you feel can be simpler as a couple of pika modules? While I like pika it needs a bunch of boiler plate[1] where celery is just multi-broker batteries included solution... which might feel a bit clunky. I see a lot of zmq solutions in the wild. But I'm happy with my current setup. [0]: https://github.com/jpmens/mqttwarn https://github.com/jpmens/mqttwarn [1]: https://github.com/pika/pika/blob/master/examples/asynchronous_publisher_example.py https://github.com/pika/pika/blob/master/examples/asynchrono...

by nickjj 9y ago

devy 9y ago

> 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.

hultner 9y ago
That sounds like a helleva large codebase, especially for Python. What did the application do? How large was the dev team?
- ageofwant 9y ago
  I have worked on several Python code bases exceeding 500k lines. Not sure why you think that's uncommon.
  - stuaxo 9y ago
    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.
    - ekovarski 9y ago
      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.
      - hultner 9y ago
        A company that doesn't pay it's engineers to think is surely doomed from achieving any significant innovation. Doesn't seem like viable strategy at all, I'd run the other way if I were approach by such a company.
      - kstrauser 9y ago
        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.
  - hultner 9y ago
    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.
yen223 9y ago
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!
- kstrauser 9y ago
  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.
  - cabalamat 9y ago
    > 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. I agree -- if you use Django, you have to do it the Django way. Flask is more flexible.
  - JoshMnem 9y ago
    You don't need Django's ORM, templates, and admin section to build a Django app. Check out this example of a single-file Django project: https://www.safaribooksonline.com/library/view/lightweight-django/9781491946275/ch01.html https://www.safaribooksonline.com/library/view/lightweight-d... It's from a good book called Lightweight Django.

nicodjimenez 9y ago

Flask _does_ scale really well with lines of codes. However the limitations of Python w.r.t. async log really start to show once you step beyond simple CRUD apps.

Rapzid 9y ago
This was my experience. Just exited a startup that relied on Python heavily. Built a flask-restful based back end with SQL Alchemy.. Never had any issues with flask per say, but it made me happy I know languages with far better tooling and concurrency experience/performance :)
- chucky_z 9y ago
  Did you ever attempt to use PyPy? Flask works with it, and in my experience the handful of times I've needed Python to be more performant, PyPy got me there easily. My use-case was I was doing a heavy part of an ETL pipeline out of MySQL and it was taking an unreasonable amount of time. PyPy was a roughly ~8x speedup, which ended up being faster than doing direct manipulation with MySQL via the cli (!!!).
  - oneweekwonder 9y ago
    For interest sake, can SQLAlchemy run on PyPy; pgsql driver support? thanks,
    - sirn 9y ago
      SQLAlchemy can run on PyPy, but you have to use pg8000 (pure Python) or psycopg2cffi (cffi port) instead of psycopg2 for pg.
    - fermigier 9y ago
      I haven't used it in production (only made some benchmarks), but the recommended approach is to use the pg8000 driver (https://github.com/mfenniak/pg8000 https://github.com/mfenniak/pg8000) with pypy, instead of psycopg.

kamac 9y ago

This reference to buildasaasappwithflask.com deserves a disclaimer (I assume you're the author - the initials match)

grzm 9y ago
The sentences immediately following the URL makes it pretty clear the commenter's relationship with the site: > "It's a full blown course where we build a SAAS application using Flask and Docker. I recently added a free RESTful API bonus section to the course and now that Flask 1.0 out, I'll be adding another free update which will cover updating all of the packages in the main app."
- kamac 9y ago
  I'm sorry, it's been a long day and I apparently can't read anymore.

kstrauser 9y ago

> Flask has a stigma for not being that good when building larger apps I've never heard that before. It's been the go-to backend server at the last few companies I've worked for, and it's the first Python web framework I reach for when I need to roll out a new service. I think its explicitness is hugely wonderful for maintenance: given a route, it's straightforward to figure out exactly what code is being called.

iampims 9y ago
I think its explicitness is hugely wonderful for maintenance I find all the magic really off-putting in Flask…
- abhishekjha 9y ago
  I thought what the parent comment meant was that there's little to no magic in Flask compared to some macro-framework like Django/Spring. Can you get any more explicit than Flask and still be called a framework, without hitting the socket levels?
  - aserafini 9y ago
    There's a bit of magic in Flask - the global object is an example.
    - mianos 9y ago
      This one trips up every podcast host and blogger. It is not a global object, it just pretends to be with some wrapper magic. Like an attribute method it is not a simple variable.
      - jononor 9y ago
        Which is even more magic... I don't get why the request and context isn't just passed as parameters. Explicit is better than implicit!

coldtea 9y ago

>Flask has a stigma for not being that good when building larger apps If it has such a stigma, I've never heard or read about it.

_diyu 9y ago

I think that's more because Flask is a micro web framework whereas Rails is a macro web framework. Sinatra, Express, and Compojure are micro frameworks in the same vein as Flask, and they encourage simplicity of mental model over batteries-included comprehensiveness of features that you find in Rails, Sails, and Django. In general I prefer some kind of a middle ground but I don't think there's middle-ground frameworks actually out there, I think you have to kind of build on top of Flask/Sinatra/Express by throwing some-batteries-included libraries on top of them to get there. But yeah I also find it easier to reason about than having a whole lot of convention-over-configuration rules memorized.

pbreit 9y ago
It's bizarre there are few or no offerings in that elusive middle ground. Rails & Django seems a little heavy. Flask & Express a little lite. I've never written an app that did not need user management, sessions, admin, db access, form processing, views/templating. Web2py is the best I've found (python).
- girvo 9y ago
  This is one of the reasons I liked Silex back when I was a PHP dev. It’s a simple micro framework, but built on the same underlying components as Symfony, so porting libraries from one to the other is simple. Add a tiny bit of structure to take the guesswork out of how to lay out your app (or module — it’s very easy to load one Silex app into another), and it nicely meets that “in between” you’re talking about! https://github.com/studionone/flint/blob/master/README.md https://github.com/studionone/flint/blob/master/README.md
- Cyph0n 9y ago
  In the Python world, Pyramid seems to fit the bill of a middle-ground framework.
- oneweekwonder 9y ago
  Will the needs not be satisfied with flask ext, approved or not[0]? For example: user management, sessions, admin(flask-admin), db access(SQLAlchemy), form processing(wtforms), views/templating(jinja). [0]: http://flask.pocoo.org/extensions/ http://flask.pocoo.org/extensions/

abhishekjha 9y ago

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 9y 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.

procinct 9y ago

How do other users of Flask handle async calls to third party APIs? I use celery which works okay but it still feels quite clunky.

oneweekwonder 9y ago
Both the solutions I use is mq and py based: mqttwarn[0] and celery. What feels clunky about celery? The third party broker? Bunch of "magic" code you feel can be simpler as a couple of pika modules? While I like pika it needs a bunch of boiler plate[1] where celery is just multi-broker batteries included solution... which might feel a bit clunky. I see a lot of zmq solutions in the wild. But I'm happy with my current setup. [0]: https://github.com/jpmens/mqttwarn https://github.com/jpmens/mqttwarn [1]: https://github.com/pika/pika/blob/master/examples/asynchronous_publisher_example.py https://github.com/pika/pika/blob/master/examples/asynchrono...