Django vs Flask vs FastAPI

Over the 16 years that this blog spans I must have, at some point, mentioned that I believe sometimes we get knowledge when we’re not ready to receive it.This isn’t some spiritual or new age thing (although you’ll hear Chopra and/or Tony Robbins talk about the phenomenon). It’s simply my lived experience. Sometimes you come across some knowledge, but there’s some underpinning knowledge missing or maybe some life experience you don’t yet have to put your new knowledge into context. So sometimes this leads to a difficulty in learning the concept and other times you just don’t get the point of it and file it away or throw it away - no need to waste neurons on this!

The same thing has happened to me with Python and Web Frameworks. I already mentioned this a bit in my March 2021 Programming update. But I wanted to elaborate on it in its own blog post. A bit of background - back in the late 90s and early 2000s I created lots of web pages using HTML and, sometimes, a bit of Javascript. Right around the time of HTMLX and other initiatives to get the web to be more interactive (what would eventually lead to Web 2.0 within a half decade), I moved on to using blogging platforms and mostly left web programming behind. Sure, I did a couple things here and there like my Vietnamese Zodiac page (which, at one point, was getting tons of hits on Google), but mostly I left the web behind. Some time in the last 5 years (or maybe more?) I looked at both Django and Flask, but found them inscrutable. Django, especially, just seemed overkill and a huge learning curve just to get started. I left them behind and continued to create command line and GUI programs (mostly with PyQT bindings).

About 3 or so years ago someone from work approached me asking about a way to automate a part of his spiritual practice. It would clearly benefit from a web interface, but I remembered things being too hard with Flask and Django. Then COVID happened and I had lots of free time to learn things. I took a look at the books and videos I’d bought from various Humble Bundles. I tend to learn best from curated experiences like books and classes as opposed to just reading framework tutorials. I had a video class from Pakt focused on using Flask to create an API-based site. This would be one of the most common workflows in modern web design: an API backend written in Python, Ruby, Go, or Java interacting with a front-end written in Javascript. With this class as my guide, Flask finally made sense. I understood what routes were and how they interacted with the user. I gained a better understanding of how to write a site that would interact with a database. This was great! After taking the class I started working on my colleague’s site. After I had the database schemas set up, we started discussing the user workflow he anticipated. There was a lot of admin backend to construct and, once again, I stopped writing websites back before CSS and all that. Also, unfortunately, the class was focused on an exceedingly simple website and I used the Flask tutorial to try and shore up how to handle user logins and so forth, it all started getting way too complicated. I lost interest and the project floundered.

Then, for some reason - I think I was flipping through my Python books - I decided to look at one of the Django books and found that Django comes with an admin interface built-in. And making changes to the admin pages are somewhat trivial. I was rejuvenated in my desire to help my colleague. So I started recreating the site with Django. There is indeed still a higher cognitive load to Django. The simplest Flask site with its app.route is still infinitely simpler than Django with its views, models, forms, settings, etc. And yet, if you’re already going to go for a more complex site and do your user interface in Python, suddenly all that complexity pays off. The ability to set up your models and forms with ease makes a model-heavy workload so much easier. And I had a better understanding of what all this meant now that I’d work on Flask.

What I find most interesting, and what led me to write this post, is that I recently got O’Reilly’s Flask Web Development from another Humble Bundle. Just as having worked on Flask helped me better understand what Django is trying to do, having worked on Django is feeding back into helping understand Flask. Having worked with models and forms in Django has cemented in my head how web backends (particularly if written in Python) are thinking about the web and separation of concerns; it’s all forming this virtuous cycle. And so while I anticipate perhaps having some momentary screwups where I try to think Flask-y while working Django or Django-y while working on a Flask site, each is helping me become a better Python web developer no matter the framework being used.

So, to the implicit question in my blog post (assuming you’re still reading after that preamble of sorts), I think you’ve probably guessed by now that I’m not an absolutist when it comes to these major Python web frameworks. Django, as I recently learned, was born to power a news website when the idea of a CMS was in its infancy. If you’re looking to create a website with a Python backend that needs a strong admin interface, strong database dependencies, and a more batteries included workflow - you’re going to want to use Django. If you just need an API that’s going to interact with mobile apps or Javascript, then (at my current level of understanding) it’s a toss-up between Flask and FastAPI. I think MOST apps nowadays use a database of some sort, but if you’re not using one, then you’re definitely better off using Flask or FastAPI instead of Django. They’re both barebones with a lower cognitive load to get started. Flask is older and may have more plugins and add-on packages to help with features you might want to add on. FasAPI is newer and Async native as well as getting some input validation “for free” thanks to Pydantic. It also has a really easy way to write Pytest Unit Tests. It’s almost too easy! FastAPI’s website maintains a page comparing it to alternatives as an explanation of why the original dev put it together. It seems written in a fair manner although it’s obviously going to be at least slightly biased in favor of FastAPI. As I said, I am just a baby dev when it comes to Python web frameworks, so I’m not the best person to comment on when to choose Flask over FastAPI, but I’d probably lean towards the latter if I were starting a site fresh. It really does a lot of great things with JSON automatically and is self-documenting.

The important thing is not to be dogmatic about things. There are occasions where each is best. I LOVE FastAPI for my Civilization VI Play By “Email” webhook server. As I spent lots of digital “ink” above describing, Django works perfectly for my colleague’s web app. Using Django freed me from coding and maintaining all the admin code and database handling. And on the other side, my webhook server just needed to have some REST API points. Even if I eventually add database support, I still don’t need any kind of admin or real user account service with that app. So when you’re ready to write your next Python web app, think about your needs and think about what the strengths and weaknesses of all the frameworks are.

• Django
• FastAPI
• Flask