Utiliser un framework, c'est partir à l'aventure sur un paquebot : c'est joli, solide, plein de pièces et l'équipage est au grand complet. C'est a priori rassurant. Malheureusement, la vie n'étant pas un long fleuve tranquille, il vaut mieux pouvoir changer rapidement de direction et être réactif qu'apprécier la qualité des bastingages. Pour la vie d'un produit, partir en hors-bord est préférable. Donc faire simple et léger.
Chez Yaal, nous utilisons un ensemble de bibliothèques cohérentes et chacune experte en son domaine. Par exmple, nous aimons utiliser Werkzeug pour les échanges HTTP, propulsé par un uwsgi performant, avec Jinja2 pour un templating efficace, ZODB pour une base de données objet, WTForms pour la validation des formulaires, celery pour l'exécution massive de tâches asynchrones, bleach pour se prémunir des injections de code, etc. Cela permet d'avoir les avantages d'une architecture modulaire sur une architecture monolithique.
Par défaut, nous utilisons les bibliothèques directement (par exemple bleach ou WTForms). Parfois, nous avons voulu faire apparaitre une abstraction de plus haut niveau. Par exemple, une bibliothèque wgsi pour Werkzeug, que nous avons nommée ywsgi. Nos bibliothèques sont préfixées d'un « y » pour être facilement différenciable des bibliothèques externes.
Facilité de compréhension
Un code de petite taille est plus facile à appréhender, à comprendre et à faire évoluer. La base de code pour démarrer un projet est limitée à quelques bibliothèques. Les autres briques viendront s'y ajouter selon les besoins de chaque projet. La base de code reste donc minimale à chaque fois.
Réutilisation de l'existant
Il ne sert à rien de tout réécrire alors que certains problèmes ont déjà été résolus d'une manière qui nous satisfait. C'est pourquoi nous utilisons Werkzeug, Jinja, WTForms, etc.
Possibilité de changer un élément tout en gardant des autres
Les bibliothèques étant indépendantes, nous pouvons facilement en remplacer une si elle ne donne plus satisfaction. C'est grâce à cette modularité que nous avons pu remplacer SQLAlchemy par ZODB par le passé.
Mises à jour plus petites
Les bibliothèques étant indépendantes, les mises à jour sont faites au fur et à mesure de leur sortie. Les mises à jour sont plus petites et donc facilement maîtrisées.
Adaptation à nos préférences présentes et futures
Comme aucune architecture ne nous est imposée, nous pouvons faire évoluer l'architecture sans souci de compatibilité future avec un quelconque framework sous-jacent. De même les seules personnes à convaincre sont dans l'équipe. C'est plus facile quand votre lobbying se limite aux personnes qui sont dans le même bureau que vous. ;-)
Avec l'expérience accumulée, nous préférons largement cette façon de faire. Pourquoi ne pas vous aussi essayer cette voie rafraichissante ?