Yes, you got that right, this is yet another text comparing two similar frameworks which are pretty solid, well known, and have a large fan base everywhere. So, why bother?
First, and most importantly, this is my page and I choose what I write here we eventually are faced with that sort of comparison in our daily lives as software engineers, and sometimes we need to have some ground reasons to write technical documentation.
What is Flask and FastAPI?
Basically, both are lightweight web application frameworks for Python. Probably you already knew that right?
Let’s start talking about FastAPI.
The first contact I had with FastAPI was a few years ago and it was an existing company project which did not use all the features the framework offered. It has been noticeable how much has changed in those couple of years during the last time I tried to build something in the FastAPI a few months ago.
FastAPI has a lot to offer if you plan to build microservices that may use some famous python ML and DS libs like Pandas, SciKit Learn, NLTK, TensorFlow and Pytorch ( because it is for python ) due to some important features:
- Async - it has full support to async calls and that makes a huge difference in performance when well used.
- Pydantic - it has full integration with Pydantic, and this is a game changer in terms of handling incoming and outgoing data from your endpoints.
- Automatic documentation - it exposes a swagger ( or OpenAPI ) out of the box for your endpoints.
- Dependency injection system - this one is not very trivial to explain, but it will grant your app a better way to design tests and probably reduce time for some code refactoring in the future.
Now, regarding Flask.
I have been using Flask for the last 2 years of the creation of this Post. Unfortunately, I started with version 1.x and just recently moved to 2.x, so this means I had not that long time to play around with Async.
That said, this is probably the most unopinionated framework for web development out there. You will have to install a separate lib for practically everything you want to deploy here, even for REST APIs, but you will have the most control over your application architecture and design ( for good, or for bad ).
Besides async support since version 2.x, Flask also has decent unit testing support, built-in support for the session and request objects, an intuitive way to store objects to be shared between multiple requests, and a lot of plugins.
The Monolith Case
A very common misconception about system design is that every system must be a microservice or will eventually become one. This is what we usually see in all modern products that (guess what) sell solutions for microservices: if your app is successful and grows exponentially, you will eventually switch to microservices.
But here you must notice that not every system is designed for millions of users, for example. Also, despite reading that testing is easier in the microservice architecture because each component has a more limited scope, now I see this is a huge mistake. This is true for unit-testing your microservice, but a whole test that verifies if your whole system is doing what it is supposed to do (which is what the paying customer is really interested in) becomes much more complex.
So, monoliths have the great advantage of being easier to test and also to be understood, which is a far better option for starting projects. There is this great post from Martin Fowler discussing why monoliths still matter.
If you choose to start with a monolith, Flask will likely be a better option for you, because of all the plugins and support for the front end ( it has a nice integration with Jinja2). Since you will only add the components you need, your application will be very light, and exactly for this reason you should keep track of what you install to avoid wasting resources.
The Microservice Case
On the other hand, we have the design for mature systems which already have a significant number of users and have to switch to microservices for scalability issues. There is also the case of parallel services, not directly related to the core business of the company (usually DataScience and DataEngineering stuff), which are usually more dependent on your cloud provider and naturally can be deployed as microservices.
Considering you already weighed the pros and cons and decided to go with microservices, FastAPI will probably offer you more resources for faster development.
Conclusion
This is an opinionated article and as such, you might not agree with the view of the author. For me, FastAPI has a slight superiority compared to Flask for developing microservices, and slight inferiority for developing monolithic applications.
But naturally, no one knows how their product will evolve. So here is a good rule of thumb to make this decision: if you are building a pilot or proof of concept, preferably go with Flask, unless your application is already doing a very specific function and already has some other parts spread in other cloud services (like authentication, another application that your product will assist or provide extra functionality, existing single or multiple databases that are being populated by other sources, etc).
FastAPI is an amazing silver bullet for specific functions, for example, those performed by data scientists that feed on existing multiple databases and generates a result “marginally” to the core business of the company.
If you are starting a project but you already know eventually you will write additional modules to it to add extra functionality, even if you expect a large number of users, go with Flask and build a beautiful monolith that will save you hours of debugging and configuration time.
Bear in mind that even if you eventually decide to move to microservices, you are not required to transform the whole application to microservices at once, but perhaps just some critical parts of it that are impacting your performance. And if that happens, you can easily pick FastAPI for that new repo.
