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.