La commodité et la polyvalence de Python signifient qu’il est utilisé pour construire des logiciels dans presque toutes les marches de la vie informatique. Une niche majeure est celle des services web, où la vitesse de développement et les métaphores flexibles de Python facilitent la mise en place et le fonctionnement rapide de sites web.
Et comme vous pouvez le deviner, Python vous donne beaucoup de choix et de latitude dans les frameworks web, petits et grands. Après tout, tous les projets web n’ont pas besoin d’être à l’échelle de l’entreprise. La plupart d’entre eux doivent être juste assez grands pour faire le travail, et pas plus. Cet article passe en revue huit des frameworks Python les plus connus qui mettent l’accent sur la simplicité, la livraison légère et une focalisation étroite.
Bottle
Bottle pourrait être considéré comme une sorte de mini-Flask, car il est encore plus compact et succinct que cet autre « microframework ». En raison de son empreinte minimale, Bottle est idéal pour être inclus dans d’autres projets ou pour livrer rapidement de petits projets comme des API REST. (Flask est abordé ci-dessous.)
L’ensemble du codebase de Bottle tient dans un seul fichier et n’a absolument aucune dépendance externe. Même ainsi, Bottle est équipé de suffisamment de fonctionnalités pour construire des types courants d’applications web sans dépendre d’une aide extérieure.
Le système de routage dans Bottle, qui fait correspondre les URL aux fonctions, a presque exactement la même syntaxe que Flask. Vous n’êtes pas non plus limité à un ensemble de chemins câblés ; vous pouvez les créer dynamiquement. Les données de requête et de réponse, les cookies, les variables de requête, les données de formulaire d’une action POST, les en-têtes HTTP et les téléchargements de fichiers peuvent tous être accédés et manipulés au moyen d’objets dans Bottle.
Chaque capacité a été implémentée avec une bonne attention aux détails. Avec les téléchargements de fichiers, par exemple, vous n’avez pas besoin de renommer le fichier si sa convention de dénomination entre en conflit avec le système de fichiers cible (comme des barres obliques dans le nom sous Windows). Bottle peut le faire pour vous.
Bottle inclut son propre moteur de templating HTML simple. Encore une fois, bien que minimal, le moteur de templating a tous les éléments essentiels. Les variables incluses dans un modèle sont rendues avec du HTML sûr par défaut ; vous devez indiquer quelles variables sont sûres pour les reproduire littéralement. Si vous préférez remplacer le moteur de modèles de Bottle par un autre, tel que Jinja2, Bottle vous permet de le faire sans problème. Je préfère le système de modèle simple fourni avec Bottle ; il est rapide, sa syntaxe est sans prétention, et il vous permet d’intermixer le code et le texte du modèle sans difficulté excessive.
Bottle prend même en charge plusieurs back-end de serveur. Il est livré avec son propre miniserver intégré pour des tests rapides, mais il supportera également WSGI générique, une grande variété de serveurs HTTP compatibles WSGI, et le vieux CGI ordinaire si nécessaire.
Bottle n’a pas besoin d’autant de documentation que d’autres frameworks, mais les docs ne sont en aucun cas lésés. Tous les éléments cruciaux tiennent sur une seule (quoique longue) page web. Au-delà, vous trouverez une documentation complète pour chaque API, des exemples de déploiement sur diverses infrastructures, une explication du langage de templating intégré et une foule de recettes courantes.
Comme avec Flask, vous pouvez étendre les fonctionnalités de Bottle manuellement ou via des plug-ins. Les plug-ins de Bottle sont loin d’être aussi nombreux que ceux de Flask, mais il y a des pièces utiles, comme l’intégration avec diverses couches de base de données et l’authentification de base des utilisateurs. Pour le support asynchrone, Bottle peut utiliser l’un des adaptateurs de serveur existants qui s’exécute de manière asynchrone, comme aiohttp/uvloop, mais async/awaitn’est pas nativement supporté.
Une conséquence du minimalisme de Bottle est que certains éléments ne sont tout simplement pas là. La validation de formulaire, y compris des fonctionnalités comme la protection CSRF (cross-site request forgery), n’est pas incluse. Si vous voulez construire une application Web qui prend en charge un haut degré d’interaction avec l’utilisateur, vous devrez ajouter ce support vous-même.
Un autre problème avec Bottle est que le développement s’est arrêté ; la dernière version ponctuelle, 0.12, est arrivée en 2013. Cela dit, Bottle continue d’être maintenu, et ses versions de développement restent utilisables pour la production. Les développeurs ont l’intention de livrer de nouvelles versions qui se débarrassent du support des éditions héritées de Python.
CherryPy
CherryPy existe sous une forme ou une autre depuis près de 20 ans, mais n’a pas perdu le minimalisme et l’élégance qui l’ont distingué dès le début.
Le but derrière CherryPy, outre le fait qu’il ne contient que les bits nus nécessaires pour servir des pages web, est de se sentir, autant que possible, non pas comme un « framework web » mais comme n’importe quel autre type d’application Python. Des sites comme Hulu et Netflix ont utilisé CherryPy en production parce que le framework fournit une base très discrète sur laquelle construire. CherryPy utilise des threads mutualisés sous le capot, afin de mieux supporter les adaptateurs de serveur multithread.
CherryPy vous permet de garder votre application web à part de la logique de base. Pour faire correspondre les fonctions de votre application aux URL ou aux routes servies par CherryPy, vous créez une classe où les espaces de noms des objets correspondent directement aux URL que vous souhaitez servir. Par exemple, la racine du site Web est fournie par une fonction appelée « index ». Les paramètres passés à ces fonctions sont utilisés pour gérer les variables fournies par les méthodes GET ou POST.
Les bits que CherryPy inclut sont destinés à fonctionner comme des blocs de construction de bas niveau. Les identifiants de session et la gestion des cookies sont inclus, mais le templating HTML ne l’est pas. Comme Bottle, CherryPy offre un moyen de mapper les routes aux répertoires sur le disque pour le service de fichiers statiques.
CherryPy s’en remettra souvent à une bibliothèque tierce existante pour supporter une fonctionnalité plutôt que de la fournir nativement. Les applications WebSocket, par exemple, ne sont pas prises en charge par CherryPy directement, mais par l’intermédiaire de la bibliothèque ws4py.
La documentation de CherryPy comprend un tutoriel pratique pour parcourir les différents aspects du programme. Il ne vous emmènera pas à travers une application complète de bout en bout, contrairement à certains autres tutoriels de framework, mais il est toujours utile. Les docs viennent avec des notes pratiques sur le déploiement dans les hôtes virtuels, le reverse proxying via Apache et Nginx, et de nombreux autres scénarios.
Falcon
Si vous construisez des API basées sur REST et rien d’autre, Falcon a été fait juste pour vous. Maigre et rapide, avec presque aucune dépendance au-delà de la bibliothèque standard, Falcon fournit tout ce dont vous avez besoin pour les API REST et rien de plus. Falcon 2.0, publié en 2019, supprime la prise en charge de Python 2.x et nécessite au moins Python 3.5.
Une grande partie de la raison pour laquelle Falcon mérite l’étiquette » léger et mince » n’a pas grand-chose à voir avec le nombre de lignes de code du framework. C’est parce que Falcon n’impose presque aucune structure propre aux applications. Tout ce qu’une application Falcon doit faire, c’est indiquer quelles fonctions correspondent à quels points de terminaison de l’API. Le renvoi de JSON à partir d’un point de terminaison n’implique guère plus que la mise en place d’une route et le renvoi des données via la fonction json.dumps de la bibliothèque standard de Python. La prise en charge de l’asynchronisme n’a pas encore atterri dans Falcon, mais des travaux sont en cours pour que cela se produise dans Falcon 3.0.
Falcon emploie également des valeurs par défaut saines et prêtes à l’emploi, de sorte que peu de bricolage est nécessaire pour la configuration. Par exemple, les 404s sont levés par défaut pour toute route qui n’est pas explicitement déclarée. Si vous souhaitez renvoyer des erreurs au client, vous pouvez lever l’une des nombreuses exceptions fournies avec le framework (comme HTTPBadRequest) ou utiliser une exception générique falcon.HTTPError. Si vous avez besoin d’un prétraitement ou d’un post-traitement pour une route, Falcon fournit des crochets pour ceux-ci également.
La concentration de Falcon sur les API signifie qu’il y a peu de choses ici pour construire des applications web avec des interfaces utilisateur HTML conventionnelles. Ne vous attendez pas à ce qu’il y ait beaucoup de fonctions de traitement de formulaires et d’outils de protection CSRF, par exemple. Cela dit, Falcon offre des options élégantes pour étendre ses fonctionnalités, de sorte que des éléments plus sophistiqués peuvent être construits. En dehors du mécanisme d’accrochage mentionné ci-dessus, vous trouverez une interface pour créer un middleware qui peut être utilisé pour envelopper toutes les API de Falcon.
La documentation de Falcon est mince par rapport aux autres frameworks, mais seulement parce qu’il y a moins à couvrir. Le guide de l’utilisateur comprend une présentation formelle étape par étape de toutes les principales fonctionnalités, ainsi qu’une section de démarrage rapide qui vous permet de visualiser des exemples de code avec ou sans annotation.
FastAPI
Le nom de FastAPI résume bien ce qu’il fait. Il est construit pour créer des points de terminaison d’API rapidement, et il s’exécute rapidement aussi.
FastAPI fait appel au projet Starlette pour son noyau de réseau à haute vitesse, mais vous n’avez pas besoin de connaître les internes de Starlette pour utiliser FastAPI. Vous définissez les points d’extrémité à peu près de la même manière qu’une application Flask ou Bottle – utilisez des décorateurs pour indiquer quelles fonctions gèrent quelles routes – puis retournez des dictionnaires qui sont traduits automatiquement en JSON.
Vous pouvez facilement remplacer la façon dont les choses sont retournées. Par exemple, si vous voulez retourner du HTML/XML à partir de certains points de terminaison, vous pouvez le faire en retournant simplement un objet Response personnalisé. Si vous voulez ajouter un intergiciel personnalisé, vous pouvez insérer n’importe quoi qui suit le standard ASGI.
FastAPI fait usage du type hinting de Python pour fournir des contraintes sur les types de données que les routes acceptent. Par exemple, si vous avez une route avec le type Optional, FastAPI rejettera toutes les soumissions sauf les entiers. Vous n’avez pas besoin d’ajouter du code de validation de données à vos endpoints ; vous pouvez simplement utiliser des indications de type et laisser FastAPI faire le travail.
Naturellement, certaines choses sont laissées de côté. Il n’y a pas de moteur de template HTML natif, par exemple, mais il ne manque pas de solutions tierces pour combler cette lacune. Même chose pour la connectivité des bases de données, mais la documentation contient des détails sur la façon d’amadouer certains ORM (par exemple Peewee) pour travailler avec les comportements asynchrones de FastAPI.
Flask
De nombreuses discussions sur les frameworks web Python commencent par Flask, et pour une bonne raison. Flask est un framework bien établi, bien compris, facile à utiliser et assez stable. Il est presque impossible de se tromper en utilisant Flask pour un projet web léger ou une API REST de base, mais vous devrez faire face à une lourde charge si vous essayez de construire quelque chose de plus grand.
L’attrait central de Flask est sa faible barrière à l’entrée. Une application de base « hello world » peut être mise en place en moins de 10 lignes de Python. Flask inclut un système de templating HTML largement utilisé, Jinja2, pour faciliter le rendu du texte, mais Jinja2 peut être échangé contre un certain nombre d’autres moteurs de template (tels que Mustache) ou vous pouvez rouler votre propre.
Au nom de la simplicité, Flask omet des subtilités telles qu’une couche de données ou un ORM, et n’offre aucune disposition pour des choses comme la validation de formulaire. Cependant, Flask peut être étendu par des extensions, dont il existe des dizaines, couvrant de nombreux cas d’utilisation courants tels que la mise en cache, la gestion et la validation des formulaires, et la connectivité aux bases de données. Cette conception lean-by-default vous permet de commencer l’ingénierie d’une application Flask avec le minimum absolu de fonctionnalités, puis de superposer seulement les pièces dont vous avez besoin quand vous en avez besoin.
La documentation de Flask est géniale et facile à lire. Le document de démarrage rapide fait un excellent travail de mise en route tout en expliquant la signification des choix par défaut pour une application simple de Flask, et les docs sur l’API sont remplis de bons exemples. Également excellente est la collection de snippets Flash, qui sont des exemples rapides et sales de la façon d’accomplir des tâches spécifiques, telles que la façon de retourner un objet s’il existe ou une erreur 404 s’il n’existe pas.
Flask a atteint sa version jalon 1.0 en 2018, avec Python 2.6 et Python 3.3 étant les versions minimales supportées, et avec beaucoup de ses comportements enfin gravés dans la pierre. Flask ne supporte pas explicitement la syntaxe asynchrone de Python, mais une variation compatible avec l’API de Flask appelée Quart a été filée pour satisfaire cette demande.
Pyramid
Petite et légère, Pyramid est bien adaptée à des tâches telles que l’exposition de code Python existant en tant qu’API REST, ou la fourniture du noyau pour un projet web où le développeur fait la plupart des travaux lourds.
« Pyramid vous permettra de devenir productif rapidement, et grandira avec vous », dit la documentation. « Il ne vous retiendra pas lorsque votre application est petite, et il ne vous gênera pas lorsque votre application deviendra grande. »
Une bonne façon de décrire le minimalisme de Pyramid serait « free of policy », un terme utilisé dans la section de la documentation qui traite de la façon dont Pyramid se positionne par rapport aux autres frameworks web. Fondamentalement, « libre de politique » signifie que quelle base de données ou quel langage de templating vous choisissez d’utiliser n’est pas la préoccupation de Pyramid.
Très peu de travail est nécessaire pour construire une application Pyramid de base. Comme avec Bottle et Flask, une application Pyramid peut être constituée d’un seul fichier Python, en dehors des fichiers pour le framework lui-même. Une simple API à une voie ne nécessite pas plus d’une douzaine de lignes de code. La plupart de ces lignes sont des éléments de base comme les déclarations from … import et la configuration du serveur WSGI.
Par défaut, Pyramid inclut plusieurs éléments qui sont communs dans les applications web, mais ils sont fournis comme des composants à assembler, pas comme des solutions complètes. La prise en charge des sessions utilisateur, par exemple, est même fournie avec une protection CSRF. Mais la prise en charge des comptes d’utilisateurs, comme les connexions ou la gestion des comptes, ne fait pas partie de l’offre. Vous devrez la mettre en place vous-même ou l’ajouter par le biais d’un plug-in. Il en va de même pour la gestion des formulaires et les connexions aux bases de données.
Pyramid fournit même un moyen de créer des modèles à partir de projets Pyramid précédents pour réutiliser le travail antérieur. Ces modèles, appelés » scaffolds « , génèrent une application Pyramid avec un routage simple et quelques modèles HTML/CSS de démarrage. Les scaffolds livrés comprennent un exemple de projet de démarrage et un projet qui se connecte aux bases de données via la bibliothèque Python populaire SQLAlchemy.
Les outils de test et de débogage élancés de Pyramide font l’affaire. Regroupez l’extension debugtoolbar dans une application Pyramid et vous obtiendrez une icône cliquable sur chaque page web qui génère des détails sur l’exécution de l’application, y compris un retour de trace détaillé en cas d’erreur. La journalisation et les tests unitaires sont également présents.
La documentation de Pyramid est excellente. En plus d’une visite rapide des bases et d’une promenade de style tutoriel, vous trouverez un ensemble de tutoriels contribués par la communauté et un livre de recettes courantes. Ce dernier comprend des techniques de déploiement pour un grand nombre d’environnements cibles, de Google App Engine à Nginx.
Pyramid prend en charge Python 2 et Python 3, mais n’utilise pas la syntaxe asynchrone de Python 3. Si vous voulez tirer parti de l’asynchronisme dans Pyramid, consultez le projet aiopyramid, qui comprend un échafaudage pour une application « hello world » alimentée par asynchronisme.
Sanic
Conçu pour la vitesse et la simplicité, Sanic fonctionne avec Python 3.6 ou plus et utilise la syntaxe async/await de Python (disponible à partir de Python 3.5) pour vous permettre de créer des applications web efficaces.
Comme avec Flask ou Bottle, un « hello world » de base de Sanic exécute environ 10 lignes de code, la plupart des importations et autres boilerplate. La différence essentielle est que les routes d’application doivent être déclarées comme des fonctions async def, et vous devez utiliser await pour invoquer ces fonctions dans votre code asynchrone. Si vous avez déjà écrit des applications asynchrones, vous avez déjà la partie la plus difficile à votre ceinture.
Plusieurs des mécanismes utilisés par Sanic pour gérer les connexions et les réponses vous seront familiers. Les demandes et les réponses sont juste des objets avec des propriétés d’apparence familière, comme des fichiers téléchargés, des formulaires, des objets JSON, des en-têtes, et ainsi de suite.
Les applications avec de nombreuses routes deviennent difficiles à gérer. Sanic aborde ce problème avec des « blueprints », des objets qui peuvent décrire des groupes de routes et vous permettent de les gérer via une interface de haut niveau. Au lieu d’écrire chaque route explicitement, ou d’utiliser un excès de routes avec des variables, vous pouvez écrire quelques blueprints pour décrire de manière générique le fonctionnement des routes dans votre application (par exemple, /object/object_id/action). Les blueprints peuvent avoir des intergiciels communs, ce qui est utile si vous voulez appliquer une fonctionnalité de gestion à certaines routes mais pas à d’autres.
Sanic fonctionne également avec des protocoles autres que HTTP. Les points de terminaison WebSocket ne nécessitent qu’un décorateur différent et un peu plus de logique interne (par exemple, l’attente et la gestion des réponses). Les protocoles réseau personnalisés peuvent être pris en charge en sous-classant asyncio.protocol.
Sanic laisse délibérément de côté des fonctionnalités telles que la connectivité des bases de données et la création de modèles HTML, tout en conservant les fonctionnalités que l’on utiliserait pour brancher ces capacités : intergiciel, configuration centralisée de l’application, et ainsi de suite.
Tornado
Tornado est un autre minuscule framework visant un cas d’utilisation spécifique : les applications réseau asynchrones. Tornado est bien adapté à la création de services qui ouvrent un grand nombre de connexions réseau et les maintiennent en vie – c’est-à-dire tout ce qui implique des WebSockets ou des polling longs. Tornado 6.0 nécessite Python 3.5 ou plus, et abandonne entièrement le support de Python 2.
Comme Bottle ou Falcon, Tornado omet les fonctionnalités étrangères à son objectif central. Tornado dispose d’un système de templating intégré pour générer du HTML et d’autres sorties, et fournit des mécanismes pour l’internationalisation, la gestion des formulaires, la définition des cookies, l’authentification des utilisateurs et la protection CSRF. Mais il laisse de côté des fonctionnalités, comme la validation des formulaires et un ORM, qui sont principalement destinées aux apps web orientées utilisateur.
Tornado excelle à fournir une infrastructure aux apps qui ont besoin d’un contrôle étroit sur les réseaux asynchrones. Par exemple, Tornado fournit non seulement un serveur HTTP asynchrone intégré, mais aussi un client HTTP asynchrone. Ainsi, Tornado est bien adapté à la construction d’apps, comme un scraper web ou un bot, qui interrogent d’autres sites en parallèle et agissent sur les données renvoyées.
Si vous voulez créer une app qui utilise des protocoles autres que HTTP, Tornado vous couvre. Tornado fournit un accès aux connexions TCP de bas niveau et aux sockets aux utilitaires comme les résolveurs DNS, ainsi qu’aux services d’authentification tiers, et il prend en charge l’interopérabilité avec d’autres frameworks grâce au standard WSGI. La documentation, qui est petite mais pas éparse, comprend de nombreux exemples pour accomplir tout cela.
Tornado exploite et complète à la fois la fonctionnalité native de Python pour les comportements asynchrones. Si vous utilisez Python 3.5, Tornado prend en charge les mots-clés intégrés async et await, qui promettent de donner aux applications un gain de vitesse. Vous pouvez également utiliser des futures ou des callbacks pour gérer les réponses aux événements.
Tornado fournit une bibliothèque de primitives de synchronisation – sémaphores, verrous, et ainsi de suite – pour coordonner les événements entre les coroutines asynchrones. Notez que Tornado s’exécute normalement en single-threading, donc ces primitives ne sont pas les mêmes que leurs homonymes de threading. Cependant, si vous voulez exécuter Tornado dans des processus parallèles pour exploiter plusieurs sockets et cœurs, des outils sont disponibles pour le faire.
La documentation de Tornado couvre chaque concept majeur du framework et toutes les API majeures du modèle. Bien qu’elle comprenne un exemple d’application (un crawler web), elle sert principalement à démontrer le module de mise en file d’attente de Tornado.