Python Flask vs Django

Temps de lecture ~4 minutes

Mon expérience de Flask n’est pas aussi poussée que celle de Django, mais il se trouve que j’ai été récemment amené à développer plusieurs projets en Flask et il m’était impossible de ne pas comparer les deux. Je vais mener ici une comparaison très succincte, non pas en montrant du code mais plutôt en discutant de certains aspects plus “philosophiques”. Bien entendu mon opinion peut changer !

Les deux restent des frameworks Python

Quand je suis passé de Django à Flask, ce qui m’a tout de suite frappé était la similitude entre les deux frameworks. Vous ne serez pas perdu. Cela tient principalement au fait que tous deux utilisent le langage Python. Bien que Flask soit censé être plus Pythonique (en utilisant beaucoup les décorateurs par exemple), je n’ai pas noté énormément de différences. Par ailleurs, les deux sont des frameworks web et la plupart des frameworks web fonctionnent à peu près de la même manière :

  • un ORM
  • du routage
  • un objet user request utilisé abondamment
  • des templates
  • la gestion des formulaires
  • la gestion des fichiers statiques

Même en passant de Python à un autre langage, l’utilisation d’un web framework vous aidera grandement parce que cette structure MVC sera toujours là (bon d’accord ce n’est pas toujours du vrai MVC mais peu importe) et vous vous sentirez comme chez vous en un instant. Par exemple, voyez comme c’est facile de passer de Python/Django à PHP/Laravel.

Framework vs micro framework

Flask est censé être un micro framework moins dirigiste et moins clé en main que Django. D’une certaine façon vous êtes censé être plus libre avec Flask. Et c’est le cas ! Django propose une structure de fichiers/dossiers que tout le monde respecte. Django contient aussi son propre ORM, son système de template, sa gestion des formulaires, son système d’inscription/authentification… qui sont utilisés par 99% des gens. Le problème est que, selon moi, cette liberté crée plus de problèmes qu’elle n’en résout…

Ce manque de structure implique que vous sachiez à l’avance exactement quelle sera la meilleure structure pour votre projet, ce qui est très difficile si vous n’avez jamais encore développé un projet entier avec Flask et que vous n’avez jamais eu l’occasion de mettre à l’épreuve cette structure sur un projet dont la taille grossit mois après mois. J’ai constaté que beaucoup de gens finissent par demander conseil concernant la structure de leur projet sur StackOverflow et enfin de compte il se trouve que la plupart des gens utilisent… la structure de Django (un fichier de configuration central et un dossier par application contenant chacun un views.py + models.py + forms.py + des templates) ! J’ai aussi eu pas mal de problèmes, comme beaucoup d’autres, d’imports circulaires en Python, ce qui n’arrive jamais avec Django puisque des gens intelligents ont conçu la structure à votre place justement pour vous éviter ce genre d’ennuis.

La structure d’un projet est une partie très importante de la documentation d’un projet. Une structure standardisée aidera considérablement les nouveaux venus sur votre projet. Chaque fois que je commence à travailler sur un projet Django existant, je suis complètement opérationnel en quelques minutes parce que je sais à l’avance comment les choses sont organisées. Ce n’est pas le cas avec Flask donc les développeurs d’un projet Flask doivent absolument écrire de la documentation supplémentaire afin d’expliquer la structure de leur projet. Le problème est le même avec de nombreuses bibliothèques natives sous Django mais pas sous Flask : chaque projet Flask peut être construit avec des bibliothèques différentes (pour les formulaires, les templates, l’inscription/login, etc.) ce qui fait que les nouveaux développeurs qui arrivent sur un projet peuvent avoir à se former sur de nouveaux outils avant de commencer à travailler.

Documentation

La documentation de Flask est bonne mais clairement trop difficile d’accès pour des développeurs débutants en comparaison de Django qui a une documentation s’adressant à tous types de niveaux (du pur débutant au plus avancé). Par ailleurs, Flask étant un micro framework, une grande partie du travail est basée sur l’utilisation de dépendances externes comme SQLAlchemy pour l’ORM, Flask login pour le login, Flask WTF pour les formulaires, etc. et certaines de ces dépendances n’ont pas le même standard de documentation que Flask. Dit autrement : je trouve la documentation de SQLAlchemy imbuvable, et les outils comme Flask login ont vraiment besoin de faire grossir leur doc (résoudre mes problèmes en parcourant le code source de la bibliothèque ne devrait jamais arriver selon moi).

Communauté

La communauté de Flask est bien plus petite que celle de Django (mais très accueillante malgré tout). La conséquence est que vous ne trouverez pas toutes vos réponses sur StackOverflow ou Github. Cependant vous finissez pas réaliser que la plupart des problèmes sont soit des problèmes purement Python (pas de souci dans ce cas) ou des problèmes rencontrés aussi par les utilisateurs de Django (dans ce cas on est aidé par la communauté de Django).

Conclusion

Flask est un micro framework qui ne recommande aucun standard ou convention. Selon moi il s’agit plus d’un problème que d’une solution si vous espérez que votre projet soit facilement maintenable par d’autre gens. En revanche, si la liberté vous attire, alors essayez Flask ! Si vous êtes déjà développeur Django, le changement sera très facile.

Also available in English

Rate Limiting d'API avec Traefik, Docker, Go, et la mise en cache

Limiter l'utilisation de l'API en fonction d'une règle avancée de limitation du débit n'est pas si facile. Pour y parvenir derrière l'API NLP Cloud, nous utilisons une combinaison de Docker, Traefik (comme proxy inverse) et la mise en cache locale dans un script Go. Si cela est fait correctement, vous pouvez améliorer considérablement les performances de votre limitation de débit et étrangler correctement les demandes d'API sans sacrifier la vitesse des demandes. Continuer de lire