Le flacon est-il mort ? FastAPI est-il l'avenir ?

Lors de mes recherches pertinentes, j'ai remarqué que même en 2024, un certain nombre de personnes recommandent encore Flask comme framework web Python. Cependant, à mon avis, "Flask est en voie de disparition et FastAPI représente l'avenir". C'est pourquoi j'écris cet article. J'invite tout le monde à se joindre à la discussion et à proposer des contre-arguments.

Flacon et FastAPI

Flask occupe une place importante dans le cœur des développeurs Python. Si vous êtes un développeur Web, je parie que vous avez probablement utilisé Flask, mais peut-être n'avez-vous jamais essayé FastAPI.

Voici deux éléments de preuve :

1. Dans les nouveaux projets Python importants liés au développement Web au cours des deux dernières années, presque tous ceux qui impliquent le développement Web ont adopté FastAPI.
2. Au 25 décembre 2024, sur GitHub, le nombre d'étoiles pour FastAPI (78,9k) a déjà dépassé celui de Flask (68,4k).

Jetons maintenant un coup d'œil à l'évolution de la proportion de frameworks Web dans les enquêtes officielles des développeurs Python.

Il est évident qu'en 2019, FastAPI n'était même pas répertorié comme une option, pourtant en 2023, sa part avait atteint 25 %. (Actuellement, nous ne disposons que de données jusqu'en 2023.)

Il convient de noter que ces données de proportion englobent les systèmes existants, donc les proportions de Django et Flask ne baisseront pas rapidement. Néanmoins, la tendance est claire.

Nous savons tous que le domaine des frameworks Web est très prolifique, avec de nouveaux frameworks émergeant presque chaque année. La plupart de ces cadres sont de courte durée, tandis que certains parviennent à perdurer. FastAPI est né fin 2018 et a commencé à se faire un nom vers la fin 2019. Alors, comment pourrait-il dépasser Flask, né fin 2010, en termes de popularité en seulement cinq ans ? Ensuite, traçons l'historique de développement des frameworks Web Python et des solutions associées tout au long de la chronologie pour une meilleure compréhension.

L'évolution des frameworks Web (plugins, outils)

L'auteur de FastAPI est un développeur qui porte une attention extrêmement particulière au développement de l'écosystème Python. Le lien de lecture étendu 2 est "Alternatives, Inspiration and Comparisons" écrit par l'auteur (https://fastapi.tiangolo.com/alternatives/), qui développe en détail les références ou inspirations que FastAPI a tirées de diverses bibliothèques. La section historique du développement de cet article fait également référence à cet article. Je recommanderais de lire le texte original, car il contient la justification de l'émergence de FastAPI ainsi que certains des concepts de conception de l'auteur.

Ballon

Flask est un framework "micro", qui est aux antipodes de Django. Il ne conserve qu'une poignée de fonctions principales et, pour découpler, divise les autres fonctions en plusieurs bibliothèques (telles que Jinja2, Werkzeug, etc.). Cela donne aux développeurs une grande liberté et leur permet d'écrire sans effort des plugins tiers pour des fonctions associées. Ses conceptions internes telles que les plans, les contextes et les décorateurs pour représenter les itinéraires, les signaux, etc. étaient assez avancées à l'époque. Associé à une documentation complète, il est extrêmement convivial pour les débutants.

Cadres REST Flask

Grâce à sa simplicité, Flask est parfaitement adapté à la création d'API. Cependant, comme Flask lui-même ne comporte aucune fonction intégrée, nous avons besoin de frameworks REST spécialisés. Par conséquent, des frameworks tels que flask-restful, Flask-RESTPlus et flask-api ont vu le jour les uns après les autres. De plus, dans les services REST, il existe des exigences en matière de validation, d'analyse et de spécification des données, ce qui a conduit à l'émergence de Marshmallow, Webargs et APISpec, jusqu'à l'arrivée de Flask-apispec. Cependant, tout au long de ce processus de développement, un framework Flask REST comparable au DRF ne s'est jamais matérialisé.

À ce stade, les défauts de Flask sont progressivement apparus.

Les atouts originaux de Flask résident dans sa flexibilité et son minimalisme, mais cela signifie également qu'un grand nombre de composants doivent être développés en interne. Cela nécessite soit une grande entreprise avec des développeurs dédiés au développement et à la maintenance, soit des développeurs individuels extrêmement compétents. Sinon, il est difficile pour les plugins d'atteindre la qualité de production, ce qui entraîne un mélange de plugins tiers pour Flask, sans garantie de maintenance à long terme. Comme mentionné précédemment, bon nombre de ces bibliothèques ont déjà cessé d'être entretenues.

Donc, même aujourd'hui, si vous souhaitez créer un service API avec Flask, vous devez toujours assembler différents composants. Pour certains composants qui n'ont pas été mis à jour rapidement, vous devrez effectuer le dépannage vous-même. Les vétérans seront peut-être capables de le gérer, mais pour les débutants, c'est plutôt intimidant, surtout lorsqu'ils veulent appliquer les dernières pratiques et concepts.

L'écosystème Asyncio

Depuis Python 3.5, asyncio est la tendance future. En conséquence, certains frameworks Web prenant en charge nativement asyncio ont vu le jour, tels que aiohttp, Starlette et sanic.

À cette époque, Flask était réticent à s'adapter. La communauté a mis du temps à ajouter la prise en charge d'asyncio, et l'auteur original de Flask est passé à l'écriture de Rust, laissant le projet entre les mains de deux responsables (il n'en reste plus qu'un).

Les projets de création de services API, comme apistar et molten, ont tous inspiré la conception de la naissance de FastAPI.

API rapide

Puis, FastAPI est né. L’auteur cherchait à l’origine une bonne solution, mais les situations ci-dessus présentaient chacune leurs propres problèmes ou limites. Ainsi, l'auteur a créé ce nouveau cadre.

Pourquoi FastAPI se démarque

C'est la partie centrale de l'article. Les raisons suivantes expliquent précisément pourquoi FastAPI peut remplacer Flask.

Validation des données utilisateur avec Pydantic

Dans le processus de développement de l'API, la validation du format des données, l'analyse et la sérialisation sont des opérations de routine. Au fil des années, plusieurs solutions ont vu le jour, et actuellement, Pydantic est le premier choix :

from fastapi import FastAPI
from pydantic import BaseModel


class Item(BaseModel):
    name: str
    description: str | None = None
    price: float
    tax: float | None = None


app = FastAPI()


@app.post("/items/")
async def create_item(item: Item):
    return item

À première vue, ce code peut ressembler à une manière d'écrire ORM ou dataclass, mais en fait, il utilise la syntaxe native Type Hints de Python pour annoter les types de champs. Par exemple, dans l'exemple ci-dessus, le schéma de l'élément dans la requête /items/ a été clairement défini et les types de valeur de chaque champ sont explicites. Par rapport aux anciennes méthodes d'utilisation des descriptions de schéma ou même du codage en dur, cette approche est plus concise, plus conforme au style Python et offre un meilleur support IDE.

Actuellement, Pydantic domine le domaine de la validation des données utilisateur. Puisque FastAPI l’a intégré, le processus de validation est considérablement simplifié et les erreurs sont réduites. C'est pourquoi le site officiel de FastAPI mentionne que cette solution peut réduire jusqu'à 40 % les erreurs des développeurs. Pour un langage dynamique comme Python, l'application de Pydantic est essentielle si vous n'utilisez pas mypy pour la vérification de type.

De plus, grâce à l'intégration de Pydantic, ajouter un ORM (comme SQLAlchemy) au projet devient extrêmement simple. Les objets obtenus à partir des requêtes peuvent être directement transmis à la base de données car la validation des données est déjà terminée. Vice versa, les objets récupérés de la base de données peuvent également être directement renvoyés.

En revanche, Flask manque à cet égard.

Conception asynchrone

À l'ère de Flask, l'exécution du code était monothread et synchrone. Cela signifiait que les requêtes devaient être traitées une par une et que les autres requêtes perdaient du temps à attendre les opérations d'E/S avant que la précédente ne soit terminée. Asyncio, en revanche, est la solution optimale. Il peut rendre les opérations d'E/S asynchrones, vous permettant d'obtenir les résultats des tâches sans attendre la fin des tâches, puis de traiter d'autres demandes de tâches.

FastAPI prend en charge nativement le code simultané et asynchrone. Tant que le code est écrit correctement, il peut atteindre une efficacité maximale. Par conséquent, il est actuellement considéré comme le framework Python le plus rapide, avec une efficacité similaire à celle de NodeJS ou Go. Lorsque la vitesse et les performances sont essentielles, FastAPI est sans aucun doute le meilleur choix.

Prise en charge native d'ASGI

Mentionnons d'abord WSGI. Son nom complet est « Python Web Server Gateway Interface », auquel on peut faire référence dans « PEP 3333 » (https://peps.python.org/pep-3333/). Il s'agit d'un standard Python écrit spécifiquement pour l'interaction entre les applications Web et les serveurs. Si vous avez utilisé PHP ou Ruby, vous trouverez peut-être cela plus facile à comprendre. Flask dépend de Werkzeug, qui est une suite WSGI, donc Flask prend en charge cet ancien standard WSGI et non ASGI.

Le problème avec WSGI est qu'il ne peut pas exploiter l'asynchronie pour améliorer les performances et l'efficacité. Ainsi, la chaîne Django a été la pionnière d'ASGI. Son nom complet est « Asynchronous Server Gateway Interface », qui est une norme itérative et presque entièrement repensée. Il fournit des interfaces serveur/application asynchrones et prend en charge HTTP, HTTP/2 et WebSocket. Contrairement à WSGI, ASGI permet à chaque application d'avoir plusieurs événements asynchrones. De plus, ASGI prend en charge les applications synchrones et asynchrones. Vous pouvez soit migrer les anciennes applications Web WSGI synchrones vers ASGI, soit utiliser ASGI pour créer de nouvelles applications Web asynchrones.

Avant de tirer des conclusions, ajoutons cinq explications de termes :

1. ASGI Toolkit : bibliothèques qui implémentent des fonctions liées à ASGI (telles que le routage d'URL, les objets de requête/réponse, les moteurs de modèles, etc.). Dans cet article, il fait principalement référence à Starlette, qui correspond à la dépendance de Flask, Werkzeug.
2. ASGI Web Framework : frameworks Web qui implémentent la spécification ASGI (comme FastAPI), tandis que Flask et Django sont des frameworks Web qui implémentent WSGI. Ces frameworks sont conçus pour permettre aux développeurs d'écrire des applications, avec des interfaces faciles à utiliser. Les développeurs n'ont qu'à remplir la logique métier en fonction de leurs besoins. Les premiers frameworks implémentaient principalement les boîtes à outils ASGI en interne, tandis que les frameworks ultérieurs combinent généralement des boîtes à outils appropriées. Par exemple, Flask utilise Werkzeug (le sien) et FastAPI utilise Starlette (des autres).
3. Application Web : Une application créée à l'aide d'un framework Web est une application Web. Habituellement, les frameworks Web sont livrés avec un serveur de test qui peut être démarré pour le développement et le débogage. Si les performances et la stabilité ne sont pas un souci, vous pouvez déjà accéder à l'adresse de développement dans le navigateur pour visiter cette application.
4. Serveur Web : Le monde réel est plus complexe que prévu. Une fois qu'une application Web est déployée dans l'environnement de production, des exigences telles que l'équilibrage de charge des demandes, la diffusion de fichiers statiques, le contrôle d'accès et le proxy inverse doivent être prises en compte, ainsi que des exigences de performances élevées. Les serveurs Web intégrés aux frameworks Web ne peuvent pas du tout répondre à ces exigences, des serveurs Web spécialisés sont donc nécessaires. Actuellement, Nginx est le choix dominant.
5. Serveur ASGI : Le serveur ASGI fait office de pont entre le serveur web et l'application web. Le serveur ASGI adhère également à la spécification ASGI, mais sa tâche principale est de répondre aux exigences de performances des requêtes de transfert, il s'occupe donc principalement de la partie « G » (passerelle) d'ASGI. Son code n'est pas convivial pour les développeurs qui souhaitent écrire une logique commerciale et de routage d'applications Web. Actuellement, le serveur ASGI le plus connu est Uvicorn, et uvicorn.workers.UvicornWorker, qui provient à l'origine du serveur WSGI Gunicorn, est également une option. Il s'agit de l'utilisation recommandée dans l'environnement de production.

Dans le passé, la solution d'environnement de production pour WSGI était généralement Nginx Gunicorn Flask (Django), alors qu'aujourd'hui, la solution d'environnement de production pour ASGI est Nginx Uvicorn FastAPI.

Encore une chose. À en juger par le nom et l'introduction de FastAPI, il est évident qu'il est conçu pour créer des services API. En fait, son code de base est exactement comme ça. On peut dire qu'il ne s'agit pas d'un cadre traditionnel entièrement mis en œuvre par nous-mêmes, mais plutôt d'un cadre qui combine les atouts de divers cadres. Partant d’une coque vide, il assemble les composants nécessaires et adaptés. Par exemple, il ne dispose pas de moteur de modèles. Si vous avez vraiment besoin de l'utiliser pour créer une application Web nécessitant un rendu de modèle, vous pouvez choisir et combiner le moteur de modèle dont vous avez besoin. Bien sûr, vous pouvez également utiliser le Jinja2 intégré à Starlette (oui, il est également intégré à Flask).

Pourquoi on dit que Flask est mort

Les avantages de FastAPI mentionnés ci-dessus ne suffisent pas pour conclure que Flask est mort. Alors, pourquoi ai-je ce point de vue ? Cela dépend principalement de la popularité auprès des développeurs et des utilisateurs.

La « popularité » ici est plutôt subjective. Les indicateurs auxquels je peux penser sont les suivants :

1. Activité communautaire(https://github.com/pallets/flask/issues) : Prenez par exemple le nombre de tickets et de pull request du projet. Flask n'a que des nombres à un chiffre, ce qui est complètement différent de FastAPI. Cela signifie en fait que le projet n'est plus actif. Si le projet est actif, les anciens utilisateurs auront plus de besoins. S’ils arrêtent de poser des questions, c’est qu’ils sont partis. Et les nouveaux utilisateurs rencontreront sûrement toutes sortes de problèmes. Même avec une documentation détaillée, de nombreux utilisateurs devraient toujours venir poser des questions et contribuer au code. L'absence de telles situations indique moins d'utilisateurs.
2. Discussion Heat : c'est-à-dire la popularité des demandes de renseignements et des discussions sur les articles de blog, Stack Overflow et d'autres sites Web. Il est évident qu'il y a très peu de gens qui écrivent sur Flask ces jours-ci.
3. Fréquence d'itération de développement(https://github.com/pallets/flask/pulls) : en regardant les enregistrements de commit, nous pouvons voir que Flask n'a qu'un seul responsable qui corrige occasionnellement certains bugs, sans aucune fonctionnalité majeure développement.
4. Influence du personnage clé : Le personnage clé derrière Flask, l'initiateur du projet, a depuis longtemps cessé de participer au projet. Selon les dossiers de contribution au projet, Armin Ronacher a contribué pour la dernière fois au développement il y a six ans.

Toutes ces situations, à mon avis, suggèrent que l'apogée de Flask est révolue et que FastAPI est l'étoile montante.

Enfin, permettez-moi de vous présenter la plateforme idéale pour déployer Flask/FastAPI : Leapcell.

Leapcell est une plate-forme de cloud computing conçue spécifiquement pour les applications distribuées modernes. Son modèle de tarification par répartition garantit l'absence de coûts inutiles, ce qui signifie que les utilisateurs ne paient que pour les ressources qu'ils utilisent réellement.

Les avantages uniques de Leapcell pour les applications WSGI/ASGI :

1. Prise en charge multilingue

• Prend en charge le développement en JavaScript, Python, Go ou Rust.

2. Déploiement gratuit de projets illimités

• Frais uniquement en fonction de l'utilisation. Aucun frais lorsqu'il n'y a aucune demande.

3. Rentabilité inégalée

• Payez à l'utilisation, sans frais d'inactivité.
• Par exemple, 25 $ peuvent prendre en charge 6,94 millions de requêtes, avec un temps de réponse moyen de 60 millisecondes.

4. Expérience de développeur simplifiée

• Interface utilisateur intuitive pour une configuration facile.
• Pipelines CI/CD entièrement automatisés et intégration GitOps.
• Mesures et journaux en temps réel, fournissant des informations exploitables.

5. Évolutivité sans effort et hautes performances

• Mise à l'échelle automatique pour gérer facilement une concurrence élevée.
• Zéro surcharge opérationnelle, permettant aux développeurs de se concentrer sur le développement.

Apprenez-en plus dans la documentation !

Twitter de Leapcell : https://x.com/LeapcellHQ

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!