Litestar mérite qu’on s’y intéresse

• Litestar est l’un des joyaux méconnus parmi les frameworks web asynchrones Python
• Grâce à sa montée en charge rapide et à son architecture flexible, il s’adapte facilement à des projets très variés
• Il propose une modélisation des données non dépendante d’une bibliothèque spécifique comme Pydantic
• Son intégration avec SQLAlchemy est excellente, ce qui en fait un framework solide pour la connexion et la gestion de bases de données
• Avec ses fonctions intégrées pratiques comme l’authentification, le caching, la journalisation et le monitoring, il peut être utilisé immédiatement en contexte professionnel

---

Présentation de Litestar

• Alors que les frameworks web Python async-first et basés sur les annotations de type ont gagné en popularité ces dernières années, Litestar a été choisi pour accumuler de l’expérience d’usage sur le terrain
• Après avoir adopté Litestar comme framework principal sur plusieurs projets réels, la confiance dans ce choix n’a cessé de grandir
• Beaucoup de développeurs web Python ne connaissent pas encore Litestar, et cet article présente donc ses principaux avantages et points distinctifs

Exemples et comparaison avec d’autres frameworks

• Litestar permet d’écrire très facilement une application web en un seul fichier

  • Son route decorator est une fonction indépendante non rattachée à l’objet application
  • Dans l’exemple de code, accéder à /greet?name=Bob renvoie “Hi, Bob!”
  • Si un paramètre requis manque, une réponse 400 est automatiquement renvoyée

• Contrairement aux microframeworks Python classiques comme Flask ou FastAPI, Litestar possède des caractéristiques structurelles qui lui permettent de s’étendre naturellement à des projets de tailles très diverses

  • Avec l’approche Flask ou FastAPI, les décorateurs de routage sont liés à l’objet application, ce qui peut entraîner des problèmes d’import circulaire lors d’une séparation en plusieurs fichiers
  • Il faut généralement utiliser un registre de routes secondaire (blueprint dans Flask/Quart, APIRouter dans FastAPI, etc.), ce qui augmente la barrière d’entrée ou impose une évolution de la structure
  • Avec Litestar, en revanche, le decorator est une fonction indépendante, ce qui rend la transition entre une app monofichier et une architecture distribuée à grande échelle très simple

• Grâce à l’architecture de base de Litestar et à sa manière de structurer la documentation, il est possible d’introduire très tôt les notions de routeurs et de regroupements fonctionnels, ce qui facilite le maintien d’une organisation cohérente même pour des API complexes

  • L’injection de dépendances, les permissions et le partage de configuration par route constituent de vrais points forts en matière de composability
  • Il est possible d’enregistrer la même route plusieurs fois afin d’appliquer des mécanismes d’authentification ou des dépendances selon l’environnement

Modélisation sans dépendance forte à Pydantic

• FastAPI et d’autres frameworks reposent fortement sur Pydantic pour les données

  • Pydantic excelle dans la validation et la sérialisation basées sur les types, mais son intégration directe avec un ORM comme SQLAlchemy reste difficile
  • En pratique, il faut souvent écrire séparément les modèles SQLAlchemy et les modèles Pydantic, ce qui ajoute une contrainte fastidieuse

• Litestar prend en charge de manière générique non seulement Pydantic, mais aussi dataclasses, msgspec, attrs et les modèles SQLAlchemy

  • Il dispose d’un protocole de plugin de sérialisation qui améliore fortement son extensibilité
  • Une fonction d’extraction automatique des objets de transfert de données (DTO) est intégrée, de sorte qu’une modification de la classe de données source se reflète automatiquement dans le DTO
  • Il est aussi facile de déclarer l’exclusion ou l’inclusion de certains champs, le mapping de noms ou encore des DTO de mise à jour partielle
  • Cela permet d’éviter les déclarations redondantes de champs de modèle et les erreurs fréquentes liées à la synchronisation manuelle

Intégration avec SQLAlchemy et présentation d’Advanced Alchemy

• L’ORM SQLAlchemy est de fait le standard pour l’accès aux bases de données en Python

  • Litestar offre une intégration particulièrement réussie avec SQLAlchemy : sérialisation automatique des schémas, automatisation des DTO, plugin de gestion de session, plugins composés, etc.

• La bibliothèque Advanced Alchemy (maintenue par l’équipe Litestar) étend encore les capacités de SQLAlchemy

  • Elle fournit de nombreuses améliorations de qualité : PK volumineuses indépendantes de la base, horodatage automatique, clés UUID, type JSON, intégration avec les migrations Alembic, Seed/Export, etc.
  • Une fonctionnalité particulièrement notable est la prise en charge des abstractions repository et service layer, qui fournit automatiquement diverses fonctions de stockage comme le CRUD ou la pagination
  • Dans des frameworks qui, contrairement à Django, offrent peu de lignes directrices structurelles, cela fournit une manière d’organiser les projets qui justifie l’adoption d’une repository/service layer

Autres caractéristiques et fonctions intégrées

