31 ms·

Building Large Flask Apps in the Real World

358 points by shinryuu 11y ago

matt_wulfeck 11y ago
> Scaling in terms concurrent users also has little to do with the web framework and more to do with your understanding of load-balancing, caching, databases, etc. This is what it always come down to for me. I know that when we can get our app running efficiently with reasonable memory requirements on a single core, then scaling it is really just about launching processes and load balancing them. Scaling out boxes is always easier than scaling out code -- for better or worse. I'm not talking about load balancing servers mind you, but applications on any given host. Two layers of load balancing. When I'm comfortable with the resource requirements I launch as little or as many of the app in a predictable manner across any number of nodes. It's comforting to know that given X, Y core and ram, I can run N services.
condescendence 11y ago
Flask is just awesome, I've never messed with a framework that's made things so simple yet doesn't take away from functionality if you're looking to build more complex apps. Anyone looking to get into webscripting/webapps should definitely take a look at flask, its python based, good for prototyping or production apps and has tons of useful documentation.
- samstave 11y ago
  best tutorial starting points?
  - siquick 11y ago
    the bible: http://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world http://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-...
    - dewarrn1 11y ago
      Seconded — Miguel's blog is terrific! Major chunks of my (very simple) website's code bear a suspicious resemblance to his examples.
      - condescendence 11y ago
        I think many people's flask personal projects resemble his examples in some way ;) He covers just about everything a modern web app needs
    - agumonkey 11y ago
      The official docs http://flask.pocoo.org/docs/0.10/ http://flask.pocoo.org/docs/0.10/ are also very nice although not full featured and integrated as the mega tutorial.
    - deleted 11y ago
      [deleted]
