Dernière modification le 11 janvier 2020
Lorsqu’il est nécessaire de mettre une interface CLI sur une application Python, c’est le package Click qui a ma préférence, mais quand il est souhaitable de mettre une interface web sur une application Python, mon choix oscille en permanence entre le micro framework Flask et le framework full-stack Django.
C’est le contexte et l’objectif visé (parfois aussi l’humeur du jour…) qui déterminent la meilleure stratégie. Démarrer avec Flask est très facile et la courbe d’apprentissage (subjective et empirique comme la plupart des lois scalantes) est rapide. Cependant, si l’objectif est de développer une application complète, on est rapidement obligé de rajouter des librairies en tant qu’extensions. D’un autre côté, la structuration mise en place par Django est un peu plus difficile à intégrer, mais tout est disponible et inclus pour réaliser une application complète, même une interface d’admin qui se génère automatiquement.
Dans les deux cas, un serveur intégré est proposé pour tester rapidement l’application au fur et à mesure de l’avancée. Ce serveur est déconseillé pour une utilisation en exploitation, son rôle étant seulement de faciliter la mise au point sans nécessiter la mise en place d’une infrastructure serveur adaptée au langage Python.
Comme toutes les application basée sur le langage Python, je travaille toujours avec un environnement virtuel. Pour ce faire, je démarre l’environnement virtuel dans un répertoire de travail et c’est dans ce même répertoire que je crée l’arborescence applicative pour l’isoler de l’environnement Python. La particularité de Django, c’est que le framework rajoute un concept de projet au dessus de l’application, permettant de diviser un projet en plusieurs applications et d’en rajouter au fur et à mesure de l’évolution du projet.
Flask utilise le moteur de template Jinja2, alors que Django utilise, par défaut, son propre langage DTL (Django Template Language), même si depuis la version 1.8 il est possible d’activer un autre moteur de template.
L’objectif n’est pas d’en déclarer un meilleur que l’autre, ils ont tous les deux leurs places dans l’écosystème Python pour le NetDevOps…