Comment empêchez-vous un changement backend de casser les clients qui consomment votre API ?

Rendez le contrat vérifiable par une machine. Gardez un schéma, un document OpenAPI ou des définitions protobuf, générés depuis le code ou validés contre lui, et lancez une vérification de compatibilité en CI qui échoue sur un changement cassant comme un champ supprimé ou un type resserré. Ajoutez des tests de contrat pilotés par les consommateurs pour les clients internes, et versionnez les événements comme vous versionnez les endpoints.

Le contrat doit être un fichier que la CI peut comparer, sinon la compatibilité dépend de celui qui relit la pull request. Donc le document OpenAPI vit dans le dépôt et est généré depuis les gestionnaires, ce qui l'empêche de dériver vers la fiction, et il y a un job qui le compare à la version sur la branche principale et échoue sur tout ce qui casse : un champ supprimé, un nouveau paramètre obligatoire, un type restreint. Ajouter est toujours autorisé. Pour les consommateurs internes, j'aime les contrats pilotés par les consommateurs, où chaque client publie le sous-ensemble dont il dépend vraiment et où ma construction vérifie que je les satisfais tous, si bien que je le découvre à la compilation plutôt que par leur astreinte. Les événements reçoivent le même traitement via un registre de schémas avec un mode de compatibilité défini, puisqu'un message cassé est pire qu'un endpoint cassé parce que les consommateurs échouent de façon asynchrone. Et avant de changer quoi que ce soit, je regarde les métriques de requêtes par client, parce que le contrat me dit ce qui est possible et les métriques me disent qui le remarquerait vraiment.