When I started my deep dive into coding, there were a lot of things that I heard of before but never knew how do they work or what do they mean. One of such things was frameworks.
The framework is just a fancy word for something similar to a LEGO constructor. You can be very experienced with any high-level programming language, master data wrangling, be good at plotting, etc. However, the question emerges when you need to present your work, or even further — your project needs to communicate with a backend or a frontend for a better user experience. You cannot provide .ipynb notebooks to the user and say: “hey, change parameters here and there, and then run the cell with prediction function” — chances are they will be lost.
Therefore, we need a web-hosted vehicle that will engulf all of the python code and make it possible to take data in and spit data out. That what framework is, in a nutshell.
Need to mention, that Flask is also friendly with plotly.dash meaning that any python-plotted graph can be easily displayed on your web app.
However, there are some negative aspects of using Flask that I faced working with it. First of all, inconsistent stability. Flask likes to complain about different things, it is very sensitive to the directory from where you attempt to run it. There are certain limitations in file naming, you cannot name any of your files flask.py — which is a minor problem.
The major one is slow speed. Flask API will be much slower at work compared to alternatives, which is a big disadvantage if your web app is actively used. Another big thing is that the project is inseparable. In other words, the Frontend development team might experience some hardships trying to make a traditional web UI for a Flask app. Building something big on Flask API would certainly be a challenge.
Much later, I joined a team building a project using FastAPI. FastAPI is a relatively new framework that is skyrocketing in popularity nowadays. At first glance, I did not like FastAPI — it seemed to be overly complex.
Yet after some time spent with FastAPI documentation, things became clear for me and I started seeing the advantages of using FastAPI.
FastAPI is really fast — at least, works faster than Flask due to the Starlette toolkit under the hood and ASGI. At the same time, FastAPI is just a backend API. It is a tool you would use for one purpose only — like a bottle opener. You cannot call it a multitool, but it does its one job very well. And its job is to reliably capture input data through the ‘GET’ route, do some operations using Python/SQL/Machine Learning, and output it through the ‘POST’ route. More importantly, FastAPI readily serves return data in JSON format which is a grab-n-go for the web development team.
It is not necessary to have all the routes in the same file. For example, the code below will take routes from all the listed files and output them on the front page of the web interface under corresponding tags:
app.include_router(db.router, tags=['Database'])app.include_router(ml.router, tags=['Machine Learning'])app.include_router(viz.router, tags=['Visualization'])
In my experience, FastAPI is much more stable. I had much fewer errors while launching the application compared to Flask. Bad luck?
Even though FastAPI is a very technical app, it is still a good-looking API with an automatically-created schema that makes it easy to use it for Frontend and DS/Backend. Documentation and directions on how to use routes can be printed on the front page.
The answer is: depends on the scale. For a small project that you want to do yourself, Flask is generally a better option — it’s better to have some user GUI than nothing at all. It is still possible to do the large project with Flask, however, you would have to solve a row of problems such as converting final data to a JSON object, fast response issues — especially if you have a machine learning application that takes time to output results. I am working on another project at the moment that is built on Flask. This project does not have any complicated machine learning system built-in, it is not meant to handle a lot of requests, neither it needs a superb frontend page. For such a case, Flask is more than sufficient.
My previous project involved multiple teams such as iOS, Web, and Backend. We all coded in different languages, used different frameworks, had different user stories to cover and solve problems related to these stories. This is how it all supposed to interact:
My choice fell on FastAPI and I do not regret it. FastAPI allowed the DS team to work on our relational database and model separately from others without interfering with their files, and then seamlessly connect to the Frontend part through endpoints. Regardless of what the web team picks and how they build it — this would still work with FastAPI.
This is how our backend looked like:
While dealing with routes, there are some things to consider:
1. Multiple routes. In our case, we had just 1 POST and 1 GET route. However, different data requests can be separated into different endpoints, upon agreement with the web dev team.
2. At least 1 GET and 1 POST route. If the data is coming in and exiting out, there is a way to make everything working within 1 POST route. However, it is a bad idea simply because you will not be able to test your input data otherwise.
I really hope this information makes it clear which one is better to choose: Flask or FastAPI.