Il est facile d'oublier de mettre à jour un fichier de protocole de buffer et de perturber un appel de serveur si la spécification n'est pas alignée, notamment avec les microservices. Si votre serveur à serveur.signature de protocole (Proto) ne correspond pas exactement à la définition, la requête échouera. Il est donc important de mettre en place une structure de pipeline de modèle évolutif tout au long du développement de votre application.
La configuration de vos fichiers de définition de protocole peut varier d'une entreprise à l'autre ou d'une application à l'autre en fonction des exigences. Le protocole gRPC a été conçu pour utiliser des fichiers de protocole de buffer ou .proto pour implémenter un schéma qui peut générer un serveur et un client capable d'envoyer des messages dans les formats définis. Au départ, vous pouvez configurer un fichier .proto à deux emplacements différents sur deux dépôts GitHub ou des dossiers différents qui ne partagent pas de modules communs et assembler les blocs de Lego pour les connecter. À un moment donné, vous pouvez vous retrouver avec plusieurs définitions de services et de messages qui sont dupliquées dans les dépôts. Avec gRPC, vous pouvez importer les modules dont vous avez besoin entre les fichiers pour éviter la duplication de code. Dans ce sens, il peut être utile de configurer un emplacement central pour créer les fichiers et les expédier aux gestionnaires de dépendances pour qu'ils soient consommés dans votre application comme le npm, cargo ou composer. Un exemple de cela peut être trouvé à cet emplacement et testé en utilisant npm (gestionnaire de packages pour Node) en exécutant npm i @a11ywatch/protos. Vous verrez les fichiers de définition à l'intérieur du dossier node_modules.
Lorsque vous suivez semver (contrôle de version) avec gRPC, cela aide à définir une couche de compatibilité qui sera vraie à différents niveaux. En général, gRPC ne présente pas de rupture lors des mises à jour, sauf lorsque vous effectuez les actions suivantes.
pas généralement transmis via le réseau, donc ce n'est pas un changement perturbateur au protocole gRPC. Cependant, le client doit être mis à jour s'il utilise le contrat le plus récent. Une situation dans laquelle les noms de messages sont transmis sur le réseau se produit avec les champs Any, lorsque le nom de message est utilisé pour identifier le type de message. Emboîter ou désembosser un message - Les types de message peuvent être emboîtés. Emboîter ou désembosser un message change son nom de message. Changer la façon dont un type de message est emboîté a le même impact sur la compatibilité que le renommage. Changement de l'espace de noms - Le changement de l'espace de noms modifiera l'espace de noms des types de langage générés. Ce n'est pas une modification perturbatrice sur le protocole gRPC, mais le client doit être mis à jour s'il met à niveau le contrat le plus récent.
Maintenant que nous avons les bases, nous pouvons utiliser les outils automatisés qui contribuent à améliorer les workflows gRPC et la productivité.
Je m'appelle Jeff et je suis le fondateur et créateur d'A11yWatch.
Commencez dès maintenant avec A11yWatch pour des outils d'accessibilité web automatisés abordables et rapides.
