Comparing Django, Flask, FastAPI and ASAB
In this simple overview, I would like to introduce you to four frameworks, which can be used for creating a web server application. Such an application should be able to provide a REST API interface for communicating with a client or frontend application served in a browser or defined in another service, while reading and writing objects in a database. For the sake of performance, the database should mostly be no-SQL, document based, because we are using Python with its powerful optimized dictionaries and any ORM technology, that would translate objects to SQL tables, would just implicitly slow down the performance.
First two frameworks are multithreaded. It means that for almost every incoming request a new thread is utilized within the processors’ core to handle the user request, that is the call to the REST API. It is an older, yet still widely used approach, that unfortunately does not scale well for highly utilized servers, since the number of threads is dependent on the number of processor cores and so on. However, for most cases the approach may still be valid, though for new applications I would recommend using the asynchronous approach, which is specifically designed to handle IO-bound problems, as I have written in some of the previous articles.
There may still be advantages to using the frameworks based on the multithreading approach, especially because of their wide use, community support and architectural patterns. One of the most commonly used Python web server frameworks is called Django, which is based on MVC, model, view, controller, or MVT, that is model, view, template pattern. The model is a part of the code to work with the data or database, the view provides the routes or handlers of different URLs in the REST API and the template defines the content, which can be the frontend page served to the user’s browser. Django comes with lots of native features, like custom ORM connectors being able to connect to multiple databases, its own templating language, multiple sub-applications and so on.
|
1 2 3 4 5 6 7 8 |
import flask app = flask.Flask(__name__) @app.route("/") def hello_world(): return "<p>Hello, world!</p>" |
The second framework called Flask is much simpler and easier for developers to understand at first. Flask is meant to be used not for complex applications such as Django, but really for microservices with only one application object and few routes, that are defined simply using decorators. If more features are needed, usually separate Python packages must be installed, like, if ever you wanted to use ORM and so on. The microservice architecture allows much more scalability, because the application can be run in multiple instances easily, especially when using containerization technologies such as Docker with some orchestration like simple Docker Compose or advanced Docker Swarm Mode or Kubernetes. The following frameworks, that I am going to mention, are more similar to Flask than to Django, exactly because of their inherent expectation to use the microservice architecture.
Asynchronous frameworks are based on a so-called asynchronous loop, that usually processes a part of the user request, then switches to another request (when, for instance, a query to the database is run in the first one), the back to the first one, returns the response, then to the second one, third one and so on. The alternation is what gives the asynchronous approach its power, because from the external view it seems that all requests are always handled in parallel regardless of the processor’s assets. However, it also requires more thinking when writing the code, like not writing long parts of code that are synchronous, that is, not separated by await statements, and avoiding CPU-bound tasks by manually pushing them to thread workers that have an asynchronous interface. This may sound fuzzy at first, but from the practical perspective it is always just one or two lines of code that do the trick.
|
1 2 3 4 5 6 7 8 |
import fastapi app = fastapi.FastAPI() @app.get("/") async def root(): return {"message": "Hello, world!"} |
The first asynchronous framework called FastAPI looks very similar to Flask in the definition of the application and routes. However, the handler functions wrapped in a Python decorator can be coroutine methods, defined by async def, right away. FastAPI allows us to utilize the MVC architecture, if needed, and even provides tutorials on how to do it. The framework natively provides documentation in OpenAPI as well as the second one called ASAB, that I helped to create myself.
The routes in ASAB are defined through aiohttp native Python 3 package for asynchronous web server communication. Instead of MVC architecture, ASAB utilizes the handler-service architecture, where the handler is similar to the controller and the service to the model. ASAB is more meant to be a boilerplate for all kinds of microservices, that is why the web module is just a part of the framework next to publish-subscribe mechanism, tenants, ElasticSearch connector, metrics, ZooKeeper connector and so on, that are more useful in the real-time data processing and cyber security area than in web application development.
Django: https://github.com/django/django
Flask: https://github.com/pallets/flask
FastAPI: https://github.com/tiangolo/fastapi
ASAB: https://github.com/TeskaLabs/asab
