Si vous évoquez développement web backend à notre équipe, il se peut que Django soit le premier mot que vous entendiez. Ce framework python nous permet en effet de mettre en place des projets importants tout en le couplant avec une application frontend. D’ailleurs Django est notre solution de prédilection dès que nous voulons développer un backend. Néanmoins FastAPI, solution plus récente, semble proposer des fonctionnalités qui méritent qu’on s’y attarde.
FastAPI ? Qu’est-ce que c’est ?
FastAPI est un framework web open source pour créer des API REST (Representational State Transfer) utilisant le langage python. Celui-ci a été créé il y 5 ans. Il dispose à l’heure actuelle d’un fort développement de son créateur, le tout en Open Source. La double promesse de ce framework : performance et prise en main rapide.
Les avantages de FastAPI
La première chose à relever, c’est que la prise en main est en effet aisée ! La mise en place l’est tout autant : en 5 lignes de codes votre application sera lancée ! (Sans aucune fonctionnalité bien entendu, ce serait trop beau 😅). On retrouve ici toute la rapidité d’utilisation du langage python.
Ce framework se veut très proche de son langage de programmation, car ici vous retrouverez les fonctionnalités de typage et les structures de données de celui-ci pour créer et utiliser vos modèles. D’ailleurs la création de ceux-ci est gérée grâce au package Pydantic, celui-ci permet de définir des objets grâce au typage de python. Et vous vous rendrez compte bien vite que ce typage est particulièrement utile quand FastAPI validera la cohérence des données de vos requêtes.
Nous disions en début de paragraphe, qu’aucune fonctionnalité n’était présente en commençant votre projet et bien cela est techniquement faux. Quel développeur n’apprécie pas une documentation qui se crée en même temps qu’il code ; et bien grâce à l’intégration de OpenAPI c’est le cas ! Rendez-vous sur la page doc de votre application et vous retrouverez tous les endpoints de votre application listés, testables avec des requêtes pré-faites, un vrai régal 🤩. Et vous pouvez bien entendu personnaliser toute cette documentation.
Grâce à ces fonctionnalités et bien d’autres, FastAPI dévoile sa plus grande force : sa flexibilité. Vous pouvez tout aussi bien créer un petit projet pour par exemple laisser tourner l’application sur un serveur afin d’accéder à vos fonctions python préférées ou bien créez un projet plus complexe disposant d’une base de données, de stratégie de sécurité, etc.
Face à la maturité de Django.
Pour commencer les comparaisons, parlons de Django, framework créé en 2005, et notamment de DRF (Django REST Framework) qui est un framework, créé lui en 2011, s’ajoutant à Django pour la création d’une API REST.
La première chose à évoquer est la communauté, celle-ci s’avère bien plus nombreuse pour Django, et cela est bien normal au vu des ses années d’existence. Il sera ainsi beaucoup plus aisé de trouver de l’aide avec celui-ci. Néanmoins la notoriété de FastApi grandit rapidement et le moins qu’on puisse dire c’est que le framework suscite de l’intérêt auprès des développeurs.
Ensuite, la flexibilité de FastAPI est ici son plus grand atout encore une fois, en comparaison de Django qui contraint l’utilisateur à utiliser une base de données et à formater son projet selon une norme, FastAPI laisse la possibilité à l’utilisateur de gérer son code et son projet avec beaucoup plus de souplesse, et cela facilite grandement la montée en compétence.
Évoquons les bases de données pour notre prochain point. Seulement deux types ici, les bases dites SQL et les bases dites NoSQL. Pour le premier type, la base est hyper structurée, rangée en objets dans des tables qui sont reliés entre elles pour correspondre au schéma que vous voulez. Bien généralement un ORM (mapping objet-relationnel) va être utilisé, et le fait que Django en intègre un par défaut, lui donne l’avantage ici. Dans FastAPi, il faut en utiliser un existant et l’intégrer, néanmoins cela se fait relativement naturellement grâce à la création de modèles Pydantic.
Pour le deuxième type, il s’agit de bases bien souvent appelées bases de documents. Très utilisé en machine learning et Big Data, ce type de base a l’avantage de ne pas exiger une hyper structuration des données contrairement au premier. Et la flexibilité de FastAPI est ici un grand atout, car vous n’avez pas forcément à créer de structure précise pour toutes vos données. Django quant à lui ne les supporte pas de façon native.
Le dernier point à soulever en faveur de FastAPI est la programmation asynchrone, en effet il prend en charge celle-ci nativement !
Repassons aux avantages de Django. Pour ce qui est de la sécurité par exemple, celui-ci étant plus ancien, il dispose de librairies prêtes à l’emploi permettant d’intégrer la sécurité dont votre application à besoin, et celle-ci se mettra en place facilement.
Pour finir, Django est-il moins flexible ? Est-il moins facile à prendre en main ? Oui en effet, mais ces désavantages ont aussi des atouts. Une fois ces débuts un peu difficile, votre projet sera facilement scalable, et de nouvelles fonctionnalités pourront être ajoutées plus facilement.
Face à la simplicité de Flask.
FastAPI tient-il la comparaison avec Flask ? Créé en 2010, celui-ci avait pour but de permettre la création d’API REST en un seul fichier, il est très facile d’utilisation et tous les développeurs python connaissant la notion d’API REST peuvent en créer une sans grande difficulté. Open Source et toujours maintenu, Flask dispose d’une communauté fidèle appréciant sa facilité d’usage. Il est pour certains la porte d’entrée aux API REST.
Tout d’abord en termes de popularité, FastAPI semble déjà rattraper Flask alors qu’il dispose d’une longévité moindre. Et pour cause, on a l’impression d’avoir affaire à un Flask survitaminé. Aussi facile à prendre en main quand on débute, on se rend vite compte que bien plus de choses ont l’air d’être présentes pour créer un projet de plus grande envergure.
Alors ne vous y trompez pas, si vous souhaitez une API REST très légère disposant de peu de fonctionnalités, qui n’a pas de besoin de sécurité ou qui n’évoluera pas beaucoup, Flask reste toujours très performant et facile à déployer et développer, néanmoins FastAPI semble bien plus intéressant.
Pour quels types de projets utiliser FastAPI ?
Votre projet à besoin d’une base de données SQL ? C’est tout à fait possible avec FastAPI et certains projets s’y prêteront très bien, mais Django grâce à son ORM intégré permettra ici une évolutivité plus facile, et une meilleure scalabilité de l’application, si celle-ci doit évoluer.
Une base de données NoSQL ? Foncez et donnez une chance à FastAPI ! Beaucoup de projets touchant au Machine learning et au Big Data devraient y trouver leur compte : une base NoSQL permettant beaucoup plus de flexibilité pour manipuler des données qui en général ne peuvent pas (ou très difficilement) s’adapter à une structure SQL.
Pour ce qui est de la sécurité, Django permettra plus de facilité de mise en place grâce à des packages tout fait, mais FastAPI permettra à tout développeur python aguerri, que ce soit grâce à la communauté montante ou à la facilité de mise en place de son code, d’établir la sécurité de votre application.
Aucune base de données n’est nécessaire ou la sécurité est optionnelle ? Si vous voulez une solution rapide à mettre en place, Flask reste un très bon candidat ici, et pourra toujours se connecter à une base de données grâce au langage python directement si besoin est. Néanmoins FastAPI étant rapide à mettre en place, il sera sûrement une meilleure solution grâce à ces différentes fonctionnalités, on ne sait jamais jusqu’où un projet peut évoluer…
Notre verdict sur FastAPI
En résumé pour FastAPI :
- Avantages :
- Flexible
- Rapide
- Support des bases NoSQL et pas de nécessité d’utiliser une base de données.
- Programmation asynchrone
- Désavantages :
- Pas d’ORM intégré pour les bases SQL
- Sécurité moins rapide à mettre en place
- Scalabilité
- Encore jeune
Étant développeurs Django, nous devons avouer être très impressionnés par les possibilités de FastAPI.
Au plaisir de jouer… Enfin nous voulons dire travailler avec dans le futur 😉.