jqm 11y ago
Falcon (http://falconframework.org/ http://falconframework.org/ mentioned at the bottom of the article) does look interesting. I've also had good experiences with bottle (http://bottlepy.org/docs/dev/index.html http://bottlepy.org/docs/dev/index.html) for building internal apps for companies. The limited amount of users means I don't have to worry much about scaling and bottle with Paste server works pretty nicely. Jinja2 templates can also be used with bottle which is a plus. It's also pretty easy to compile this setup into an executable so it can run off someone's Windows machine and no need for a separate server. This setup makes a really convenient internal-use app which is easy to send to end users for deployment.
- rahimnathwani 11y ago
  If you are bundling as a windows exe, where are you storing persistent state/data? (EDIT: fixed autocorrect exe->exercise)
  - jqm 11y ago
    Either interact with an external database... (an existing company db for instance...this is just a front end) or else use a sqlite file on the local machine for smaller stuff.
jorgecurio 11y ago
Don't be fooled by the "micro-framework" line. My experience of building SaaS on top of Flask is that you are going to have to reinvent the wheels for a lot of things. Flask is plagued with abandoned plugins from a cesspool of weekend contributors which you rely on for basic things such as authentication and ORM. Tough enough as it is with all the outdated documentation for each of the plugins you need. So my recommendation based on 2 years of working with Flask is don't fucking do it, unless your product doesn't extend beyond couple of HTTP endpoints served over uwsgi + nginx for your internal applications. I really wish I'd spent all that time I spent on Flask on Node.js, python was the wrong medium to distance myself from PHP frameworks. All in all, 4 years have passed since my search of alternatives to LAMP. And finally, it wasn't some open source framework or asynchronous javascript to save the day, it was Amazon Lambda + API Gateway. Gone are the need to spin up Vagrant, docker, mysql/postgresql. I just upload the specific script I want and bam. Npm modules and pip modules too. I've in the process of migrating to AWS and leaving Flask. Great initiative, ruined by abandonware plugins and modules, certainly not attractive to entice developers to build their own wheels. The biggest mistake you could do is basing speed and agility as basis for going with Flask. It is the complete opposite. I think using Laravel or even CodeIgniter will significantly cut development time. Regardless, I'm done with the whole server/client frameworks and have migrated to AWS without any servers to maintain or setup. There's even frameworks for "Serverless" architecture now which makes me shake my head.
- orf 11y ago
  Why not try Django? It's documentation is top notch, plenty of maintained plugins for everything you could need. Jumping on the lambda bandwagon seems pretty risky, and in any case how does it protect you against abandonware? To me it's a bit like saying "I don't like outdated python packages, so I'll switch to nginx instead of Apache!".
  - mhurron 11y ago
    > Why not try Django? They blame Python for issues they perceived with Flask, I doubt they're going to be too open to Django.
abledon 11y ago
If your interested in websockets for flask, Miguel Grinberg has a straightforward implementation: http://blog.miguelgrinberg.com/post/easy-websockets-with-flask-and-gevent http://blog.miguelgrinberg.com/post/easy-websockets-with-fla...
aidos 11y ago
> In the end you should be aiming to design your application to depend on Flask as little as possible. I'm 3 years in to a project where I've taken the approach of having my "app" as its own package. Flask is then a thin wrapper that instantiates the app and then exposes the views to talk to it. I handle validation / sessions / config etc within Flask. It's extremely flexible. I have some stuff that runs off as worker processes. No problem - the core is the same, the wrapper around it is different. I also have a boot.py that I can call so I'm working directly with the app in ipython (again, it's a wrapper that starts the app). I'm currently reworking the structure for capacity planning, which is mostly just a matter of splitting the Flask app into 2 apps for handling different parts of the work. Because my core app is decoupled from the web app it's all really easy to do.
- odonnellryan 11y ago
  Great points! I've worked with Flask for a while, as I've gotten to be a better developer. I used to have a lot of my logic in the application itself. Now, I ensure my logic lives in its own modules. Flask is really just either a way to serve my templates or API.
- voltagex_ 11y ago
  Maybe I'm just not thinking clearly today but how do you turn Flask into a wrapper? I thought you had to put enough logic in to a class that inherits from Flask to return views and such.
  - aidos 11y ago
    I think I need to explain a bit better. I have a few different layers. From the outside in: Flask/Web Deal with sessions, authentication, caching, templating, logging etc here. Fires up an instance of the App and keeps it around for the duration of the life of the Web instance. I actually have an API in here that looks like what you'd expect in most other web apps. It does the validation / error handling etc. In terms of manipluating the data, I'm not a total purist - the API is allowed to load up the SQLA models and make changes. If there's a more complex operation going on though, it will live inside the next layer down. App Deal with remote services / data models / db connection. I guess on the outside you might call this a "service layer". A surprisingly large amount of this is data persistance management. The model I use is to put the data access stuff just off to the side at the top level of the app. Nothing in here knows anything about things like web frameworks. This is important. In other places in the system, this same App is used by RQ (worker instances taking on work via a redis queue). There's another web app that uses it for administrative tasks. I can boot it up to work with it in ipython (I do this a lot). Oh, and I don't manage the db life-cycle here. Whichever layer sits above this determines when it's ok to commit transactions. If something goes wrong here we raise app specific expections - the layer above can handle those and relay them as appropriate. Core In the very core I have "pure" algorithmic stuff (for context - http://www.countfire.com http://www.countfire.com is effectively an image recognition app). Really this is just one component that the App happens to be using. If the App wants to talk to this, it needs to create the data structures that the core defines. At various borders I often have mappings from the objects in the current local world to versions for the created to talk to the layer below (ps I like namedtuples). It's a lot more complex than all this, each of these layers has more sub layers etc. And really, what I've called the Core is a sublayer of the App (in my case there's a well definied algorithmic chunk that I think of as the core so it's in its own package - it stands alone as its own library). There's no real way of knowing where you'll draw lines between the layers when you start but I have a few rules. Any bit of code should be given the bare minimum of data required to do its work. At borders map local data to data for the next layer. Make sure the stuff going into the current layer is really there because it needs to be there. Be a pragmatist - things will change, you'll pull stuff out into submodules. By following the other rules hopefully refactoring won't be too painful.
andrewstuart 11y ago
Bottle and Flask are similiar and a great place to learn and start your journey with Python web application development. It is pseudo-minimalist though, so either you must almost immediately start reinventing the wheel to build basic stuff that you will need (as a novice developer I started by writing my own sessions and cookie handler). The next realisation you'll come to is that all that stuff has already been written by someone else as addons. So you try that but eventually you'll find you are in so much pain from problems with integrating addons that you will realise that you would be best off with something that has all the basic functionality "batteries included". So then you'll try to find projects on github that have already baked together Flask plus all the plugins into a boilerplate project. Then you'll find that there's many ways to bake all that stuff together and start to wonder if maybe you're now using a framework. But the boilerplate Flask with addons integration doesn't feel like it has a really well thought out consistent overarching model. So you'll then look at full featured integrated frameworks like Django where it's all integrated according to an architectural vision (perfect or otherwise is a matter of opinion) and although you might mot like some of the components, at least its all built in. Flask still carries of cruft and mental model though, because it is from earlier days of web development when you built the front end in the back end using things like Jinja templates. And then one day you'll need to build just a simple REST API without all the bells and whistles needed in a web application. So you can then look at Falcon which is extremely minimalist for developer who know they don't want any extra web application stuff at all including things like back end UI generation with templates. It's a sharp knife because there's almost nothing in it, and never attempted to provide the features needed to build user oriented web applications, so it has a very small mental model to grasp. TLDR: Bottle and Flask are great for finding your feet in web development without being forced to learn too many concepts all at the same time. Django or Pyramid or something full featured for web application development Falcon for REST API development If you are willing to take on the cognitive load of going straight to your destination, I would recommend beginners start with Django or Pyramid or Falcon. If (and this is entirely reasonable) you need to get going in Python web development without being overwhelmed by the concepts, go to Bottle or Flask but move on as soon as you can. If you love Flask and have the skills and competence to craft your own architecture and carefully selected from a menu of addons that suit you and know how to whittle out unneeded functionality, then Flask is the right choice for you.
mattbillenstein 11y ago
+1 flask-classy -- feels a bit like the old pylons which was a very simple and powerful framework
- bunnybender 11y ago
  The original flask-classy extension hasn't seen updates in two years. This fork is currently active: https://github.com/teracyhq/flask-classy https://github.com/teracyhq/flask-classy
- ergo14 11y ago
  Well, If you liked pylons - pyramid with classes and matchparam based views will feel also very similar to you.
kunoo 11y ago
A bit off topic, but does anybody know why development looks stopped since 2013? http://flask.pocoo.org/docs/0.10/changelog/ http://flask.pocoo.org/docs/0.10/changelog/ I'm in the process of writing my first webapp, and thses days it's a bit strange seeing a popular framework not being updated (even if it's just for bugfixing) a few times a year.
- detaro 11y ago
  It hasn't stopped, there just hasn't been a release. Main issue seems to be that the next release was planned to be the magic "1.0" and that isn't finished. So while that is worked on, there haven't been new releases, because the current release works, and most bug fixes happened in dependencies (jinja, werkzeug). At least that was my takeaway from various github discussions about it.
- zanny 11y ago
  There are milestones for 0.11 and 1.0: https://github.com/mitsuhiko/flask/milestones/0.11 https://github.com/mitsuhiko/flask/milestones/0.11 https://github.com/mitsuhiko/flask/milestones/1.0 https://github.com/mitsuhiko/flask/milestones/1.0 None of the 0.11 blockers are substantial, and 1.0 is mostly about having updated documentation. It just requires someone to actually finish them.
- andrewstuart 11y ago
  It's a bit unclear how enthused Mitsuhiko remains about Python development. He is one of the greatest contributors to the Python community and undoubtedly one of the most impressive software developers on the Internet. He is very "Python 2" oriented though and I wonder if his enthusiasm for Python has waned because he could never get onboard the Python 3 thing with enthusiasm. To his credit he updated Flask early to Python 3 and he has written alot of other stuff, most of which I understand to be Python 3 compatible. As everyone here knows, it's hard to write software when you don't feel enthused about the programming language. He has been doing stuff with Rust in particular. Maybe there will be a "Rusty Flask" one day.
  - leejoramo 11y ago
nawitus 11y ago
How do you load balance a Flask application since it's single threaded? For optimal performance shouldn't there be a single Flask instance (process?) for each request being processed? What kind of load balancers are usually used with Flask and how do they decide to spawn new Flask instances? And why should Flask be used instead of asynchronous Tornado or Node.js?
- matthewowen 11y ago
  A common approach is to run Flask on uWSGI or gunicorn. You then put this behind nginx.
- fuhrysteve 11y ago
  You typically use something like uwsgi or gunicorn to serve requests, and it's uwsgi & gunicorn that decide how many processes or threads to start. These typically sit behind a load balancer and / or a reverse proxy. In terms of async Tornado / etc, it serves a different need. Like all wsgi servers, it is best to optimize Flask such that you serve a small number of concurrent requests that are fast to prevent a long queue waiting to serve web requests. With Tornado you have more flexibility in that particular area, but also another layer of complexity. Different tools for different use cases.
  - nawitus 11y ago
    > Like all wsgi servers, it is best to optimize towards serving a small number of concurrent requests that are fast and end fast to free up the worker pool. Well, most (or all) web applications I've worked with make database calls to serve a response, which (in case of Flask) locks the whole thread, and there's always the possibility that the database request is slow. That's why I prefer asynchronous web servers where I don't need to worry about this particular problem. Modern web applications tend to be more like light proxies between the database and other (micro)services. Most logic has been transferred to the client, including templating. Serving static files should be done by Nginx in any case. Therefore I think it's rather critical that the web application does the serving of multiple requests well, and why I think the async architecture is the way going forward.
encoderer 11y ago
The post mentions Falcon at the end. At Cronitor, I rebuilt our ping tracking endpoint (peaks over 100r/s) with Falcon, breaking it out of Django, and I wrote a blog post about it: https://blog.cronitor.io/scaling-django-breaking-out-not-breaking-up-c48b4a9e4a96 https://blog.cronitor.io/scaling-django-breaking-out-not-bre... Here's a tldr: Logging requests to a flat file on a t2.small instance: Django: 519.93 trans/sec Falcon: 2083.19 trans/sec
- tedmiston 11y ago
  I'm confused when you say requests are logged to a flat file, but also requests are sent to SQS (presumably to be processed and eventually hit a centralized log?)
  - mattzito 11y ago
    I think perhaps just to remove SQS as a bottleneck for benchmarking purposes?
    - encoderer 11y ago
      Correct, but this could probably be more clear.
nerva 11y ago
So what's a good (clean) way to create the frontend for Flask apps? I have a decent sized Flask app and I've created a mess with all the templates, static CSS/JS now. What JS framework do you tie it to, if you use Flask to just create an API/manage sessions?
- mwhite 11y ago
  You could try using Flask-Restless with Backbone-Relational and then integrate with something like React using something like https://github.com/magalhas/backbone-react-component https://github.com/magalhas/backbone-react-component https://flask-restless.readthedocs.org/en/stable/ https://flask-restless.readthedocs.org/en/stable/ http://backbonerelational.org/ http://backbonerelational.org/
  - mwhite 11y ago
    On second thought, I'm not sure if a backbone-react mixin is even necessary. You can explicitly subscribe and unsubscribe to events with only a couple lines of code in componentWillMount() and componentWillUnmount().
- bndw 11y ago
  You can serve any sort of frontend from Flask. Personally, I prefer Emberjs and have been serving Ember apps from Flask for sometime now. It's as easy as pointing your Flask app's `template_folder` at the compiled frontend folder. If you're using Emberjs, this is the `dist` folder.
- mslate 11y ago
  I host my Flask API on one server and serve a single page app (Angular) on another. The trick with that is having to host them from separate domains and deal with CORS, however it also allows you to distribute your SPA via CDN instead of using Flask app servers to serve up that static content. This is what we do at my full-time gig, but same holds for Flask.
  - derefr 11y ago
avyfain 11y ago
I have been working with flask over the last 6 months and the deeper I dive the more I feel like there are 100 ways to do each task. Can anyone provide a few good open source flask projects worth reading?
esaym 11y ago
I think Flask is like Ruby Sinatra and Perl Dancer. I've used Dancer quite a bit. Some for larger apps (30+ pages) This is how I typically lay out a Dancer app. Starting with a top level directory of application name, say "MyApp", I put the routes in different directories instead of jumble them all up in one file. As an example, lets use an app that handles and tracks customers and orders. So something like this: MyApp/ └── Routes ├── API │ ├── Component │ │ ├── Customer.pm │ │ └── Order.pm │ ├── Customer.pm │ └── Order.pm ├── API.pm ├── Customer.pm └── Order.pm (templates should have a similar layout in a separate 'Views' directory) Routes/Customer.pm would handle basic requests like GET /Customer/list and POST or GET Customer/1 While routes handling json/ajax only requests (from jquery ect) would be in Routes/API/Customer.pm. Routes/API.pm would be an api for stuff that doesn't directly involve a Customer or Order object (perhaps returning json from an inventory table or something) And if you get tired of requesting json just to convert it into html with javascript and you want the power of a template (without a SPA); I fetch that stuff with jquery .load() using the 'Component' routes (dynamic parts of a webpage). For example, perhaps when making a new quote, you select a specific customer and you want open orders to be displayed in a popup or inline div somewhere. Using jquery .load(), you would just easily fetch /API/Component/Customer/Open-Orders/<cust id#>, ect and then just inline the returned html. If you stick to a rule of "components can only return html and not cause a page refresh", you will keep from getting too big of mess with them. This is just sorta a method I made from various best practices from other frameworks. Perhaps its barftastic, but I haven't been complaining about it.
- jqm 11y ago
  I like Jinja2 templating and haven't fully jumped on the client side generation train. But I'm partially on that train and do do some client side generation. Particularly for elements that need to appear and disappear with the data lurking in the background. What I found is that I can pass json directly to the script portions of a Jinja template and avoid a second request (although certainly subsequent requests are often necessary). It might not be the "right way" but it works for a lot of things and is pretty simple.
- derefr 11y ago
  This is reminding me strangely of the original, non-single-entry-point style of writing PHP. I'm actually kind of surprised that we haven't seen a return to that style, with more modern sensibilities: each route directly mapping to a file containing the route's procedure body + any view templates for that route; a single "common" file at the project root containing dependency-imports and model declarations, etc. In the end, it wouldn't actually work like old PHP—you'd still actually have a single entry-point and all the code would be preloaded rather than loaded into an ephemeral request context—but you'd be able to code as if the opposite was true. Reminds me a bit of the "oldschool sensibilities" of coding with something like Löve2D, actually.
idm 11y ago
I've used Flask for several dozen projects, mostly in the data science space. I combined the reusable bits to create http://flask-diamond.org http://flask-diamond.org - and I've written lots documentation to help people get work done using it. Flask-Diamond establishes some common practices so that you are not starting from scratch for each and every new Flask app. In a research context, I might scaffold multiple new apps per month, so this has been a huge time saver for me. This has also made Flask teamwork much easier.
welder 11y ago
Flask is awesome! Here are some must-use libraries along with any Flask app: https://gist.github.com/alanhamlett/ecb3656a1d1bfb3feb31 https://gist.github.com/alanhamlett/ecb3656a1d1bfb3feb31 (requirements.txt) Flask is great for small projects, and also scales to large apps like https://wakatime.com https://wakatime.com
itajaja 11y ago
Shamelss plug: We are using flask-resty [1] for our microservices and it's awesome. it uses sqlalchemy and marshmallow and the resulting code is very terse and declarative. [1] https://github.com/4Catalyzer/flask-resty https://github.com/4Catalyzer/flask-resty
bkovacev 11y ago
What do you guys think of webapp2 framework? How does it compare to flask?
- mayhew 11y ago
  Assuming this [1] is the main source repository for webapp2, it hasn't had any serious development since early 2012 and there's probably no reason to use it. [1] https://code.google.com/archive/p/webapp-improved/source/default/commits https://code.google.com/archive/p/webapp-improved/source/def...
  - bkovacev 11y ago
    Yes that is the framework. Well, Google App Engine still suggests using it in all of their code snippets and is the goto python framework suggested for GAE apps. I also probably didn't formulate my question well. I didn't ask whether to use it or not, but how it compares to Flask - .
m_mueller 11y ago
Is it really best practice to initialize the logger in each python file? Seems strange to me, I've always just initialized in the main routine(s) and the logger that you set up like this is available from everywhere as a singleton (`import logging ; logging.info("hello world")`).
- pyre 11y ago
  > `import logging ; logging.info("hello world")` I don't think that this is doing what you think it is doing (assuming that 'import logging' is importing the Python logging package, and not relying on broken Python 2 package name resolution quirks to import a local module). The `logging.{LEVEL}` functions always log in the root logger. The loggers that you initialize have a tree structure. There is a nice package for inspecting that here: https://pypi.python.org/pypi/logging_tree https://pypi.python.org/pypi/logging_tree Several different 3rd party libraries that you might be using will all have their own loggers that are initialized at their level. By separating things out like this, you can set different log levels for different loggers. For example, you might not want Component A logging at DEBUG level, while you want Component B logging at DEBUG level. This is why one would initialize things per package like this: import logging logger = logging.getLogger(__name__) That logger's log level inherits from it's parent, and the structure mirrors the structure of your package/module hierarchy, so you can set the log level for an entire package, or just an individual module. Granted, you may not require such granularity, but doing this as a standard practice does give you the flexibility.
  - m_mueller 11y ago
    Well yes, but with basic_config I'm telling the root logger in a central fashion what it's supposed to do - at least that's how I understand it. So far I've never had the urge to initialize separate child loggers for every component. Do people do that mainly so you can have fine grained control over log levels?
    - mixmastamyk 11y ago
      Yes, otherwise you can get messages from noisy libraries bubbling up to the user that may not be relevant in the app context. If the logging is just going to a file to look at later it matters less, still sometimes it is nice to shut them up.
m_mueller 11y ago
Here's why I use Flask for every web project: - It is both 'out of my way' and flexible enough to scale up. I.e. you can start with a 5 LOC hello world, but it still handles a large app with lots of components well (Blueprints). - It doesn't force a data model / DB onto me - I can just plug in whatever I have (unlike Django). - It doesn't even force a templating engine onto me - I always use mustache instead of jinja2 (it's extremely tiny, tidy and portable to any language, so it's much easier to port code to other devices / platforms). - wanna just get started? `sudo pip install Flask && python ./hello.py` --> served on localhost:5000. I recently started a project[1] while in a meeting with someone complaining about some complex app we had - built a prototype with him together that could replace the entire thing and solves problems we had in 2h. Having a foolproof starting point without any configuration and then being able to build up from there is essential. [1] https://github.com/muellermichel/guetzli https://github.com/muellermichel/guetzli
- waprin 11y ago
  I like Flask a lot, but I take issue with: > It doesn't force a data model / DB onto me - I can just plug in whatever I have (unlike Django). Django doesn't force a data model onto you anymore than Flask does - nobody is forcing you to use the Django ORM. Any database code you write for a Flask app could be re-used in a Django app. What the Django ORM does do is allow you to write portable apps and extensions. For example, suppose someone writes an extension for Flask that uses SQLAlchemy. If I'm writing a Flask app and only have a Mongo database available, I can't use that extension. On the other hand, if someone uses the Django ORM to write that extension, as long as I have a Django backend for my database, I can use their extension. It abstracts away the underlying datastore. Besides just which database you are using, you can also write a variety of code that works with Django models. Now granted, this abstraction can be severely leaky and flawed at times, but it's still quite powerful overall. Django provides a conventional, standard way to address the issue of interacting with data in a general way. Again, nobody is forcing you to use it, because you can just bypass the ORM and write your database code directly. It's just a powerful paradigm if you do embrace it.
  - m_mueller 11y ago
foxhop 11y ago
I do not use flask for large applications, I reach for Pyramid instead.
- mkesper 11y ago
  Can you share some advantages you perceive?
  - ergo14 11y ago
    Pyramid avoids globals wherever it can, so this leads to cleaner and better architecture. has an event system that you can plug in, and customizable auth system. You also have powerful pluggable configuration system where you can easly add new functionalities to your app as extensions, like provide pluggable service layer, or auto add new views from external package for your application that handle some specific functionality. It was also among first python frameworks that supported py3.
  - foxhop 11y ago
    Pyramid also has scaffolds which layout the project in an intelligent way based on some assumptions. Pyramid can be as batteries included or as out of your way as you desire. In the end there isn't a Pyramid way (The Rails Way) there is just Python. Also the debugtool bar is excellent for tracking down defects. The last time I check the Pyramid code base had 100% test coverage. I look to the documentation as a work of art and a standard for all of my opensource libraries.
akoumjian 11y ago
This was a good general list of things to consider for scaling any web applications. What I've noticed though is that all my flask apps, after adding in all of the standard components, eventually converge on a Django-esque setup anyway. So now I just use Django, and if I don't want to use a particular component (ie: orm, templates, whatever) I don't, or I swap it out. On the other hand, if I do want to use those components, they are right there.
- derefr 11y ago
  Do you ever write "apps" that only expose an API, without rendering any HTML? I find Flask (or Ruby's Sinatra) to be ideal for that case. Given hexagonal architecture (i.e. your model + business rules existing as a "service component" library project, that your webapp consumes as a dependency), if all you need is to expose that service with an API, Flask and/or Sinatra lets you do so with nothing more than a flat file of 3–6-line controller stanzas. It's really quite lovely; gets to the core of what it means for something to be a "microservice."
  - akoumjian 11y ago
    I suppose if you already have an existing service component that encapsulates authentication, authorization, business logic, notifications, and all that other jazz, then use flask is an excellent way to wrap that to produce an http api.
arel90 11y ago
WATCH BOX OFFICE MOVIE NOW!! Find the Film click here MOVIE FREE https://t.co/nLGLMehTaI https://t.co/nLGLMehTaI & here TV MOVIE SHOWS https://t.co/zJWRHf75RF https://t.co/zJWRHf75RF WEEKEND BOX OFFICE Weekend box office charts show gross receipts for a given weekend, which is Friday through Sunday unless otherwise noted. Studio estimates for the weekend are reported on Sunday mornings, generally between 9 a.m. and 10 a.m. Pacific Time and reflect estimated Friday and Saturday box office receipts plus a projection for Sunday. As with daily box office, weekend estimates do not reflect all movies playing in theaters, but at least the Top 12 plus select movies below that may be reported. Actual weekend box office receipts are reported Monday, generally after 1 p.m. Pacific Time, and reflect most movies currently playing in the marketplace. A final update to the chart may be made Monday night or later in the week to reflect grosses that are reported late. Readers can view historical weekend box office from 1982 to the Present and have access to the weekend index, broken down by year. Readers also have access to an index by week number, showing a given week's box office history from 1982-Present. WEEKLY BOX OFFICE Weekly box office charts show gross receipts for a given week, which is defined as Friday through Thursday. This information is reported on Friday afternoons for the previous week's box office, though additional titles are added to a given week's chart at later dates to account for grosses reported late. Readers have full access to historical weekly data back to 1982 as well as an index, similar to the weekend box office index. MONTHLY, QUARTERLY and SEASONAL BOX OFFICE These sections allow readers to view box office receipts for the above time periods by Release Date and by Calendar Grosses. Monthly box office is a breakdown by month, of January through December; Quarterly box office is a breakdown by quarter (i.e., January through March is Q1, etc...); Seasonal box office is a breakdown by season. There are five box office seasons: Winter (the first day after New Year's week or weekend through the Thursday before the first Friday in March), Spring (the first Friday in March through the Thursday before the first Friday in May), Summer (the first friday in May through Labor Day Weekend), Fall (the day after Labor Day Weekend through the Thursday before the first Friday in November) and Holiday (the first Friday in November through New Year's week or weekend). Each of these sections contains an index by the specified time period, from 1982 to the Present, as well as a breakdown of time periods for a given year, from 1982 to the Present. Each individual chart shows a list of movies for a specific time period in a specific year. Both the indexes and individual charts can be viewed by Release Date for all movies, Wide Releases only and Limited Releases only, as well as by Calendar Grosses. They can be sorted by any column, adjusted for ticket price inflation and individual charts can be filtered by studio. YEARLY BOX OFFICE Readers can view the top 50 movies of a given year from 1980 to 2000 and the top 150 movies from 2001 to the Present. Readers can also view all movies tracked for these years as well as breakdowns by Release Date and Calendar Gross and can filter by studio. Readers can also view the top 10 opening weekends for each given year; readers can view all opening weekends and filter by wide and limited releases only as well as by studio. Finally, Worldwide box office by year, which shows the movies' combined domestic and foreign grosses, can be viewed from 1989 to the Present. Movies are grouped by the year they were released domestically, regardless of when they were released in foreign markets. HISTORICAL CHARTS The data on the Yearly and All Time Domestic charts can be viewed "as of" a given date in history. For example, one can see what 1999's box office was like as of May 19. Or one can see what the All Time Domestic Box Office chart looked like in 1987.
arel90 11y ago
WATCH BOX OFFICE MOVIE NOW!! Find the Film click here MOVIE FREE https://t.co/nLGLMehTaI https://t.co/nLGLMehTaI & here TV MOVIE SHOWS https://t.co/zJWRHf75RF https://t.co/zJWRHf75RF WEEKEND BOX OFFICE Weekend box office charts show gross receipts for a given weekend, which is Friday through Sunday unless otherwise noted. Studio estimates for the weekend are reported on Sunday mornings, generally between 9 a.m. and 10 a.m. Pacific Time and reflect estimated Friday and Saturday box office receipts plus a projection for Sunday. As with daily box office, weekend estimates do not reflect all movies playing in theaters, but at least the Top 12 plus select movies below that may be reported. Actual weekend box office receipts are reported Monday, generally after 1 p.m. Pacific Time, and reflect most movies currently playing in the marketplace. A final update to the chart may be made Monday night or later in the week to reflect grosses that are reported late. Readers can view historical weekend box office from 1982 to the Present and have access to the weekend index, broken down by year. Readers also have access to an index by week number, showing a given week's box office history from 1982-Present. WEEKLY BOX OFFICE Weekly box office charts show gross receipts for a given week, which is defined as Friday through Thursday. This information is reported on Friday afternoons for the previous week's box office, though additional titles are added to a given week's chart at later dates to account for grosses reported late. Readers have full access to historical weekly data back to 1982 as well as an index, similar to the weekend box office index. MONTHLY, QUARTERLY and SEASONAL BOX OFFICE These sections allow readers to view box office receipts for the above time periods by Release Date and by Calendar Grosses. Monthly box office is a breakdown by month, of January through December; Quarterly box office is a breakdown by quarter (i.e., January through March is Q1, etc...); Seasonal box office is a breakdown by season. There are five box office seasons: Winter (the first day after New Year's week or weekend through the Thursday before the first Friday in March), Spring (the first Friday in March through the Thursday before the first Friday in May), Summer (the first friday in May through Labor Day Weekend), Fall (the day after Labor Day Weekend through the Thursday before the first Friday in November) and Holiday (the first Friday in November through New Year's week or weekend). Each of these sections contains an index by the specified time period, from 1982 to the Present, as well as a breakdown of time periods for a given year, from 1982 to the Present. Each individual chart shows a list of movies for a specific time period in a specific year. Both the indexes and individual charts can be viewed by Release Date for all movies, Wide Releases only and Limited Releases only, as well as by Calendar Grosses. They can be sorted by any column, adjusted for ticket price inflation and individual charts can be filtered by studio. YEARLY BOX OFFICE Readers can view the top 50 movies of a given year from 1980 to 2000 and the top 150 movies from 2001 to the Present. Readers can also view all movies tracked for these years as well as breakdowns by Release Date and Calendar Gross and can filter by studio. Readers can also view the top 10 opening weekends for each given year; readers can view all opening weekends and filter by wide and limited releases only as well as by studio. Finally, Worldwide box office by year, which shows the movies' combined domestic and foreign grosses, can be viewed from 1989 to the Present. Movies are grouped by the year they were released domestically, regardless of when they were released in foreign markets. HISTORICAL CHARTS The data on the Yearly and All Time Domestic charts can be viewed "as of" a given date in history. For example, one can see what 1999's box office was like as of May 19. Or one can see what the All Time Domestic Box Office chart looked like in 1987.
arel90 11y ago
WATCH BOX OFFICE MOVIE NOW!! Find the Film click here MOVIE FREE https://t.co/nLGLMehTaI https://t.co/nLGLMehTaI & here TV MOVIE SHOWS https://t.co/zJWRHf75RF https://t.co/zJWRHf75RF
deleted 11y ago
[deleted]
acidity 11y ago
Another one that I have used in multiple of my projects: https://github.com/mattupstate/overholt https://github.com/mattupstate/overholt
a_c 11y ago
The "Architecture The Lost Years" talk is a real gem
TeeWEE 11y ago
While flask is a nice framework, it has some problems. I worked with numerous python web frameworks, mainly webapp2 and flask. So some things i don"t like about flask: Disclaimer: You can architect beautiful apps in apps, its just easy todo it wrong. GLOBALS: Flask has a lot of globals (from flask import g, request, current_user, etc.) A better web handler function looks like this handle(request) -> response. Any other web framework that I know does it like this. Much better. Flask promotes touching the 'request' object everywhere. Example: https://github.com/lepture/flask-wtf/blob/master/flask_wtf/form.py https://github.com/lepture/flask-wtf/blob/master/flask_wtf/f.... Flask is not functional, its inherently statefull with globals. MIDDLEWARE: Flask promotes writing middleware as decorators functions, while it looks nice, it not really useable anywhere else, and its not really a standard. At least you can still use WSGI middleware. BLUEPRINT are nice, but have issues: When you create a blueprint, for a sub app, you cant set error handlers. They only work on app level. Also (small issue) You cant add blueprint specific middleware. Better way to create 'sub apps': Use a new WSGI App. Or use a sitemap where you bind functions to paths. SITEMAP @route has disadvantages For big apps, its nice to have a single routes.py file where you can see all urls the app supports, and which methods to handle those. The @route is nice to use initially, but imho for big apps it becomes messy. Also it promotes circular imports: view.py: from init import blueprint #circular import! blueprint.route('/test/') def f(): pass init.py: blueprint = new Blueprint from . import view assert view # ensure the handlers are initiallized
- irahul 11y ago
  Haven't used flask in some time now, but most of your objections are missing the mark. > GLOBALS: Flask has a lot of globals (from flask import g, request, current_user, etc.) A better web handler function looks like this handle(request) -> response. Any other web framework that I know does it like this. Flask's request is not global. I have had this discussion with someone else before: https://news.ycombinator.com/item?id=6662623 https://news.ycombinator.com/item?id=6662623 FWIW, flask's "from flask import request" never had been a blocker for me, whereas django's injected request variable had made me write middleware to preseve requests as thread locals so that I can access it elsewhere. Werkzeug does the same thing, except it does it more robustly. > MIDDLEWARE: Flask promotes writing middleware as decorators functions, while it looks nice, it not really useable anywhere else, and its not really a standard. At least you can still use WSGI middleware. I don't see an issue. If you can solve it using simple python(decorators), solve it using Python. > BLUEPRINT are nice, but have issues: When you create a blueprint, for a sub app, you cant set error handlers. They only work on app level. Also (small issue) You cant add blueprint specific middleware. Rather than calling app.before_request, you can call blueprint.before_request and it will work only for that blueprint. > SITEMAP @route has disadvantages For big apps, its nice to have a single routes.py file where you can see all urls the app supports, and which methods Then don't use the decorator. Have a routes.py and call app.add_url_rule I have had a template with all of this from some time back https://github.com/rahulkmr/flask-bigapp-template https://github.com/rahulkmr/flask-bigapp-template
ccanassa 11y ago
I spend the last 3 years on the microframework bandwagon, and now I am quite pleased to be back writing Django code. In my experience, any sufficiently large Flask project contains an ad hoc, bug-ridden, slow implementation of half of Django.
auvrw 11y ago
in addition to the flask documentation http://flask.pocoo.org/docs/0.10/ http://flask.pocoo.org/docs/0.10/ the snippets page is really helpful http://flask.pocoo.org/snippets/ http://flask.pocoo.org/snippets/ also, I've some boilerplate https://github.com/ransomw/catalog-flask https://github.com/ransomw/catalog-flask even though it hasn't gotten attn in a while

358 points by shinryuu 11y ago

> Scaling in terms concurrent users also has little to do with the web framework and more to do with your understanding of load-balancing, caching, databases, etc. This is what it always come down to for me. I know that when we can get our app running efficiently with reasonable memory requirements on a single core, then scaling it is really just about launching processes and load balancing them. Scaling out boxes is always easier than scaling out code -- for better or worse. I'm not talking about load balancing servers mind you, but applications on any given host. Two layers of load balancing. When I'm comfortable with the resource requirements I launch as little or as many of the app in a predictable manner across any number of nodes. It's comforting to know that given X, Y core and ram, I can run N services.

condescendence 11y ago

Flask is just awesome, I've never messed with a framework that's made things so simple yet doesn't take away from functionality if you're looking to build more complex apps. Anyone looking to get into webscripting/webapps should definitely take a look at flask, its python based, good for prototyping or production apps and has tons of useful documentation.

samstave 11y ago
best tutorial starting points?
- siquick 11y ago
  the bible: http://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world http://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-...
  - dewarrn1 11y ago
    Seconded — Miguel's blog is terrific! Major chunks of my (very simple) website's code bear a suspicious resemblance to his examples.
    - condescendence 11y ago
      I think many people's flask personal projects resemble his examples in some way ;) He covers just about everything a modern web app needs
  - agumonkey 11y ago
    The official docs http://flask.pocoo.org/docs/0.10/ http://flask.pocoo.org/docs/0.10/ are also very nice although not full featured and integrated as the mega tutorial.
  - deleted 11y ago
    [deleted]

jqm 11y ago

Falcon (http://falconframework.org/ http://falconframework.org/ mentioned at the bottom of the article) does look interesting. I've also had good experiences with bottle (http://bottlepy.org/docs/dev/index.html http://bottlepy.org/docs/dev/index.html) for building internal apps for companies. The limited amount of users means I don't have to worry much about scaling and bottle with Paste server works pretty nicely. Jinja2 templates can also be used with bottle which is a plus. It's also pretty easy to compile this setup into an executable so it can run off someone's Windows machine and no need for a separate server. This setup makes a really convenient internal-use app which is easy to send to end users for deployment.

rahimnathwani 11y ago
If you are bundling as a windows exe, where are you storing persistent state/data? (EDIT: fixed autocorrect exe->exercise)
- jqm 11y ago
  Either interact with an external database... (an existing company db for instance...this is just a front end) or else use a sqlite file on the local machine for smaller stuff.

jorgecurio 11y ago

Don't be fooled by the "micro-framework" line. My experience of building SaaS on top of Flask is that you are going to have to reinvent the wheels for a lot of things. Flask is plagued with abandoned plugins from a cesspool of weekend contributors which you rely on for basic things such as authentication and ORM. Tough enough as it is with all the outdated documentation for each of the plugins you need. So my recommendation based on 2 years of working with Flask is don't fucking do it, unless your product doesn't extend beyond couple of HTTP endpoints served over uwsgi + nginx for your internal applications. I really wish I'd spent all that time I spent on Flask on Node.js, python was the wrong medium to distance myself from PHP frameworks. All in all, 4 years have passed since my search of alternatives to LAMP. And finally, it wasn't some open source framework or asynchronous javascript to save the day, it was Amazon Lambda + API Gateway. Gone are the need to spin up Vagrant, docker, mysql/postgresql. I just upload the specific script I want and bam. Npm modules and pip modules too. I've in the process of migrating to AWS and leaving Flask. Great initiative, ruined by abandonware plugins and modules, certainly not attractive to entice developers to build their own wheels. The biggest mistake you could do is basing speed and agility as basis for going with Flask. It is the complete opposite. I think using Laravel or even CodeIgniter will significantly cut development time. Regardless, I'm done with the whole server/client frameworks and have migrated to AWS without any servers to maintain or setup. There's even frameworks for "Serverless" architecture now which makes me shake my head.

orf 11y ago
Why not try Django? It's documentation is top notch, plenty of maintained plugins for everything you could need. Jumping on the lambda bandwagon seems pretty risky, and in any case how does it protect you against abandonware? To me it's a bit like saying "I don't like outdated python packages, so I'll switch to nginx instead of Apache!".
- mhurron 11y ago
  > Why not try Django? They blame Python for issues they perceived with Flask, I doubt they're going to be too open to Django.

abledon 11y ago

If your interested in websockets for flask, Miguel Grinberg has a straightforward implementation: http://blog.miguelgrinberg.com/post/easy-websockets-with-flask-and-gevent http://blog.miguelgrinberg.com/post/easy-websockets-with-fla...

aidos 11y ago

> In the end you should be aiming to design your application to depend on Flask as little as possible. I'm 3 years in to a project where I've taken the approach of having my "app" as its own package. Flask is then a thin wrapper that instantiates the app and then exposes the views to talk to it. I handle validation / sessions / config etc within Flask. It's extremely flexible. I have some stuff that runs off as worker processes. No problem - the core is the same, the wrapper around it is different. I also have a boot.py that I can call so I'm working directly with the app in ipython (again, it's a wrapper that starts the app). I'm currently reworking the structure for capacity planning, which is mostly just a matter of splitting the Flask app into 2 apps for handling different parts of the work. Because my core app is decoupled from the web app it's all really easy to do.

odonnellryan 11y ago
Great points! I've worked with Flask for a while, as I've gotten to be a better developer. I used to have a lot of my logic in the application itself. Now, I ensure my logic lives in its own modules. Flask is really just either a way to serve my templates or API.
voltagex_ 11y ago
Maybe I'm just not thinking clearly today but how do you turn Flask into a wrapper? I thought you had to put enough logic in to a class that inherits from Flask to return views and such.
- aidos 11y ago
  I think I need to explain a bit better. I have a few different layers. From the outside in: Flask/Web Deal with sessions, authentication, caching, templating, logging etc here. Fires up an instance of the App and keeps it around for the duration of the life of the Web instance. I actually have an API in here that looks like what you'd expect in most other web apps. It does the validation / error handling etc. In terms of manipluating the data, I'm not a total purist - the API is allowed to load up the SQLA models and make changes. If there's a more complex operation going on though, it will live inside the next layer down. App Deal with remote services / data models / db connection. I guess on the outside you might call this a "service layer". A surprisingly large amount of this is data persistance management. The model I use is to put the data access stuff just off to the side at the top level of the app. Nothing in here knows anything about things like web frameworks. This is important. In other places in the system, this same App is used by RQ (worker instances taking on work via a redis queue). There's another web app that uses it for administrative tasks. I can boot it up to work with it in ipython (I do this a lot). Oh, and I don't manage the db life-cycle here. Whichever layer sits above this determines when it's ok to commit transactions. If something goes wrong here we raise app specific expections - the layer above can handle those and relay them as appropriate. Core In the very core I have "pure" algorithmic stuff (for context - http://www.countfire.com http://www.countfire.com is effectively an image recognition app). Really this is just one component that the App happens to be using. If the App wants to talk to this, it needs to create the data structures that the core defines. At various borders I often have mappings from the objects in the current local world to versions for the created to talk to the layer below (ps I like namedtuples). It's a lot more complex than all this, each of these layers has more sub layers etc. And really, what I've called the Core is a sublayer of the App (in my case there's a well definied algorithmic chunk that I think of as the core so it's in its own package - it stands alone as its own library). There's no real way of knowing where you'll draw lines between the layers when you start but I have a few rules. Any bit of code should be given the bare minimum of data required to do its work. At borders map local data to data for the next layer. Make sure the stuff going into the current layer is really there because it needs to be there. Be a pragmatist - things will change, you'll pull stuff out into submodules. By following the other rules hopefully refactoring won't be too painful.

andrewstuart 11y ago

Bottle and Flask are similiar and a great place to learn and start your journey with Python web application development. It is pseudo-minimalist though, so either you must almost immediately start reinventing the wheel to build basic stuff that you will need (as a novice developer I started by writing my own sessions and cookie handler). The next realisation you'll come to is that all that stuff has already been written by someone else as addons. So you try that but eventually you'll find you are in so much pain from problems with integrating addons that you will realise that you would be best off with something that has all the basic functionality "batteries included". So then you'll try to find projects on github that have already baked together Flask plus all the plugins into a boilerplate project. Then you'll find that there's many ways to bake all that stuff together and start to wonder if maybe you're now using a framework. But the boilerplate Flask with addons integration doesn't feel like it has a really well thought out consistent overarching model. So you'll then look at full featured integrated frameworks like Django where it's all integrated according to an architectural vision (perfect or otherwise is a matter of opinion) and although you might mot like some of the components, at least its all built in. Flask still carries of cruft and mental model though, because it is from earlier days of web development when you built the front end in the back end using things like Jinja templates. And then one day you'll need to build just a simple REST API without all the bells and whistles needed in a web application. So you can then look at Falcon which is extremely minimalist for developer who know they don't want any extra web application stuff at all including things like back end UI generation with templates. It's a sharp knife because there's almost nothing in it, and never attempted to provide the features needed to build user oriented web applications, so it has a very small mental model to grasp. TLDR: Bottle and Flask are great for finding your feet in web development without being forced to learn too many concepts all at the same time. Django or Pyramid or something full featured for web application development Falcon for REST API development If you are willing to take on the cognitive load of going straight to your destination, I would recommend beginners start with Django or Pyramid or Falcon. If (and this is entirely reasonable) you need to get going in Python web development without being overwhelmed by the concepts, go to Bottle or Flask but move on as soon as you can. If you love Flask and have the skills and competence to craft your own architecture and carefully selected from a menu of addons that suit you and know how to whittle out unneeded functionality, then Flask is the right choice for you.

mattbillenstein 11y ago

+1 flask-classy -- feels a bit like the old pylons which was a very simple and powerful framework

bunnybender 11y ago
The original flask-classy extension hasn't seen updates in two years. This fork is currently active: https://github.com/teracyhq/flask-classy https://github.com/teracyhq/flask-classy
ergo14 11y ago
Well, If you liked pylons - pyramid with classes and matchparam based views will feel also very similar to you.

kunoo 11y ago

A bit off topic, but does anybody know why development looks stopped since 2013? http://flask.pocoo.org/docs/0.10/changelog/ http://flask.pocoo.org/docs/0.10/changelog/ I'm in the process of writing my first webapp, and thses days it's a bit strange seeing a popular framework not being updated (even if it's just for bugfixing) a few times a year.

detaro 11y ago
It hasn't stopped, there just hasn't been a release. Main issue seems to be that the next release was planned to be the magic "1.0" and that isn't finished. So while that is worked on, there haven't been new releases, because the current release works, and most bug fixes happened in dependencies (jinja, werkzeug). At least that was my takeaway from various github discussions about it.
zanny 11y ago
There are milestones for 0.11 and 1.0: https://github.com/mitsuhiko/flask/milestones/0.11 https://github.com/mitsuhiko/flask/milestones/0.11 https://github.com/mitsuhiko/flask/milestones/1.0 https://github.com/mitsuhiko/flask/milestones/1.0 None of the 0.11 blockers are substantial, and 1.0 is mostly about having updated documentation. It just requires someone to actually finish them.
andrewstuart 11y ago
It's a bit unclear how enthused Mitsuhiko remains about Python development. He is one of the greatest contributors to the Python community and undoubtedly one of the most impressive software developers on the Internet. He is very "Python 2" oriented though and I wonder if his enthusiasm for Python has waned because he could never get onboard the Python 3 thing with enthusiasm. To his credit he updated Flask early to Python 3 and he has written alot of other stuff, most of which I understand to be Python 3 compatible. As everyone here knows, it's hard to write software when you don't feel enthused about the programming language. He has been doing stuff with Rust in particular. Maybe there will be a "Rusty Flask" one day.
- leejoramo 11y ago

nawitus 11y ago

How do you load balance a Flask application since it's single threaded? For optimal performance shouldn't there be a single Flask instance (process?) for each request being processed? What kind of load balancers are usually used with Flask and how do they decide to spawn new Flask instances? And why should Flask be used instead of asynchronous Tornado or Node.js?

matthewowen 11y ago
A common approach is to run Flask on uWSGI or gunicorn. You then put this behind nginx.
fuhrysteve 11y ago
You typically use something like uwsgi or gunicorn to serve requests, and it's uwsgi & gunicorn that decide how many processes or threads to start. These typically sit behind a load balancer and / or a reverse proxy. In terms of async Tornado / etc, it serves a different need. Like all wsgi servers, it is best to optimize Flask such that you serve a small number of concurrent requests that are fast to prevent a long queue waiting to serve web requests. With Tornado you have more flexibility in that particular area, but also another layer of complexity. Different tools for different use cases.
- nawitus 11y ago
  > Like all wsgi servers, it is best to optimize towards serving a small number of concurrent requests that are fast and end fast to free up the worker pool. Well, most (or all) web applications I've worked with make database calls to serve a response, which (in case of Flask) locks the whole thread, and there's always the possibility that the database request is slow. That's why I prefer asynchronous web servers where I don't need to worry about this particular problem. Modern web applications tend to be more like light proxies between the database and other (micro)services. Most logic has been transferred to the client, including templating. Serving static files should be done by Nginx in any case. Therefore I think it's rather critical that the web application does the serving of multiple requests well, and why I think the async architecture is the way going forward.

encoderer 11y ago

The post mentions Falcon at the end. At Cronitor, I rebuilt our ping tracking endpoint (peaks over 100r/s) with Falcon, breaking it out of Django, and I wrote a blog post about it: https://blog.cronitor.io/scaling-django-breaking-out-not-breaking-up-c48b4a9e4a96 https://blog.cronitor.io/scaling-django-breaking-out-not-bre... Here's a tldr: Logging requests to a flat file on a t2.small instance: Django: 519.93 trans/sec Falcon: 2083.19 trans/sec

tedmiston 11y ago
I'm confused when you say requests are logged to a flat file, but also requests are sent to SQS (presumably to be processed and eventually hit a centralized log?)
- mattzito 11y ago
  I think perhaps just to remove SQS as a bottleneck for benchmarking purposes?
  - encoderer 11y ago
    Correct, but this could probably be more clear.

nerva 11y ago

So what's a good (clean) way to create the frontend for Flask apps? I have a decent sized Flask app and I've created a mess with all the templates, static CSS/JS now. What JS framework do you tie it to, if you use Flask to just create an API/manage sessions?

mwhite 11y ago
You could try using Flask-Restless with Backbone-Relational and then integrate with something like React using something like https://github.com/magalhas/backbone-react-component https://github.com/magalhas/backbone-react-component https://flask-restless.readthedocs.org/en/stable/ https://flask-restless.readthedocs.org/en/stable/ http://backbonerelational.org/ http://backbonerelational.org/
- mwhite 11y ago
  On second thought, I'm not sure if a backbone-react mixin is even necessary. You can explicitly subscribe and unsubscribe to events with only a couple lines of code in componentWillMount() and componentWillUnmount().
bndw 11y ago
You can serve any sort of frontend from Flask. Personally, I prefer Emberjs and have been serving Ember apps from Flask for sometime now. It's as easy as pointing your Flask app's `template_folder` at the compiled frontend folder. If you're using Emberjs, this is the `dist` folder.
mslate 11y ago
I host my Flask API on one server and serve a single page app (Angular) on another. The trick with that is having to host them from separate domains and deal with CORS, however it also allows you to distribute your SPA via CDN instead of using Flask app servers to serve up that static content. This is what we do at my full-time gig, but same holds for Flask.
- derefr 11y ago

avyfain 11y ago

I have been working with flask over the last 6 months and the deeper I dive the more I feel like there are 100 ways to do each task. Can anyone provide a few good open source flask projects worth reading?

esaym 11y ago

I think Flask is like Ruby Sinatra and Perl Dancer. I've used Dancer quite a bit. Some for larger apps (30+ pages) This is how I typically lay out a Dancer app. Starting with a top level directory of application name, say "MyApp", I put the routes in different directories instead of jumble them all up in one file. As an example, lets use an app that handles and tracks customers and orders. So something like this: MyApp/ └── Routes ├── API │ ├── Component │ │ ├── Customer.pm │ │ └── Order.pm │ ├── Customer.pm │ └── Order.pm ├── API.pm ├── Customer.pm └── Order.pm (templates should have a similar layout in a separate 'Views' directory) Routes/Customer.pm would handle basic requests like GET /Customer/list and POST or GET Customer/1 While routes handling json/ajax only requests (from jquery ect) would be in Routes/API/Customer.pm. Routes/API.pm would be an api for stuff that doesn't directly involve a Customer or Order object (perhaps returning json from an inventory table or something) And if you get tired of requesting json just to convert it into html with javascript and you want the power of a template (without a SPA); I fetch that stuff with jquery .load() using the 'Component' routes (dynamic parts of a webpage). For example, perhaps when making a new quote, you select a specific customer and you want open orders to be displayed in a popup or inline div somewhere. Using jquery .load(), you would just easily fetch /API/Component/Customer/Open-Orders/<cust id#>, ect and then just inline the returned html. If you stick to a rule of "components can only return html and not cause a page refresh", you will keep from getting too big of mess with them. This is just sorta a method I made from various best practices from other frameworks. Perhaps its barftastic, but I haven't been complaining about it.

jqm 11y ago
I like Jinja2 templating and haven't fully jumped on the client side generation train. But I'm partially on that train and do do some client side generation. Particularly for elements that need to appear and disappear with the data lurking in the background. What I found is that I can pass json directly to the script portions of a Jinja template and avoid a second request (although certainly subsequent requests are often necessary). It might not be the "right way" but it works for a lot of things and is pretty simple.
derefr 11y ago
This is reminding me strangely of the original, non-single-entry-point style of writing PHP. I'm actually kind of surprised that we haven't seen a return to that style, with more modern sensibilities: each route directly mapping to a file containing the route's procedure body + any view templates for that route; a single "common" file at the project root containing dependency-imports and model declarations, etc. In the end, it wouldn't actually work like old PHP—you'd still actually have a single entry-point and all the code would be preloaded rather than loaded into an ephemeral request context—but you'd be able to code as if the opposite was true. Reminds me a bit of the "oldschool sensibilities" of coding with something like Löve2D, actually.

idm 11y ago

I've used Flask for several dozen projects, mostly in the data science space. I combined the reusable bits to create http://flask-diamond.org http://flask-diamond.org - and I've written lots documentation to help people get work done using it. Flask-Diamond establishes some common practices so that you are not starting from scratch for each and every new Flask app. In a research context, I might scaffold multiple new apps per month, so this has been a huge time saver for me. This has also made Flask teamwork much easier.

welder 11y ago

Flask is awesome! Here are some must-use libraries along with any Flask app: https://gist.github.com/alanhamlett/ecb3656a1d1bfb3feb31 https://gist.github.com/alanhamlett/ecb3656a1d1bfb3feb31 (requirements.txt) Flask is great for small projects, and also scales to large apps like https://wakatime.com https://wakatime.com

itajaja 11y ago

Shamelss plug: We are using flask-resty [1] for our microservices and it's awesome. it uses sqlalchemy and marshmallow and the resulting code is very terse and declarative. [1] https://github.com/4Catalyzer/flask-resty https://github.com/4Catalyzer/flask-resty

bkovacev 11y ago

What do you guys think of webapp2 framework? How does it compare to flask?

mayhew 11y ago
Assuming this [1] is the main source repository for webapp2, it hasn't had any serious development since early 2012 and there's probably no reason to use it. [1] https://code.google.com/archive/p/webapp-improved/source/default/commits https://code.google.com/archive/p/webapp-improved/source/def...
- bkovacev 11y ago
  Yes that is the framework. Well, Google App Engine still suggests using it in all of their code snippets and is the goto python framework suggested for GAE apps. I also probably didn't formulate my question well. I didn't ask whether to use it or not, but how it compares to Flask - .

m_mueller 11y ago

Is it really best practice to initialize the logger in each python file? Seems strange to me, I've always just initialized in the main routine(s) and the logger that you set up like this is available from everywhere as a singleton (`import logging ; logging.info("hello world")`).

pyre 11y ago
> `import logging ; logging.info("hello world")` I don't think that this is doing what you think it is doing (assuming that 'import logging' is importing the Python logging package, and not relying on broken Python 2 package name resolution quirks to import a local module). The `logging.{LEVEL}` functions always log in the root logger. The loggers that you initialize have a tree structure. There is a nice package for inspecting that here: https://pypi.python.org/pypi/logging_tree https://pypi.python.org/pypi/logging_tree Several different 3rd party libraries that you might be using will all have their own loggers that are initialized at their level. By separating things out like this, you can set different log levels for different loggers. For example, you might not want Component A logging at DEBUG level, while you want Component B logging at DEBUG level. This is why one would initialize things per package like this: import logging logger = logging.getLogger(__name__) That logger's log level inherits from it's parent, and the structure mirrors the structure of your package/module hierarchy, so you can set the log level for an entire package, or just an individual module. Granted, you may not require such granularity, but doing this as a standard practice does give you the flexibility.
- m_mueller 11y ago
  Well yes, but with basic_config I'm telling the root logger in a central fashion what it's supposed to do - at least that's how I understand it. So far I've never had the urge to initialize separate child loggers for every component. Do people do that mainly so you can have fine grained control over log levels?
  - mixmastamyk 11y ago
    Yes, otherwise you can get messages from noisy libraries bubbling up to the user that may not be relevant in the app context. If the logging is just going to a file to look at later it matters less, still sometimes it is nice to shut them up.

m_mueller 11y ago

Here's why I use Flask for every web project: - It is both 'out of my way' and flexible enough to scale up. I.e. you can start with a 5 LOC hello world, but it still handles a large app with lots of components well (Blueprints). - It doesn't force a data model / DB onto me - I can just plug in whatever I have (unlike Django). - It doesn't even force a templating engine onto me - I always use mustache instead of jinja2 (it's extremely tiny, tidy and portable to any language, so it's much easier to port code to other devices / platforms). - wanna just get started? `sudo pip install Flask && python ./hello.py` --> served on localhost:5000. I recently started a project[1] while in a meeting with someone complaining about some complex app we had - built a prototype with him together that could replace the entire thing and solves problems we had in 2h. Having a foolproof starting point without any configuration and then being able to build up from there is essential. [1] https://github.com/muellermichel/guetzli https://github.com/muellermichel/guetzli

waprin 11y ago
I like Flask a lot, but I take issue with: > It doesn't force a data model / DB onto me - I can just plug in whatever I have (unlike Django). Django doesn't force a data model onto you anymore than Flask does - nobody is forcing you to use the Django ORM. Any database code you write for a Flask app could be re-used in a Django app. What the Django ORM does do is allow you to write portable apps and extensions. For example, suppose someone writes an extension for Flask that uses SQLAlchemy. If I'm writing a Flask app and only have a Mongo database available, I can't use that extension. On the other hand, if someone uses the Django ORM to write that extension, as long as I have a Django backend for my database, I can use their extension. It abstracts away the underlying datastore. Besides just which database you are using, you can also write a variety of code that works with Django models. Now granted, this abstraction can be severely leaky and flawed at times, but it's still quite powerful overall. Django provides a conventional, standard way to address the issue of interacting with data in a general way. Again, nobody is forcing you to use it, because you can just bypass the ORM and write your database code directly. It's just a powerful paradigm if you do embrace it.
- m_mueller 11y ago

foxhop 11y ago

I do not use flask for large applications, I reach for Pyramid instead.

mkesper 11y ago
Can you share some advantages you perceive?
- ergo14 11y ago
  Pyramid avoids globals wherever it can, so this leads to cleaner and better architecture. has an event system that you can plug in, and customizable auth system. You also have powerful pluggable configuration system where you can easly add new functionalities to your app as extensions, like provide pluggable service layer, or auto add new views from external package for your application that handle some specific functionality. It was also among first python frameworks that supported py3.
- foxhop 11y ago
  Pyramid also has scaffolds which layout the project in an intelligent way based on some assumptions. Pyramid can be as batteries included or as out of your way as you desire. In the end there isn't a Pyramid way (The Rails Way) there is just Python. Also the debugtool bar is excellent for tracking down defects. The last time I check the Pyramid code base had 100% test coverage. I look to the documentation as a work of art and a standard for all of my opensource libraries.

akoumjian 11y ago

This was a good general list of things to consider for scaling any web applications. What I've noticed though is that all my flask apps, after adding in all of the standard components, eventually converge on a Django-esque setup anyway. So now I just use Django, and if I don't want to use a particular component (ie: orm, templates, whatever) I don't, or I swap it out. On the other hand, if I do want to use those components, they are right there.

derefr 11y ago
Do you ever write "apps" that only expose an API, without rendering any HTML? I find Flask (or Ruby's Sinatra) to be ideal for that case. Given hexagonal architecture (i.e. your model + business rules existing as a "service component" library project, that your webapp consumes as a dependency), if all you need is to expose that service with an API, Flask and/or Sinatra lets you do so with nothing more than a flat file of 3–6-line controller stanzas. It's really quite lovely; gets to the core of what it means for something to be a "microservice."
- akoumjian 11y ago
  I suppose if you already have an existing service component that encapsulates authentication, authorization, business logic, notifications, and all that other jazz, then use flask is an excellent way to wrap that to produce an http api.

arel90 11y ago

WATCH BOX OFFICE MOVIE NOW!! Find the Film click here MOVIE FREE https://t.co/nLGLMehTaI https://t.co/nLGLMehTaI & here TV MOVIE SHOWS https://t.co/zJWRHf75RF https://t.co/zJWRHf75RF WEEKEND BOX OFFICE Weekend box office charts show gross receipts for a given weekend, which is Friday through Sunday unless otherwise noted. Studio estimates for the weekend are reported on Sunday mornings, generally between 9 a.m. and 10 a.m. Pacific Time and reflect estimated Friday and Saturday box office receipts plus a projection for Sunday. As with daily box office, weekend estimates do not reflect all movies playing in theaters, but at least the Top 12 plus select movies below that may be reported. Actual weekend box office receipts are reported Monday, generally after 1 p.m. Pacific Time, and reflect most movies currently playing in the marketplace. A final update to the chart may be made Monday night or later in the week to reflect grosses that are reported late. Readers can view historical weekend box office from 1982 to the Present and have access to the weekend index, broken down by year. Readers also have access to an index by week number, showing a given week's box office history from 1982-Present. WEEKLY BOX OFFICE Weekly box office charts show gross receipts for a given week, which is defined as Friday through Thursday. This information is reported on Friday afternoons for the previous week's box office, though additional titles are added to a given week's chart at later dates to account for grosses reported late. Readers have full access to historical weekly data back to 1982 as well as an index, similar to the weekend box office index. MONTHLY, QUARTERLY and SEASONAL BOX OFFICE These sections allow readers to view box office receipts for the above time periods by Release Date and by Calendar Grosses. Monthly box office is a breakdown by month, of January through December; Quarterly box office is a breakdown by quarter (i.e., January through March is Q1, etc...); Seasonal box office is a breakdown by season. There are five box office seasons: Winter (the first day after New Year's week or weekend through the Thursday before the first Friday in March), Spring (the first Friday in March through the Thursday before the first Friday in May), Summer (the first friday in May through Labor Day Weekend), Fall (the day after Labor Day Weekend through the Thursday before the first Friday in November) and Holiday (the first Friday in November through New Year's week or weekend). Each of these sections contains an index by the specified time period, from 1982 to the Present, as well as a breakdown of time periods for a given year, from 1982 to the Present. Each individual chart shows a list of movies for a specific time period in a specific year. Both the indexes and individual charts can be viewed by Release Date for all movies, Wide Releases only and Limited Releases only, as well as by Calendar Grosses. They can be sorted by any column, adjusted for ticket price inflation and individual charts can be filtered by studio. YEARLY BOX OFFICE Readers can view the top 50 movies of a given year from 1980 to 2000 and the top 150 movies from 2001 to the Present. Readers can also view all movies tracked for these years as well as breakdowns by Release Date and Calendar Gross and can filter by studio. Readers can also view the top 10 opening weekends for each given year; readers can view all opening weekends and filter by wide and limited releases only as well as by studio. Finally, Worldwide box office by year, which shows the movies' combined domestic and foreign grosses, can be viewed from 1989 to the Present. Movies are grouped by the year they were released domestically, regardless of when they were released in foreign markets. HISTORICAL CHARTS The data on the Yearly and All Time Domestic charts can be viewed "as of" a given date in history. For example, one can see what 1999's box office was like as of May 19. Or one can see what the All Time Domestic Box Office chart looked like in 1987.

arel90 11y ago

WATCH BOX OFFICE MOVIE NOW!! Find the Film click here MOVIE FREE https://t.co/nLGLMehTaI https://t.co/nLGLMehTaI & here TV MOVIE SHOWS https://t.co/zJWRHf75RF https://t.co/zJWRHf75RF

deleted 11y ago

[deleted]

acidity 11y ago

Another one that I have used in multiple of my projects: https://github.com/mattupstate/overholt https://github.com/mattupstate/overholt

a_c 11y ago

The "Architecture The Lost Years" talk is a real gem

TeeWEE 11y ago

While flask is a nice framework, it has some problems. I worked with numerous python web frameworks, mainly webapp2 and flask. So some things i don"t like about flask: Disclaimer: You can architect beautiful apps in apps, its just easy todo it wrong. GLOBALS: Flask has a lot of globals (from flask import g, request, current_user, etc.) A better web handler function looks like this handle(request) -> response. Any other web framework that I know does it like this. Much better. Flask promotes touching the 'request' object everywhere. Example: https://github.com/lepture/flask-wtf/blob/master/flask_wtf/form.py https://github.com/lepture/flask-wtf/blob/master/flask_wtf/f.... Flask is not functional, its inherently statefull with globals. MIDDLEWARE: Flask promotes writing middleware as decorators functions, while it looks nice, it not really useable anywhere else, and its not really a standard. At least you can still use WSGI middleware. BLUEPRINT are nice, but have issues: When you create a blueprint, for a sub app, you cant set error handlers. They only work on app level. Also (small issue) You cant add blueprint specific middleware. Better way to create 'sub apps': Use a new WSGI App. Or use a sitemap where you bind functions to paths. SITEMAP @route has disadvantages For big apps, its nice to have a single routes.py file where you can see all urls the app supports, and which methods to handle those. The @route is nice to use initially, but imho for big apps it becomes messy. Also it promotes circular imports: view.py: from init import blueprint #circular import! blueprint.route('/test/') def f(): pass init.py: blueprint = new Blueprint from . import view assert view # ensure the handlers are initiallized

irahul 11y ago
Haven't used flask in some time now, but most of your objections are missing the mark. > GLOBALS: Flask has a lot of globals (from flask import g, request, current_user, etc.) A better web handler function looks like this handle(request) -> response. Any other web framework that I know does it like this. Flask's request is not global. I have had this discussion with someone else before: https://news.ycombinator.com/item?id=6662623 https://news.ycombinator.com/item?id=6662623 FWIW, flask's "from flask import request" never had been a blocker for me, whereas django's injected request variable had made me write middleware to preseve requests as thread locals so that I can access it elsewhere. Werkzeug does the same thing, except it does it more robustly. > MIDDLEWARE: Flask promotes writing middleware as decorators functions, while it looks nice, it not really useable anywhere else, and its not really a standard. At least you can still use WSGI middleware. I don't see an issue. If you can solve it using simple python(decorators), solve it using Python. > BLUEPRINT are nice, but have issues: When you create a blueprint, for a sub app, you cant set error handlers. They only work on app level. Also (small issue) You cant add blueprint specific middleware. Rather than calling app.before_request, you can call blueprint.before_request and it will work only for that blueprint. > SITEMAP @route has disadvantages For big apps, its nice to have a single routes.py file where you can see all urls the app supports, and which methods Then don't use the decorator. Have a routes.py and call app.add_url_rule I have had a template with all of this from some time back https://github.com/rahulkmr/flask-bigapp-template https://github.com/rahulkmr/flask-bigapp-template

ccanassa 11y ago

I spend the last 3 years on the microframework bandwagon, and now I am quite pleased to be back writing Django code. In my experience, any sufficiently large Flask project contains an ad hoc, bug-ridden, slow implementation of half of Django.

auvrw 11y ago

in addition to the flask documentation http://flask.pocoo.org/docs/0.10/ http://flask.pocoo.org/docs/0.10/ the snippets page is really helpful http://flask.pocoo.org/snippets/ http://flask.pocoo.org/snippets/ also, I've some boilerplate https://github.com/ransomw/catalog-flask https://github.com/ransomw/catalog-flask even though it hasn't gotten attn in a while