Suite au succès phénoménal de Flask, qui a plus d’étoiles sur GitHub que Django, et à celui remarquable de Bottle, j’ai poursuivi ma réflexion personnelle sur les microframeworks. C’est un sujet auquel je m’étais fortement intéressé en 2009, il y a 7 ans donc, lors de la soudaine prolifération de microframeworks Python.

Sinatra, l’inspiration vint encore du Ruby

Tout comme Ruby on Rails a été dès 2004 le grand précurseur des frameworks web MVC de nouvelle génération, Sinatra a été dès 2007 le précurseur des microframeworks web. Sinatra a rendu l’écriture d’application web radicalement plus aisée grâce à sa syntaxe claire et concise :

require 'sinatra'

get '/' do
'Hello world!'
end

WSGI, la condition technique

Le standard Python WSGI (Web Server Gateway Interface) décrit dans la PEP 333 de 2003, mise à jour en 2010 par la PEP 3333, a proposé une interface simple permettant de découpler les frameworks web des serveurs web.

Et l’ajout du module wsgiref dans la bibliothèque standard de Python 2.5 en 2006 a permis a tout framework d’être utilisable sans aucune dépendance grâce au petit serveur WSGI qu’il fournit :

from wsgiref.simple_server import make_server

Qu’est-ce qu’un micro-framework ?

En admettant que l’on sache ce qu’est un framework, on doit s’interroger sur le sens de micro. Le Larousse précise :

Préfixe, du grec mikros, petit, indiquant que quelque chose est très petit.

Un micro-framework est donc un très petit framework. L’intérêt de cette démarche est réel pour le développeur car il est plus facile d’apprendre à utiliser un petit framework, qui de plus consomme moins de ressources et impose souvent moins de contraintes.

Il est communément admis que ces microframeworks sont surtout intéressants pour construire de petites applications, la quantité de fonctionnalités des frameworks full-stack justifiant de plus en plus leur usage avec l’augmentation de la taille et des besoins de l’application.

Le moins de lignes de code possible

Un microframework est donc un framework ayant une petite base de code, c’est-à-dire un petit nombre de lignes de code. Encore faut-il qu’il en ait suffisamment pour qu’un développeur ait un intérêt à l’utiliser. Le minimum nécessaire n’est pas forcément facile à évaluer, mais on peut penser que des frameworks comme Newf ou Itty n’en faisaient pas assez pour susciter un réel intérêt chez les développeurs d’applications web.

Tout le framework dans un seul fichier

La théorie de l’ingénierie logicielle a combattu cette pratique au nom d’une meilleure structuration, permettant une bonne séparation des fonctionnalités et donc un débogage et une réutilisation plus facile du code. Pourtant, mettre tout le code dans un seul fichier présente certains avantages, en particulier quand il s’agit de le distribuer. C’est une pratique qui a connu une nouvelle légitimation avec le succès des bibliothèques JavaScript côté client, facilement chargées dans le navigateur web d’une simple ligne :

<script src="https://cdn.net/lib.js">

Bottle est distributed as a single file module alors que Flask est plus classiquement composé de plusieurs fichiers. Flask, le plus populaire des microframeworks Python en est-il donc vraiment un ?

Essayons d’y voir plus clair à l’aide de wc récursifs appliqués sur les répertoire contenant le code source des frameworks, et desquels j’ai retiré le code des tests :

	Micro-frameworks					Frameworks
Nom	Newf	importd	Itty	Bottle	Flask	Tornado	Pyramid	Django
Lignes de code	150	791	958	4 179	6 469	22 327	22 641	122 675
Fichiers Python	1	2	1	1	21	81	193	853
Étoiles GitHub	50	454	374	3 878	22 007	11 903	2 059	20 717

J’ai ajouté au tableau Django, Pyramid et Tornado, les trois frameworks web Python les plus populaires, et il apparaît clairement qu’en comparaison Flask est bien un microframework, puisque s’il est 1,5 fois plus gros que Bottle, il est 3,5 fois moins gros que Tornado et Pyramid et 19 fois moins gros que Django.

Toute l’application dans un seul fichier

Lorsque l’on utilise les outils d’aide des frameworks classiques pour débuter un projet, on se retrouve devant une arborescence complexe. Par exemple avec Django, si vous évitez les bizarreries et faites les choses normalement :

$ django-admin startproject django_project
$ cd django_project
$ django-admin startapp django_app

django_project
├── django_project
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── django_app
│ ├── admin.py
│ ├── __init__.py
│ ├── migrations
│ │ └── __init__.py
│ ├── models.py
│ ├── tests.py
│ └── views.py
└── manage.py


De même avec Pyramid :

$ pcreate -s starter pyramid_project

pyramid_project
├── CHANGES.txt
├── development.ini
├── MANIFEST.in
├── production.ini
├── pyramid_project
│ ├── __init__.py
│ ├── static
│ │ ├── pyramid-16x16.png
│ │ ├── pyramid.png
│ │ ├── theme.css
│ │ └── theme.min.css
│ ├── templates
│ │ └── mytemplate.pt
│ ├── tests.py
│ └── views.py
├── README.txt
└── setup.py


Ceci est une bonne base pour un gros projet, qui sera bien structuré dès le départ, avec un bon découplage du code, et même les fichiers nécessaires à son packaging ; mais pour beaucoup de projets assez simples, c’est surtout lourd et redondant.

Tous les microframeworks ont donc comme point commun qu’ils sont conçus pour qu’une application toute entière contenue dans un seul fichier soit parfaitement fonctionnelle, et un certain nombre de frameworks qui ne prétendent pas être des microframeworks, comme Tornado, partagent la même approche.

Pas de dépendances… ou beaucoup de dépendances ?

Deux visions opposées peuvent en effet légitimement se défendre lors de la construction d’un microframework :

– pour avoir un framework léger il ne faut aucune dépendances, et se reposer exclusivement sur la bibliothèque standard de Python (Python Standard Library)
– pour avoir un framework léger il faut au contraire se reposer un maximum sur des bibliothèques existantes, fiables et populaires si possible, et se contenter d’offrir une fine couche logicielle permettant de les interfacer correctement

Newf et Itty font bien sûr partie de la première catégorie.

Bottle qui has no dependencies other than the Python Standard Library, et fournit son propre langage de template, fait donc aussi partie de la première catégorie. Mais on peut en plus lui interfacer facilement Mako, Jinja2 et Cheetah, des langages de template Python populaires, ce qui le fait alors déborder sur la deuxième catégorie.

Flask quant à lui est de la seconde catégorie, d’autant que son auteur est Armin Ronacher (mitsuhiko) qui est aussi l’auteur de ses dépendances Werkzeug et Jinja2. Mais si avoir comme dépendances une bibliothèque WSGI et un langage de template est on ne peut plus légitime pour un microframework, l’ajout de la bibliothèque d’interface de ligne de commande Click semble beaucoup plus contestable et relever plutôt du syndrome NIH (Not invented here).

Enfin, la seconde vision a amené à de multiples essais de microframeworks basés sur… Django, le maxi-framework du monde Python ! Et si seul importd a rencontré un certain succès parmi ces projets, je pense que cet oxymore logiciel est un concept vraiment intéressant et que son potentiel n’a probablement pas encore été totalement exploité.

Original post of fgallaire.Votez pour ce billet sur Planet Libre.