Les frameworks Web sont des outils puissants. Ils abstraient les aspects communs de la création de sites Web et d’API et nous permettent de créer des applications plus riches et plus stables avec moins d’effort.
Une large gamme de frameworks web nous est disponible en Python. Certains sont des favoris éprouvés avec de grands écosystèmes et communautés. D’autres excellent dans des cas d’utilisation de niche ou pour des types de développement spécifiques. Pourtant, d’autres sont des émergents avec de nouvelles raisons impérieuses à prendre en compte. Poursuivez votre lecture pour explorer les options et trouver ce qui vous conviendra le mieux.
Si vous savez déjà ce qui vous intéresse, utilisez les liens ci-dessous pour aller de l’avant :
- Comment Choisir le Bon framework pour vos besoins
- Frameworks Full-Stack vs Microframeworks vs. Frameworks asynchrones
- Frameworks Python à pile complète
- Microframeworks pour Python
- Frameworks asynchrones pour Python
- Qui Le framework web Python est le mieux pour vous?
Si vous souhaitez de l’aide pour décider, vous pouvez également passer directement à notre aperçu des recommandations.
- Comment choisir le Bon framework pour vos besoins
- Frameworks Full-Stack vs Microframeworks vs Frameworks asynchrones
- Cadres Python à pile complète
- Django
- Pyramide
- Web2Py
- TurboGears
- Masonite
- Microframeworks pour Python
- Flask
- Bouteille
- H3:CherryPy
- Falcon
- Cadres asynchrones pour python
- Sanic
- FastAPI
- Starlette
- Tornado
- Quel framework web Python vous convient le mieux ?
Comment choisir le Bon framework pour vos besoins
Les frameworks sont conçus pour résoudre différents problèmes et faire des compromis pour mieux servir leurs publics cibles. Si tout le monde avait les mêmes objectifs, nous n’aurions besoin que d’un seul cadre! Lorsque vous évaluez les cadres, certaines considérations importantes incluent:
- Quelle est la taille et la complexité éventuelles probables de ce que vous construisez?
- Préférez-vous choisir vos propres bibliothèques, configuration et structure d’application ou souhaitez-vous qu’un ensemble d’options plus organisé soit sélectionné pour vous à l’avance?
- Quelle sera l’importance de la performance pour votre projet ?
- À quelle vitesse souhaitez-vous pouvoir développer et déployer votre application ?
- Combien de temps votre application sera-t-elle disponible et combien de développeurs sont susceptibles de travailler dessus ?
De plus, tenez compte de la qualité de la documentation disponible pour les choix potentiels et de la taille de la communauté autour d’un projet – cela affecte à la fois la gamme de plugins ou d’intégrations existants que vous pouvez exploiter pour accélérer le développement et la probabilité de pouvoir obtenir de l’aide lorsque vous êtes bloqué.
Gardez ces aspects à l’esprit lorsque vous explorez vos options – il y en a beaucoup! En fonction de la longévité de votre projet, déterminez également si un cadre est susceptible de grandir avec vous. Sera-t-il adapté à votre application maintenant et à l’avenir?
Frameworks Full-Stack vs Microframeworks vs Frameworks asynchrones
Les frameworks Python peuvent être grossièrement divisés en trois camps, les frameworks full-stack, les microframeworks et les frameworks asynchrones.
Les frameworks Full-stack sont généralement axés sur la création d’applications plus grandes et complètes et offrent de nombreuses fonctionnalités communes prêtes à l’emploi. Si vous cherchez à créer rapidement quelque chose de complexe ou si vous souhaitez des valeurs par défaut raisonnables pour assembler une application sans faire tous les choix vous-même, un framework full-stack est un bon choix. Les frameworks Full-stack vous fournissent généralement des valeurs par défaut judicieuses pour communiquer avec les bases de données, créer des modèles de vues, gérer les files d’attente, les tâches en arrière-plan et d’autres aspects communs des applications plus importantes.
Les microframeworks sont généralement axés sur la fourniture d’un petit noyau de fonctionnalités et invitent le développeur à faire ses propres choix quant aux bibliothèques et technologies à ajouter pour d’autres fonctionnalités. Cela a l’avantage de permettre beaucoup plus de contrôle sur la conception de l’application et peut entraîner de meilleures performances de l’application. Ils exigent généralement que le développeur choisisse sa propre couche d’abstraction de base de données et d’autres bibliothèques. Microframeworks peut être un excellent choix pour les applications plus petites et plus ciblées, le développement d’API ou les applications où les performances sont plus importantes.
Les frameworks asynchrones visent à fournir des niveaux de performances élevés en permettant un très grand nombre de connexions simultanées. Bien que vous puissiez augmenter considérablement la concurrence de la plupart des frameworks synchrones en les associant à des serveurs compatibles asynchrones tels que gevent, les frameworks nativement asynchrones vont encore plus loin avec une pile complètement asynchrone. Généralement, les frameworks asynchrones nécessitent plus de rigueur dans le style de programmation et ont un ensemble de plugins plus limité. Les frameworks asynchrones sont parfaits lorsque vous devez fournir une fonctionnalité spécifique à un volume très élevé.
Cadres Python à pile complète
Django
Django est le framework full-stack le plus populaire pour Python. Il a la réputation bien méritée d’être très productif lors de la création d’applications Web complexes. Surnommé « le cadre Web pour les perfectionnistes avec des délais », son objectif est un développement rapide avec des options bien documentées pour les cas courants.
Django existe depuis plus d’une décennie (première version en 2006) et il est mature, complet, bien documenté et dispose d’une très grande communauté. C’est un cadre opiniâtre, ce qui signifie qu’il prend beaucoup de décisions pour le développeur. Les points positifs de cette approche rendent le développement plus rapide, des intégrations « bénies » qui fonctionnent et plus d’espace de tête pour se concentrer sur les besoins personnalisés de votre projet au lieu des bibliothèques à utiliser. De plus, les projets Django ont tendance à se ressembler, ce qui permet aux développeurs de monter rapidement en puissance sur des projets nouveaux pour eux et aux équipes d’organiser leurs efforts de manière cohérente.
Django offre beaucoup de fonctionnalités prêtes à l’emploi, notamment son propre mappeur objet-relationnel (ORM) pour travailler avec des bases de données, une approche standard de l’authentification et de l’autorisation, une interface d’administration générée automatiquement (utile pour le prototypage rapide), une mise en cache intégrée et plus encore.
Bon pour les projets petits et grands, Django peut être bien adapté pour des charges raisonnables et a été utilisé par de nombreux sites à fort trafic, notamment Instagram, Mozilla et le Washington Post. Django a des fonctionnalités asynchrones dans la version 3.0, avec des vues asynchrones et un middleware à venir dans la version 3.1.
Bien que traditionnellement axé sur les applications web full-stack, Django est également bien adapté au développement d’applications backend réservées aux API. Des intégrations matures existent pour créer rapidement des API REST et GraphQL avec Django.
Résultat net: Le standard de facto pour une bonne raison, Django est le framework full-stack dominant pour Python. Excellent pour démarrer rapidement et avec une expérience éprouvée en matière de mise à l’échelle, Django convient parfaitement à de nombreux projets. Si vous préférez personnaliser plus que Django ne le permet, considérez Pyramid et les microframeworks. Si vous avez besoin d’une concurrence très élevée, explorez les frameworks asynchrones.
Pyramide
Pyramid est un autre framework full-stack populaire. Avec des racines dans le projet Pylons, il a été en développement aussi longtemps que Django et est également une option très mature.
Contrairement à Django, Pyramid est moins opiniâtre. Il fournit des outils de routage, de rendu et de ligne de commande pour démarrer un projet, mais vous offre la possibilité de choisir votre propre couche de base de données, votre système de modèles, etc. via un vaste ensemble de plugins.
Avec sa flexibilité fondamentale, Pyramid est un bon terrain d’entente si vous essayez de choisir entre un framework full-stack ou un microframework. Pyramid vous permet de démarrer plus petit que Django et d’augmenter la complexité de votre base de code au besoin. Cette flexibilité dans la prise en charge des bibliothèques peut être importante lorsque vous avez des exigences spécialisées ou que vous interagissez fortement avec des systèmes avec lesquels Django peut ne pas bien s’intégrer (les bases de données héritées en sont un exemple courant).
Pyramid dispose d’une base de fans dévoués et d’une communauté active qui apprécie sa nature de croissance au fur et à mesure et sa flexibilité fondamentale. Si vous optez pour Pyramid, attendez-vous à un travail supplémentaire pour choisir les composants à l’avance. Cependant, cela peut être du temps bien dépensé à long terme si cela vous permet d’accélérer en permanence les aspects du développement qui sont critiques pour vous.
Résultat: Un puissant mélange de flexibilité et de contrôle fait de Pyramid une alternative convaincante à Django pour certains projets.
Web2Py
web2py est un framework full-stack qui se concentre sur la facilité de développement, avec ses propres contrôles de déploiement, de débogage et d’EDI basés sur le Web. Il a été inspiré par Ruby on Rails et Django et suit une conception MVC (Model View Controller).
Le projet a commencé comme un outil d’enseignement et met l’accent sur des fonctionnalités communes avec des valeurs par défaut sensibles. Il a une courbe d’apprentissage beaucoup plus facile que la plupart des frameworks et est extrêmement facile à installer et à démarrer. La documentation est excellente et de nombreuses fonctionnalités sont intégrées, notamment un planificateur, des assistants 2FA et un bon système de billetterie qui est automatiquement rempli de défauts de production.
web2py a une communauté plus petite que Django et d’autres frameworks, mais très conviviale. De nombreux tutoriels et ressources sont disponibles.
Résultat net: Mieux adapté aux nouveaux programmeurs ou développeurs expérimentant le développement Web. Pas idéal pour de nouveaux projets commerciaux à plus grande échelle.
TurboGears
Présenté comme le » framework qui évolue avec vous « , TurboGears vous permet de démarrer votre application aussi simplement qu’un seul fichier (comme un microframework) ou d’évoluer jusqu’à une application complète avec des outils de ligne de commande pour prendre en charge la gestion. En ce sens, il est similaire à Pyramid, avec l’avantage de plus de contrôle / personnalisation au détriment de plus de travail à l’avance pour déterminer comment vous souhaitez structurer votre application et quelles bibliothèques vous souhaitez intégrer.
L’ORM par défaut pour TurboGears est l’excellent SQLAlchemy. TurboGears présente des différences intéressantes dans la façon dont il gère le routage et sa solution de modèle par défaut. Contrairement à la plupart des frameworks full-stack, le routage est géré par une hiérarchie d’objets au lieu de mapper des expressions régulières aux contrôleurs (le mappage est disponible en option alternative). Le système de modèles par défaut pour TurboGears est Kajiki, un langage inspiré de XSLT.
Résultat net: TurboGears évolue bien avec beaucoup de contrôle, des petits projets aux plus grands. Cependant, Pyramid offre une gamme similaire de flexibilité et est probablement un meilleur choix pour la plupart des gens.
Masonite
Masonite est un framework relativement nouveau (2017) qui a une philosophie de conception similaire à Django mais vise à améliorer certains points douloureux courants. Il offre un échafaudage de code amélioré, un middleware de routage et une prise en charge intégrée de l’envoi d’e-mails, du téléchargement S3 et de la mise en file d’attente.
L’architecture de Masonite est très extensible et ses capacités intégrées sont impressionnantes. La documentation est bonne et il existe un canal Slack actif pour le support. Il utilise son propre ORM, Orator, basé sur ActiveRecord.
En tant que cadre plus récent, la communauté de Masonite est petite mais en croissance. Il est activement amélioré et a beaucoup à aimer. Compte tenu de son mindshare plus petit, il est plus difficile de trouver des développeurs familiers avec Masonite, mais si les capacités supplémentaires prêtes à l’emploi conviennent bien à vos besoins, cela peut accélérer votre développement.
Résultat net: Un concurrent plus récent, Masonite facilite les tâches courantes telles que la gestion des e-mails, le téléchargement de fichiers sur le cloud et le traitement des paiements.
Microframeworks pour Python
Flask
Flask est une solution incroyablement populaire pour les applications Web et les microservices. Inspiré à l’origine du framework Ruby Sinatra, Flask se concentre sur la fourniture d’un ensemble de fonctionnalités de base (traitement des demandes, routage, conformité WSGI, modélisation) et propose une conception modulaire pour l’ajout de tout ce dont vous avez besoin.
En conséquence, le démarrage d’une application est incroyablement simple. Vous pouvez créer une application Web fonctionnelle en quelques lignes seulement :
from flask import Flask, escape, requestapp = Flask(__name__)@app.route('/')def hello(): name = request.args.get("name", "World") return f'Hello, {escape(name)}!'
Flask dispose d’une large gamme d’extensions disponibles, vous permettant d’intégrer vos propres choix de stockage, d’interaction de base de données, d’authentification et d’autorisation, de sécurité et plus encore. Il faudra du temps pour intégrer et configurer vos choix, mais les applications peuvent être construites de manière incrémentielle et n’incluront pas de bibliothèques ni de code pour des éléments que votre application n’utilise pas.
Les applications Flask démarrent généralement dans un seul fichier, mais peuvent être très volumineuses. Il existe des modèles courants pour organiser les applications flask et flask propose également des plans pour rendre les applications plus grandes plus modulaires et plus faciles à gérer.
Conclusion : Extrêmement flexible, Flask est idéal pour les applications Web, les API et les microservices orientés utilisateur. Flask est le microframework le plus populaire pour Python.
Bouteille
Bottle a une syntaxe similaire à Flask (elle la précède en fait d’un an), mais est distribuée sous forme de fichier unique sans dépendances en dehors de la bibliothèque standard python. Cela le rend facile à exécuter dans n’importe quel environnement, y compris les endroits où l’installation de bibliothèques est difficile. Cela signifie également que la gestion des dépendances peut être triviale, ce qui peut être idéal pour les petits projets.
from bottle import route, run, template@route('/hello/<name>')def index(name): return template('<b>Hello {{name}}</b>!', name=name)run(host='localhost', port=8080)
L’ensemble de fonctionnalités est assez similaire à Flask, mais la communauté active est beaucoup plus petite. Les plugins disponibles sont également plus limités. De plus, il y a moins de tutoriels et il peut être plus difficile de trouver des exemples de code ou d’obtenir de l’aide.
Bottle est principalement orienté vers les applications avec de très petites bases de code et n’a pas de chemin clair pour la mise à l’échelle de l’organisation du code car les choses deviennent complexes. La simplicité est au centre de nos préoccupations. Avoir moins de dépendances peut simplifier beaucoup le déploiement (il suffit de coller bottle.py dans votre répertoire de projet) et vous permet de passer plus rapidement d’un prototype à une application de production.
Résultat net: Idéal pour les projets personnels, les petites applications ou les scénarios de déploiement où la gestion des dépendances complexes est difficile.
H3:CherryPy
CherryPy est un autre microframework mature (autour depuis 2002) avec ses propres fans. Une différence majeure avec Flask et Bottle est que CherryPy est orientée objet et se concentre sur le fait d’être aussi « pythonique » que possible. Autrement dit, CherryPy vise à rendre l’écriture d’une application Web aussi similaire que possible à l’écriture de code python général. Regardons un exemple:
import cherrypyclass HelloWorld(object): @cherrypy.expose def index(self): return "Hello World!"cherrypy.quickstart(HelloWorld())
Vous pouvez voir que l’application est définie comme une classe, par opposition à l’approche basée sur les fonctions de Flask. De plus, le routage lui-même est basé sur des objets; le décorateur `@cherrypy` marque les méthodes d’objet qui doivent être transformées en routes, où dans Flask les décorateurs définissent les routes eux-mêmes. Certains développeurs préfèrent cette forme de routage implicite tandis que d’autres la trouvent difficile.
L’une des forces de CherryPy est son serveur Web, qui est intégré au framework. Il est rapide, prêt pour la production, HTTP/1.1 – compatible, pool de threads et peut être utilisé avec n’importe quelle application Python WSGI. En fait, certains développeurs utilisent le serveur Web de CherryPy pour exécuter d’autres applications WSGI (non CherryPy) car il est si facile à configurer et à utiliser.
CherryPy inclut également de nombreuses fonctionnalités intégrées, notamment la gestion des sessions, l’authentification, les gestionnaires de contenu statiques, la mise en cache, le profilage, etc. Des plugins sont disponibles qui puisent dans un riche ensemble de points d’extension.
La communauté de CherryPy est beaucoup plus petite que celle de Flask, ce qui signifie une plus petite communauté de plugins, moins de tutoriels, etc.
Résultat net: Vaut le détour si vous préférez un style de développement orienté objet.
Falcon
Falcon est un framework axé sur les performances pour la création d’API REST et de microservices. Compte tenu de son accent mis sur la vitesse, Falcon fournit un ensemble de fonctionnalités limité: routage, middleware, hooks, gestion des erreurs / exceptions et assistants WSGI pour faciliter les tests unitaires.
Falcon s’intéresse aux applications orientées utilisateur et se concentre sur le service JSON via des points de terminaison REST. Notez le verbe REST (GET) dans cet exemple de code:
import falconclass QuoteResource: def on_get(self, req, resp): """Handles GET requests""" quote = { 'quote': ( "I've always been more interested in " "the future than in the past." ), 'author': 'Grace Hopper' } resp.media = quoteapi = falcon.API()api.add_route('/quote', QuoteResource())
Compte tenu de son réglage et de sa mise au point singulière, Falcon est radicalement plus rapide (20-75x!) que Django et Flask dans les benchmarks de requêtes très basiques. D’autres aspects forts de Falcon sont les réponses d’erreur HTTP idiomatiques (un point douloureux courant lors de la construction d’API) et la gestion simple des exceptions. Il fonctionne sur PyPy et prend en charge Cython sur CPython, deux options à considérer pour des performances maximales.
Si vous aimez l’idée de Falcon mais que vous souhaitez une solution plus complète, jetez un coup d’œil à Hug, un framework construit sur Falcon qui ajoute la gestion des versions, la documentation automatique et la validation automatique par type.
Conclusion : Si vous souhaitez créer des API REST /JSON très performantes, Falcon peut être fait pour vous.
Cadres asynchrones pour python
Sanic
Sanic est un framework et serveur web asynchrone relativement nouveau (première version en 2016), « écrit pour aller vite ».
Alors que la plupart des applications full-stack et micro-trameworks de cette liste existent depuis une décennie ou plus, l’ajout d’asyncio dans Python 3.5+ a ouvert les portes à une toute nouvelle génération de frameworks asynchrones très performants. Sanic est l’une des options les plus établies de cette nouvelle génération.
La syntaxe de Sanic est assez similaire à Flask, avec l’ajout d’une prise en charge asynchrone de bout en bout :
from sanic import Sanicfrom sanic.response import jsonapp = Sanic()@app.route("/")async def test(request): return json({"hello": "world"})if __name__ == "__main__": app.run(host="0.0.0.0", port=8000)
Il dispose de puissantes capacités de routage, de middleware, de streaming, de prise en charge de WebSocket, de gestion des cookies, de gestion des versions de route, de service de fichiers statiques et plus encore. Sanic est un choix naturel si vous avez besoin de gérer des connexions à longue durée de vie telles que des WebSockets ou si vous avez besoin d’un niveau élevé de concurrence de votre API.
Avec un framework asynchrone, vous devrez maîtriser la programmation asynchrone en Python, avec ses mises en garde, sa complexité et ses défis de débogage. Il vaut la peine de prendre le temps d’évaluer si vous avez vraiment besoin des performances d’une API entièrement asynchrone, mais si vous le faites, Sanic vaut le détour !
Résultat net: Une option mature et établie pour développer des API asynchrones très performantes
FastAPI
FastAPI est plus récent que Sanic (première version début 2019) mais prend rapidement de l’ampleur. Il excelle dans la création d’API REST ou GraphQL et peut gérer les requêtes synchrones, les requêtes asynchrones, le streaming et les websockets.
Il prend également en charge l’authentification et l’autorisation, la validation des données, la sérialisation JSON et propose une documentation API automatique suivant la norme OpenAPI.
from fastapi import FastAPIapp = FastAPI()@app.get("/")def read_root(): return {"Hello": "World"}@app.get("/items/{item_id}")def read_item(item_id: int, q: str = None): return {"item_id": item_id, "q": q}
L’ensemble de fonctionnalités de FastAPI est vraiment impressionnant et il frappe un bon point avec sa combinaison de flexibilité et de facilité de développement. Il est conçu de manière très réfléchie et tire largement parti des suggestions de type et de l’injection de dépendances pour réduire les bogues en développement. De plus, la documentation et le support de l’éditeur de FastAPI sont excellents.
La syntaxe de FastAPI est assez similaire à Flask, ce qui en fait un bon choix si vous cherchez à migrer des bases de code Flask existantes vers une solution entièrement asynchrone.
Résultat net: Un framework à la hausse, FastAPI vaut la peine d’être exploré pour votre prochain projet asynchrone.
Starlette
Starlette est un framework et une boîte à outils ASGI légers, fournissant des primitives et une intégration modulaire pour vous permettre de créer votre application avec le degré de contrôle que vous souhaitez.
ASGI est un successeur de WSGI, fournissant une interface standard entre les serveurs Web, les frameworks et les applications compatibles asynchrones. Notez que ASGI prend en charge les opérations synchrones et asynchrones et que ASGI inclut une implémentation de rétrocompatibilité WSGI.
En tant que framework, Starlette associe ses différentes fonctions pour vous, y compris la prise en charge de WebSocket, la prise en charge de GraphQL, les tâches d’arrière-plan en cours, la prise en charge des sessions et des cookies, CORS, GZip, fichiers statiques, etc. Vous pouvez également utiliser chaque pièce indépendamment, en sélectionnant et en choisissant des pièces spécifiques de la boîte à outils.
Puisque Starlette est d’abord une boîte à outils, l’utilisation en tant que framework peut sembler plus compositionnelle, avec des préoccupations exposées séparément:
from starlette.applications import Starlettefrom starlette.responses import JSONResponsefrom starlette.routing import Routeasync def homepage(request): return JSONResponse({'hello': 'world'})app = Starlette(debug=True, routes=)
FastAPI est en fait construit sur Starlette, ajoutant une commodité de syntaxe et des fonctionnalités supplémentaires. Pour la plupart des équipes, FastAPI est probablement un meilleur point de départ, mais Starlette offre un contrôle maximal et un ensemble puissant de primitives.
Conclusion: Si vous souhaitez travailler à proximité du métal sur vos propres outils asynchrones, Starlette est un excellent point de départ.
Tornado
Tornado est un framework web asynchrone plus ancien, créé bien avant que les capacités asynchrones ne soient intégrées à Python. Créé à l’origine par FriendFeed et publié pour la première fois en 2009, Tornado est une solution éprouvée pour la mise à l’échelle de dizaines de milliers de connexions ouvertes en Python.
Le cœur de Tornado est un modèle d’application hautement personnalisable avec de solides bibliothèques réseau sous-jacentes. Il comprend le routage, la création de modèles, la gestion des sessions et des cookies, la prise en charge native de WebSocket, des fonctionnalités de sécurité et propose une gamme mature d’options pour différentes banques de données. Il est moins complet que quelque chose comme Django, mais a beaucoup plus de fonctionnalités intégrées qu’un micro-cadre typique. Tornado utilise des méthodes de type verbe sur les classes de gestionnaire de demandes, ce qui lui permet de se prêter à un style de développement plus orienté objet:
import tornado.ioloopimport tornado.webclass MainHandler(tornado.web.RequestHandler): def get(self): self.write("Hello, world")def make_app(): return tornado.web.Application()if __name__ == "__main__": app = make_app() app.listen(8888) tornado.ioloop.IOLoop.current().start()
Tornado continue d’être activement amélioré et maintenu, avec une communauté robuste. Il est utilisé par Facebook, Quora et d’autres dans leur architecture de production.
Tornado 6+ utilise asyncio sous le capot et nécessite Python 3.5+, mais Tornado 5 peut être utilisé avec Python 2.7 et plus récent. Fonctionnant sur Python 3.5+, les coroutines asynchrones Tornado utilisent la syntaxe native `async`/`await’. Pour les versions antérieures, Tornado offre une syntaxe de générateur qui a des capacités similaires. Notamment, Tornado a un pont mature pour Twisted, qui vous permet d’exécuter à la fois des applications et des bibliothèques Twisted au-dessus de Tornado.
Bottom line: Une solution éprouvée pour la mise à l’échelle en un grand nombre de requêtes simultanées, Tornado vaut la peine d’être explorée si vous voulez une option établie avec une communauté forte, si vous êtes lié à d’anciennes bases de code ou si vous devez utiliser d’anciennes versions de Python.
Quel framework web Python vous convient le mieux ?
Comme il ressort clairement de cette liste, il y a beaucoup de bonnes options. En fait, il existe de nombreux autres frameworks disponibles pour Python – nous avons intentionnellement limité cet article aux seuls frameworks que nous pensons être les plus intéressants à considérer en 2020.
Un bon point de départ est les critères que nous avons mentionnés au début de cet article. Quels sont vos objectifs ? Vous cherchez à expérimenter quelque chose de nouveau, à construire quelque chose rapidement avec une technologie éprouvée ou à acquérir de nouvelles compétences? Combien de personnes travailleront sur votre base de code et combien de temps cela durera-t-il ? Ce sont tous des indices utiles quant au bon choix.
Il n’y a pas de framework parfait pour tout le monde, mais voici quelques suggestions générales :
- Si vous cherchez à démarrer rapidement avec une solution bien établie où les ressources seront faciles à trouver, utilisez Django ou Flask
- Si vous aimez commencer petit et comprendre (ou contrôler) tous les éléments de votre application, explorez Pyramid, Flask ou CherryPy
- Si vous construisez une API ou un microservice qui devra être très performant, regardez Falcon, FastAPI ou Sanic.
- Si vous êtes un programmeur débutant ou que vous apprenez simplement à faire du développement web, web2py ou Bottle sont des moyens conviviaux et faciles de commencer
- Si vous cherchez à explorer des frameworks prometteurs avec de nouvelles idées et façons de faire les choses, consultez Masonite et FastAPI
Avez-vous trouvé cet article utile ou avez-vous vu quelque chose avec lequel vous n’êtes pas d’accord ou qui devrait être amélioré. Veuillez nous le faire savoir, nous apprécions vos commentaires!