Chaque équipe Django résout les mêmes problèmes DRF de zéro. Elles ne devraient pas avoir à le faire.

Si vous avez construit plus d'une API avec Django REST Framework, vous connaissez ce sentiment. Un nouveau projet commence, et dans la première semaine, vous écrivez des choses que vous avez déjà écrites. La même logique d'enveloppe de réponse. La même structure de viewset. Le même contournement pour suivre qui a créé ou modifié un enregistrement. La même implémentation d'opérations en masse, cette fois avec la sécurité transactionnelle, parce que la dernière fois elle ne l'avait pas.

Vous ne construisez pas quelque chose de nouveau. Vous reconstruisez une fondation.

Ce que DRF laisse inachevé

DRF est exceptionnel dans ce qu'il fait. Ce n'est pas une critique de DRF. C'est l'observation que construire des APIs à grande échelle fait systématiquement remonter les mêmes lacunes, et ces lacunes ne sont pas des cas limites. Ce sont les problèmes standards de tout projet Django sérieux.

Les endpoints d'une même base de code renvoient des données sous des formes structurellement incohérentes. Certains encapsulent dans une enveloppe. Certains renvoient des tableaux. Certains renvoient des objets plats. Les clients ne peuvent pas compter sur un contrat prévisible, et chaque consommateur de l'API l'apprend à ses dépens.

Chaque ressource nécessite le même code passe-partout. Classes de permissions, résolution de sérialiseurs, filtrage de queryset, intégration de pagination et gestion des erreurs. Dans un système avec cinquante ressources, ce sont des milliers de lignes de duplication structurelle qui n'apportent aucune valeur et créent une incohérence permanente.

Il n'existe pas de mécanisme intégré pour suivre qui a créé ou modifié un enregistrement en dernier. Les contournements habituels dispersent la responsabilité sur plusieurs couches et s'effondrent sous la pression.

Le pattern standard pour stocker l'utilisateur courant dans le stockage local aux threads ne fonctionne pas dans les environnements asynchrones. Avec ASGI qui devient le standard de déploiement, cela introduit des bugs subtils qui sont véritablement difficiles à diagnostiquer.

Les opérations en masse ne sont pas des citoyens de première classe. Les implémenter soi-même signifie réimplémenter la sécurité transactionnelle, la validation et la population d'audit pour chaque ressource, généralement de façon incohérente.

Les champs relationnels s'écrivent en ID, se lisent en ID. Représenter la même relation différemment selon le contexte nécessite des classes de champs personnalisées à chaque fois, une quantité de code disproportionnée pour quelque chose qui revient constamment.

Aucun de ces problèmes n'est exotique. Chaque équipe les rencontre. Chaque équipe les résout légèrement différemment. Chaque nouveau projet recommence par la reconstruction.

La décision d'arrêter

Après avoir rencontré chacun de ces problèmes dans plusieurs systèmes, le schéma est devenu impossible à ignorer. Le problème n'était pas une implémentation individuelle. C'était que l'implémentation devait se produire, à chaque fois, de zéro, avec des résultats légèrement différents à chaque fois.

La bonne réponse était de les résoudre une fois, correctement, de façon composable, et de ne plus jamais avoir à le refaire.

Ce qu'est drf-commons

Ce n'est pas un framework par-dessus DRF. C'est une couche structurelle composée au-dessus des internals de DRF qui suit un principe unique : l'amélioration progressive. Vous adoptez ce dont vous avez besoin. Il complète ce que vous avez déjà. Il ne casse jamais ce que DRF fournit déjà.

Les réponses incohérentes deviennent une enveloppe unifiée unique. Le code passe-partout répétitif de viewset devient des classes de base précomposées. La piste d'audit devient un mixin qui résout l'utilisateur courant de manière sûre via des variables de contexte, avec un support async complet. Les opérations en masse deviennent des citoyens de première classe avec la sécurité transactionnelle intégrée. Les champs relationnels deviennent configurables avec plus de vingt types de champs couvrant chaque pattern courant. L'import et l'export deviennent des services, pas des implémentations personnalisées. Les outils de débogage deviennent unifiés et cohérents.

Chaque problème qui était autrefois résolu par projet est désormais résolu une fois pour toutes.

Si vous construisez des APIs avec Django REST Framework, la documentation complète est disponible sur drf-commons.readthedocs.io. Le code source est sur GitHub. De futurs articles approfondiront chaque problème et la façon dont drf-commons l'aborde spécifiquement.

Victoire Habamungu

Ingénieur logiciel spécialisé en systèmes de données, architecture distribuée et ingénierie de plateforme.

Share post: