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.
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 :
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'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.
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.
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.
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.
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.
C'est la partie centrale de l'article. Les raisons suivantes expliquent précisément pourquoi FastAPI peut remplacer Flask.
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.
À 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.
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 :
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).
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 :
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 :
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!
Comment configurer au mieux la mémoire virtuelle
Que se passe-t-il lorsque phpmyadmin ne peut pas y accéder ?
ps quitter la touche de raccourci plein écran
fonction de la touche prtscr
Comment télécharger du HTML
Quelle monnaie est l'u-coin ?
Quels sont les modèles de conception utilisés par Laravel ?
Comment utiliser la fonction abdominaux
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
