Discover Flask
discoverflask.com
discoverflask.com
I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't get me wrong; I love Flask. It launched me into web development with Python at a time when Django only confused me. But I just can't justify using Flask for a big project anymore when Django is just so much faster to work with (for me). If I need to, I can customize nearly any part of Django I want, store it as a project template, and use `django-admin startproject myproject --template="https://sometemplate.com/in/a/git/repo.git" ` to start a new project with it.
This exactly. Every site I've attempted to build in Flask ends up having so many dependencies for even the simplest of things. I shouldn't have to go and find what the most popular recent library for each aspect is (even if they are out there and are great). Once you learn Django, it's just so much faster to work in from the maturity of the framework itself to the docs to the community.
That said I do have one project today I keep in Flask. It's a small personal website which serves a few templated pages, has a very small content database, and just a couple API endpoints used privately. In all it may be a couple hundred lines of code.
I have also worked in flask environments, flask does have the advantage of having a bigger plugin ecosystem, and a bigger network effect (way more users!), which translate in more recipes, entries on SO, etc...
Of course, it's hard to build something like an authentication/admin interface framework without there being some standardized ORM/migration system, so the argument is more or less moot.
It was stunning that most of the solutions out there rely on some sort of a hack to get it working. I ended up porting over my project to Tornado, because I need websockets for a lot of the features I'm working on. And it worked out really well, especially after I combined it with SQLAlchemy and Alembic. 80% of the feature set right there. And SQLAlchemy is such a fantastic toolkit.
I'm hoping that django channels (http://channels.readthedocs.org/en/latest/) stabilizes soon.
Of course, native support for long-lived connections in Django would be cool, if only because it would mean the connection management layer could be built with Django too.
There are just so many apps that end up requiring queries complex enough that with the Django ORM you have to resort to raw SQL. With SQLAlchemy, you can express any SQL you want without giving up composition.
After that you can use SqlAlechemy as a side channel, just like a lot of people use NoSQL databases.
(As an aside, for very crud-heavy applications that are client-heavy with primarily JSON data endpoints, I suggest using PostgREST if possible. It is almost certainly going to be better than any CRUD API you produce yourself)
If your application is mostly endpoints that do "interesting" stuff, you aren't going to hit much of the Django infrastructure, and piece you are most likely to hit (the ORM) is so far behind the dominant Python ORM (SQLAlchemy) that it is just painful.
Flask is a lot better at getting "out of your way" than Django. The main problem I see with flask is that it isn't obvious to people picking up the library the right way to structure and scale an application code base.
I wholeheartedly agree! Do you have any resources in mind (even perhaps not specific to flask) that you think would be useful to people hitting that wall?
I'm also planning to write a series on how to build a simple SAAS with flask, hope some will find that interesting.
It would be so much simpler to just have a request argument passed to each view.
Dynamic scoping would solve this problem (and similar problems, like dependency injection), but Python doesn't have that.
Flasks way emulates it as well as possible.
Anyway, great content for Flask beginner. It's a wonderful framework for anybody wanting to write clean APIs and it's this kind of content that makes the community awesome.
http://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-...
I've also recently been using Django, and I'd say the biggest advantage of Flask is simplicity.
When you get to something the scale of Django, there's a whole load of decisions and culture baked into the approach, and you have to learn that in order to use it.
For small projects, I'd recommend Flask.
Flask is a micro-framework, but it's not a toy framework (anymore). I've used it professionally for all web related projects big and small for the last 4 years with great success. I wholeheartedly recommend it. It's not for everybody though, as one can attest by various comments lamenting its minimalist approach. Things that attract someone like me who likes a certain degree of control on how my tools are set up and work, may be the same that repulse someone else more concerned with having everything available in the kitchen sink.
When I moved to Python for web development Django was the most common recommendation. I had toyed with it a bit previously and considered settling for it. Amid the raves though were a few complains that gave me pause, most coming from experienced Python programmers. A common remark was that as time went and as they evolved with the framework, it wasn't uncommon to swap parts out of it for external libraries. SQLAlchemy, WTForms, Jinja2. In some case basically ending with only the routing module and the admin. Which raised the question of the relevance of using a full-stack framework not necessarily designed with interchangeability in mind, if you end up just using it like a glue mini-framework. Having worked with full-stack frameworks before I identified with the highlighted pain points and Flask became very attractive. I picked it up for a first project and never looked back. It's been over 4 years now. It's entirely possible that I'm missing out by not working with something more like Django, although I doubt it very much.
Flask itself is small, made of bits of the Werkzeug WSGI toolkit and the Jinja2 template engine. It's simple in concept, simple to set up, and simple to use, but anyone who's been developing with it for anything more than basic projects (static sites, microblogs, etc) knows that to do more complicated stuff than displaying template pages you will need to add some dependencies (as it should be). You can do it the old-fashion Python way, by simply importing modules and working with them, or you can install an extension. There's currently a great variety of extensions, the official list is here http://flask.pocoo.org/extensions/, with lots more available from Github and PyPI. Furthermore it's dead simple to make your own if you're not satisfied with the offering. All of this is probably the reason why 5+ years after its creation you see a good number of guidelines on how to work with it for ambitious web projects.
As someone who procrastinates on their own blog to teach people this topic, this is going to inspire my direction a lot.
I haven't used meteor, but I have used a few other JS frameworks and libraries on the backend. My major criticisms of JS on the back end are: they like magic, in that they tend to decouple code to the point that there's no way to trace the code. Instead, pieces are structured and tied together by convention, i.e. thingController goes with thingModel, and stuffController goes with stuffModel. It creates terse code, but a) if you need to do anything slightly unique (and you will) you're screwed, b) it's a huge pain to debug and trace because you can't just read function calls, and c) since the JS world doesn't care about reverse compatibility, you have to always know when the convention changes, and if you fall a few versions behind, you're basically stuck there. In particular, Ember.JS gave me PTSD. Meteor may avoid some of these issues, but when I evaluated it a while back it didn't seem like it did.
all that aside, i like Flask a whole lot. Proxy objects are brilliant, and i wouldn't be surprised if koa.js was partially influenced by Flask. i'm considering going back and fiddling w/ Sinatra for the project after next as i'm given to understand that it was a partial inspiration for Flask's routing.
all in all, there's a lot of cross-pollination. i suppose jquery + html -> frontend framework (angular, marionette, etc.) -> express.js + sequelize/bookshelf -> Flask + SQLAlchemy would be a pretty smooth transition w/ lots of docs, stack overflow, community, and sample code to help out.
Sharing logic between client and server side means that your client and server side don't have clearly-defined responsibilities. The one exception to this might be input syntax validation, but generally that's a place where you don't want to roll your own anyway.
i guess a better thing to say is "exactly": specs often change and responsibility gets shifted around. so "runs everywhere" can be useful, whether it be js or otherwise.
You're forgetting the first rule of optimization: profile.
JavaScript has a coherent design specially if you're using ES6+ in strict mode with a linter. Modern JavaScript is a great language, and comparable to Python.
Some stuff is broken in the ecosystem. That's true of all ecosystems. If you're coming from the JS world it's far, far better. But if you are importing every 0.x versioned library that vaguely solves a problem close to your problem, no ecosystem will save you.
Python is a solid choice of language for the back ends of web applications.
With caution advised when it comes to scaling. You might, or might not, pay a pretty hefty premium in the amount of hardware needed.
My experience has been that Python will give you more than enough rope to hang yourself with, and lots of apps that are meant to scale have some homegrown crap of an architecture, or people try to get fancy when they don't need to and try to write go or scala in Python.
If you have a clear understanding of your data model, Python backends scale quite well vertically. Run one instance of your app per core you have available and use IPTables to round robin (or whatever. you can get fancier if you feel like it) to each app instance. Boom. You are now banging on all 4 or 8 or however many cores your server has without the context switch overhead of the multiprocessing module and also without the headaches that go along with the shared memory space of the multithreading libs. Not to mention cleaner, nicer code.
If you build your product to work well in this way, then scaling horizontally also becomes a non-issue as far as Python code is concerned. You just put haproxy in front of multiple machines, set up health checks, and for the vast majority of use cases, you're done until you need to scale the storage horizontally. Then you have some serious decisions to make. But that's a different topic.
But back to my original point: every case where I've seen Python being all slow has really been an artifact of a crap architecture, or bolting on crap front end frameworks, or depending too much on an ORM like SQLAlchemy without really understanding your data and depending on it to do everything for you instead of thinking rationally about what your data is. Or some combination of all three above.
Yes, I know that there are languages that execute much faster than Python. I work with C#/.NET/SQL Server almost as much as I use the Python/Pyramid/PostgreSQL stack. I can write a crappy, slow, messy architecture on either stack. And in fact, when I was first getting to know C# and still writing Python code in that language, I did that.
The bottom line is that if you understand the strengths, weaknesses, and idioms of the language you are working with right now, almost every high-level language in common use today is sufficient for massive-scale deployments for the most common types of web apps. Heavy computing or scientific purposes obviously excepted. But most web apps that scale to hundreds of millions of users are basically "window-on-data" type applications.
I can't really think of a case where some other language besides Python would be noticeably cheaper hardware-wise.
Maybe you have to know your entire stack a bit better if you want scalable Python apps, maybe you have to do a little more Jiggery-Pokery with your Linux servers, but if you are serving at massive scale, you are going to have to go there anyway, especially when you start dealing with storage. That's part of the game.
But if you're using Flask and you have 4 cores with 4 instances, and you're making 4 database requests at the same time you're whole application is suddenly locked. And it's not uncommon for a single view to make up to 4 separate database requests. Most modern web applications are I/O bound, therefore a single Node.js process would have better performance here.
I agree that this could be a problem in theory. In practice, it has not been. Again, it boils down to how you architect your code.
EDIT: you need to stick your sessions to a specific instance. Otherwise, you are correct that there's a problem. But as long as you stick your sessions, there's no problem with a database lock.
Not sure what you are getting at here.
If you are talking about the raw scalability of your database, yes, you are correct. The speed with which you are able to get info from your DB will be a limiting factor.
But that's a totally different point than the one I was making, which was about how to scale Python, not your database.
If I understand you correctly, the time spent in retrieving stuff from your database will be a limiting factor no matter what language you are using. The DB I/O will eventually limit C# or go or node.js or whatever. I really don't see how this is relevant.
But since you brought it up, you can really cut down on data access times by relying less on ORMs and getting your fingers dirty with stored procedures and building tables that make sense to SQL instead of pretending everything in your RDBMS is a class.
Okay, my experience differs. Most modern web applications are relatively lightweight, and are mostly "proxies" or thin wrappers between the load balancer and the database.
I can't see even a slow interpreted language being unable to process 100 requests/second. That leaves like 40 million clock cycles per request. Especially since they tend to come with built-in bytecode compilers, and most of the pure algorithmic code is written in C. Most web requests just don't take that much work to answer.
Most performance issues I see with web applications are somebody writing ORMTable->find(x) in a loop or the equivalent, and then papering it over with a cache(or 3). Or memory leaks. Or badly-written SQL queries(no index, too many indices, disabling seq scans, using CTEs to elegantly 'refactor' SQL, etc.). Or doing blocking calculations/service requests as part of the original web request. The underlying language is almost never what's holding them back.
Of course, at megascale these optimizations might still not be sufficient, but there is no reason you can't deliver hundreds of thousands of requests per second very affordably with a python stack.
I've been hearing that for a long time...
Well, not that doing so is a bad thing - it's the contrary, esp. if the patch goes to the upstream - but still this may be frustrating to some.
(Most common libraries are actually work pretty well with Python 3. But there are still a lot of stuff PyPI that's Python 2-only at the moment.)
I do run our requirements.txt through https://caniusepython3.com every few months though.
Then there's a bunch of deployment tools like ansible, fabric, and marionette which don't really need to be python3 compatible for use.
Then there's tools like MySQL-python, python-gflags, python-cjson, INITools, filechunkio, which have python3 compatible alternatives, often in the standard library.
That brings the total up to 331
That leaves basically 3 categories of things left: mozilla tools, database connectors (many of which probably have python3 bindings though I haven't looked), and single sign on tools. Those account for 12 of the remaining 29 libraries.
That's pretty ready.