• Litestar fournit aussi en interne un système d’authentification (fonctions guard, middleware), le caching (stores), la journalisation, des réponses d’erreur standardisées, des métriques basées sur Prometheus/OpenTelemetry et la prise en charge de htmx
• Contrairement à d’autres microframeworks, il n’est pas nécessaire de chercher des bibliothèques externes séparées ni d’écrire du glue code personnalisé pour implémenter certaines fonctionnalités
• Il conserve la simplicité d’un « microframework », tout en permettant d’utiliser immédiatement des fonctions d’extension ou des fonctionnalités supplémentaires selon les besoins
• Plutôt qu’un simple remplaçant de Django ou Flask, son concept consiste à intégrer de manière Pythonic les points forts de frameworks d’autres langages, comme Java Spring Boot, notamment sur la structure initiale et la commodité
• Dans l’ensemble, c’est une option offrant de forts gains de productivité et des avantages structurels pour le développement web Python en conditions réelles

Conclusion

• Grâce à son asynchronisme, son approche basée sur les types, sa flexibilité d’extension, sa modélisation de données non rigide, ainsi que l’excellence de son ORM et de ses fonctions intégrées, Litestar s’impose comme un framework que tout développeur web Python devrait envisager au moins une fois
• Après un usage répété sur des projets réels, il a démontré une forte productivité et une bonne maintenabilité, y compris dans des environnements variés comme les startups
• On peut espérer que les développeurs considéreront Litestar comme l’une des options possibles pour leur prochain projet web Python

[minhoryang]

Le problème des « imports circulaires » en Python n’a-t-il pas déjà des solutions assez claires ? J’ai du mal à y voir un problème vraiment majeur.

[GN⁺]

Avis Hacker News

• Depuis un an, je développe un gros projet backend avec FastAPI. J’ai commencé en suivant le style du tutoriel officiel, mais j’ai trouvé peu pratique le template officiel de FastAPI qui pousse à mettre tout le CRUD dans un seul fichier, ainsi que sa manière de gérer les dépendances. En utilisant SQLModel, j’ai aussi rencontré plusieurs limites, comme l’absence de prise en charge des modèles polymorphes, et je me suis demandé si le projet était vraiment maintenu quand des PR d’amélioration proposées par la communauté n’étaient même pas relues pendant des mois. La documentation manquait aussi de références vraiment exploitables, au point qu’il fallait finir par fouiller dans le code source. C’est correct pour monter rapidement un CRUD, mais pour construire un système complexe, j’ai l’impression qu’il faut rajouter un framework par-dessus le framework, donc je ne pense pas le recommander. À partir de demain, je prévois de migrer vers Litestar
  • Pour étudier un exemple concret de grande application FastAPI, il semble utile de consulter le code serveur du dépôt polarsource/polar. On y trouve de bons exemples réels de montée en charge, notamment pour l’authentification et les tests, donc je compte apprendre en suivant l’implémentation de ce dépôt
  • Je débute dans la conception d’applications orientées API, et ce billet m’a appris beaucoup de choses sur l’architecture et les outils auxquelles je n’avais pas pensé. Je pense moi aussi essayer Litestar. Merci pour cet avis utile et pour l’article
  • Je ne suis pas d’accord avec l’idée que SQLModel soit trop mis en avant dans le tutoriel officiel de FastAPI. Il n’est même pas mentionné sur la première page, et n’apparaît que dans la page qui explique la connexion à une base de données relationnelle. Utiliser un ORM particulier dans un tutoriel est un choix naturel, et si SQLModel ne convient pas, je pense que c’est à l’utilisateur de choisir une autre option. Moi aussi, après avoir lu le tutoriel, j’ai opté pour SQLAlchemy pur
  • En lisant la documentation de Litestar, j’ai vu qu’un système d’événements est aussi intégré. C’est une fonctionnalité que j’avais passée plusieurs semaines à construire séparément dans FastAPI, alors que Litestar l’a dès le départ
  • Je me demande si Litestar n’a pas lui aussi certaines limites. La communauté, la documentation et les discussions sont moins abondantes que pour FastAPI, alors j’aimerais savoir si vous pensez malgré cela qu’il est plus adapté aux applications complexes
• Litestar est excellent pour construire des backends d’API. Je l’utilise moi-même et je le recommande vivement. Advanced Alchemy s’améliore aussi de plus en plus. On peut tout à fait créer avec Litestar des sites plus traditionnels rendus côté serveur, et il inclut aussi un plugin pour HTMX. En revanche, les patterns pensés pour la conception d’endpoints d’API sont parfois un peu maladroits pour des endpoints traditionnels rendus côté serveur, avec validation de formulaires, redirections, etc. Litestar ne dispose pas en soi d’un vrai système de traitement de formulaires, ce qui rend difficile la gestion correcte des erreurs champ par champ. Le pattern basé sur @post("/route", exception_handlers={...}) paraît un peu maladroit. J’espère de meilleurs outils intégrés et une meilleure expérience de développement à l’avenir
  • Je n’ai jamais utilisé Litestar moi-même, mais je me dis qu’on pourrait peut-être simplement créer un décorateur maison comme @postform qui gérerait tout ce qui concerne les formulaires
