L'article de Jay Freestone propose une approche pour éviter la duplication des règles métier entre frontend et backend en privilégiant le partage de politiques plutôt que de code. L'idée centrale est que les règles, comme la validation d'état d'une commande, doivent être centralisées côté serveur pour éviter des incohérences lorsque les deux parties évoluent indépendamment. Plutôt que de partager des fonctions ou des modules (risquant des divergences de versions ou de déploiement), l'auteur suggère de transmettre les décisions sous forme de données structurées, comme les actions autorisées ou les raisons de désactivation, permettant au frontend de s'adapter dynamiquement.

L'auteur illustre cette méthode avec un exemple concret : au lieu de dupliquer une fonction canCancelOrder en TypeScript à la fois dans l'API et l'interface, le backend renvoie un objet JSON contenant les actions possibles (allowedActions) et les motifs de désactivation (disabledReasons). Cette approche, inspirée des principes HATEOAS, simplifie la maintenance et garantit la cohérence des règles, tout en restant compatible avec des architectures polyglottes où le partage de code est complexe.

Florent Destremau discute de l'utilisation des DTO (Data Transfer Objects) dans les formulaires, soulignant que leur utilisation est souvent présentée comme une évidence sans considérer le contexte et le coût de maintenance. Il illustre cela avec un exemple simple où l'ajout d'un DTO et d'un service de mapping pour une entité basique crée une sur-complexité et une duplication de code. Il argue que pour des opérations CRUD simples, les DTO n'apportent que peu de valeur et recommande plutôt d'écrire des tests pour protéger le code. Il montre comment déplacer les contraintes de validation sur l'entité et utiliser du typage strict peut simplifier le code tout en maintenant une bonne robustesse. Il conclut que cette approche résulte en un couplage plus souple et une couverture de test accrue, malgré une perception initiale de moins de rigueur.

Un résumé d'une conférence à propos de la duplication de code - généralement à éviter mais avec quelques exceptions

D'après l'auteur, la duplication de code est la pire des choses possibles... Il explique pourquoi et comment s'en débarrasser

ou comment recréer les structures de données de MariaDB de zéro... c'est sportif

Tout est dans le titre (via Sebsauvage, remplace fslint)

Tout est dans le titre

Tout est dans le titre

Tout est dans le titre, sauf que ça concerne JavaScript