Dans une architecture de microservices, est-il conseillé de disposer d'une collection centralisée de fichiers proto et de les avoir comme dépendance pour les clients et les serveurs? ou avez seulement 1 fichier proto par client et serveur?Implémentation de l'architecture de microservice Grpc
Si votre organisation utilise une base de code monolithique (c'est-à-dire que tout le code est stocké dans un référentiel), je recommande fortement d'utiliser le même fichier. L'alternative est seulement de copier le fichier mais alors vous devez garder toutes les versions en synchronisation. Si vous partagez un fichier tampon de protocole entre l'expéditeur et le destinataire, vous pouvez vérifier de manière statique que l'expéditeur et le destinataire utilisent le même schéma, en particulier si de nouveaux microservices sont écrits dans une langue typée statiquement (par exemple, Java). En revanche, si vous n'avez pas de base de code monolithique mais que vous disposez de plusieurs référentiels (par exemple, un par microservice), il est plus difficile de partager le fichier de tampons de protocole. Ce que vous pouvez faire est de les mettre dans des dépôts séparés qui peuvent être ajoutés en tant que dépendance aux microservices qui en ont besoin. C'est ce que j'ai vu dans ma compagnie précédente. Nous avions plusieurs petits référentiels d'API pour le schéma. Donc, s'il est facile d'utiliser le même fichier, je recommande de le faire au lieu de créer des copies. Il peut toutefois y avoir des situations où il est plus pratique de les copier. L'inconvénient est que vous devez toujours appliquer une modification à toutes les copies. Dans le meilleur des cas, vous savez quels fichiers mettre à jour, alors c'est juste fastidieux. Dans le pire des cas, vous ne savez pas quels fichiers mettre à jour et votre schéma sera désynchronisé. Seulement quand le code est libéré, vous le découvrirez. Notez que base de code monolithique ne signifie pas l'architecture monolithique.
Vous pouvez avoir des microservices et conserver tout le code source dans un seul référentiel. Le célèbre exemple est, bien sûr, Google. Google utilise également beaucoup les tampons de protocole pour leur communication interne. Je n'ai pas vu leur code source, mais je serais surpris s'ils ne partagent pas leurs fichiers de tampon de protocole entre les services.