• Litestar est un framework web Python. Je partage l’info d’abord pour ceux que ça intrigue
  • Certains ont dit que cela leur avait fait gagner du temps
• Cela fait plus d’un an que j’utilise Litestar pour servir à la fois du JSON et du HTML basé sur des templates. C’est un framework async Python plus rapide que FastAPI, léger, mais bien équipé avec les fonctions essentielles comme l’authentification et les sessions. J’aime particulièrement la prise en charge de msgspec et le routage imbriqué basé sur les Controller. Je le recommande vivement
  • J’ai moi aussi basculé de FastAPI vers Litestar sur un nouveau projet, et je l’utilise sans le moindre regret. Rien qu’avec la base fournie par défaut, Litestar donne une vraie impression de finition et de fiabilité
  • J’utilise FastAPI depuis quelques années, mais Litestar semble vraiment valoir la peine d’être essayé au moins une fois
• En développant des applications avec FastAPI pendant plusieurs années, j’ai ressenti des frustrations similaires. Beaucoup estiment que la documentation FastAPI, centrée sur les tutoriels et les exemples, est déconnectée de la réalité du développement en production et de la vraie mesure de la qualité d’une API. Je suis surpris que ce point revienne aussi souvent
  • Je suis très déçu de voir que la documentation des frameworks Python récents donne tous l’impression des bibliothèques JavaScript, avec un mélange de « tutoriel + billet de blog bavard », mais sans vraie référence détaillant l’API et ses paramètres. Il faut une vraie documentation de référence de l’API. J’aimerais avoir le détail des options pour chaque méthode, une présentation claire des paramètres, et des options correctement documentées au lieu de simples phrases en commentaire. Le fait qu’il faille fouiller dans le code source pour obtenir des réponses satisfaisantes est extrêmement pénible
• FastAPI est utilisable, mais il a pas mal de limites dès qu’il s’agit de construire des applications complexes. Il m’arrive d’être surpris de voir l’écosystème des microframeworks Python redécouvrir avec retard des problèmes de conception que JavaEE avait déjà traversés il y a 15 ans. Litestar a l’air plutôt bon. Je suis aussi curieux de savoir comment il gère les cas d’erreur en streaming
• FastAPI est populaire, mais pour les petits projets, j’ai été très satisfait de starlette à lui seul. Il n’offre pas toutes les fonctionnalités, mais pour des services simples, il ne manque de rien. Litestar semble couvrir un périmètre plus proche de FastAPI ou de Django
  • Dernièrement, je construis mes API uniquement avec starlette, et comme c’est propre, concis et bien documenté officiellement, ça s’adapte bien quel que soit le volume du projet
• Litestar m’a toujours intéressé, mais je ne l’ai pas encore utilisé directement. J’utilise FastAPI depuis assez longtemps, et je pense que l’idée selon laquelle il serait difficile à faire évoluer sur une grosse base de code est un peu exagérée. En répartissant les routes dans plusieurs fichiers et en les important dans une grosse arborescence, on obtient quelque chose d’assez extensible. En revanche, je suis d’accord sur le manque de guide officiel concernant la structuration à grande échelle. En séparant les fichiers par modules selon les bonnes pratiques et les préférences de chacun, on obtient une extensibilité suffisante. Je n’ai pas utilisé SQLAlchemy directement avec FastAPI, donc je ne pense pas pouvoir vraiment partager cette souffrance-là
• C’est un billet qui met bien en lumière les points importants du développement d’applications en conditions réelles. La conception de Litestar est vraiment séduisante. J’attends aussi avec intérêt son point de vue sur le pattern repository. Ce serait bien d’en faire un billet séparé
• Le billet était vraiment excellent. SQLAlchemy est difficile à manier, avec un état interne complexe et beaucoup d’aspects surprenants, et je me demande si certaines personnes développent carrément sans l’utiliser
  • J’ai récemment utilisé peewee sur un projet personnel. Il n’a pas beaucoup de fonctions annexes, mais il fait bien le travail qu’on lui demande
  • Il y a une grande différence entre SQLAlchemy traditionnel et Advanced Alchemy de Litestar, même si ce dernier repose lui aussi sur SQLAlchemy. Avant, j’utilisais du SQL pur ou SQLAlchemy, mais depuis mon passage de django ninja à Litestar, j’essaie de réduire autant que possible mon usage direct de SQLAlchemy
  • L’aspect le plus intéressant de ce projet, c’est qu’il semble corriger dans une certaine mesure les défauts de SQLAlchemy. Chaque fois que je démarre un projet nécessitant une base de données, je finis par revenir à Django. SQLAlchemy et Alembic sont des souffrances dont je me passerais volontiers
  • À mon avis, la manière la plus réaliste d’utiliser SQLAlchemy consiste à ne s’en servir que pour définir les modèles et le schéma avec Alembic, ainsi que pour les migrations, puis à écrire soi-même le SQL pour les requêtes réelles et la gestion des transactions. Le temps perdu à reformuler les requêtes via l’ORM est trop important
  • J’utilise surtout asyncpg