Appels gRPC lisibles par l’homme avec Fiddler Everywhere

Découvrez quelques trucs et astuces plus avancés pour utiliser gRPC avec Fiddler Everywhere, notamment comment tirer parti de la lisibilité des appels gRPC.

Le gRPC est-il uniquement une question de performances ? Ou gagne-t-il autant de popularité parce qu’il est efficace, multiplateforme, multilingue, interopérable, peu encombrant et, bien sûr, sécurisé ? Comment Progress Telerik Un violoniste partout convient, et quelle est exactement la partie « appel gRPC lisible par l’homme » ? Je ne sais pas si commencer un article de blog avec autant de questions est une bonne idée, mais je peux vous dire que terminer un article de blog en fournissant toutes les réponses l’est.

Source de l’image : Unsplash

Mais tout d’abord, faisons une brève introduction sur les principaux acteurs d’aujourd’hui. gRPC (Google Remote Procedure Calls) est un framework open source moderne ou, mieux encore, un style architectural parfaitement adapté à la création de microservices rapides, évolutifs et indépendants du langage, avec des contrats stricts et des capacités de communication en temps réel. Il est basé sur HTTP/2 et constitue un choix de premier ordre pour les applications cloud natives, les réseaux à faible latence et les systèmes nécessitant une sérialisation efficace des données.

Fiddler Everywhere est un outil de débogage Web qui capture, inspecte, modifie, filtre et enregistre le trafic (que ce soit HTTPS, WebSocket, les événements envoyés par le serveur, Socket.IO ou, bien sûr, gRPC), émet des requêtes entre une machine (y compris les appareils mobiles). ) et Internet, et manipule les données entrantes et sortantes. Avec lui, vous pouvez rédiger des requêtes API et partager des journaux de débogage réseau. Il est multiplateforme, lisible par l’homme et convivial (jeu de mots prévu) et apporte des performances élevées.

Si vous êtes fan de vidéos rapides de cinq minutes expliquant comment tout fonctionne, je suis là pour vous. vidéo sur gRPC est exactement pour vous, accompagné d’un lien vers leur documentation officielle. En tant que bon guide du débutant sur la façon de démarrer avec gRPC et Fiddler Everywhere, je recommanderais cet article de blog : Introduction à gRPC avec Fiddler Everywhereet bien sûr le fonctionnaire Documentation Fiddler partout.

Source de l’image : Unsplash

Cependant, le but de cet article de blog est de vous amener un peu plus loin et de dévoiler quelques trucs et astuces supplémentaires. Son sujet principal portera sur la manière de bénéficier de la lisibilité des appels gRPC.

Le trafic gRPC n’est pas lisible par l’homme par défaut

Contrairement aux requêtes API HTTP, qui peuvent être créées et lues par des humains, car elles sont envoyées sous forme de texte, gRPC n’est pas lisible par l’homme par défaut.

Un facteur majeur derrière les performances exceptionnelles de gRPC est son utilisation de Protobuf pour la sérialisation. Il s’agit d’un protocole binaire qui n’est pas lisible par l’homme. D’une part, cela accélère considérablement les opérations d’appels de procédures à distance, mais cela peut également compliquer les interactions manuelles avec le serveur. Protobuf nécessite la description de l’interface du message spécifiée dans le .proto fichier pour désérialiser correctement.

Je ne peux pas cacher que je suis un fan des franchises de super-héros, alors explorons la différence entre les formats binaires lisibles par l’homme et Protobuf avec un tel exemple !

Définition de Protobuf

message Superhero {
  optional  string name = 1;
  optional string superpower = 2;
  optional string favorite_food = 3;
  optional string sidekick_name = 4;
}

Sur la base de la structure de données ci-dessus, voici mon instance de données :

• Nom: « Quelqu’un qui a eu une rencontre rapprochée avec une araignée »
• Superpuissance: « Capacité à s’accrocher aux surfaces solides »
• Plat préféré: « Tarte aux cerises de tante »
• Nom de l’acolyte: « Ils sont tellement nombreux »

Représentation JSON (lisible par l’homme)

{
  "name": "Someone that had a close encounter with a spider",
  "superpower": "Ability to cling to solid surfaces",
  "favorite_food": "Aunt's Cherry Pie",
  "sidekick_name": "They are so many"
}

Bien que cela reste un mystère (n’est-ce pas ?), dans ce format JSON, il est facile de voir l’identité et les capacités du super-héros sous une forme claire et lisible par l’homme. Tout le monde peut immédiatement comprendre les détails de la vie, des pouvoirs et des préférences alimentaires de ce super-héros, car les paires clé-valeur sont clairement affichées.

Représentation binaire Protobuf (non lisible par l’homme)

Lorsqu’elles sont sérialisées à l’aide de Protobuf, ces mêmes données peuvent ressembler à ceci en hexadécimal :

0a 2e 53 6f 6d 65 6f 6e 65 20 74 68 61 74 20 68 61 64 20 61 20 63 6c 6f 73 65 20 65 6e 63 6f 75 6e 74 65 72 20 77 69 74 68 20 61 20 73 70 69 64 65 72 12 23 41 62 69 6c 69 74 79 20 74 6f 20 63 6c 69 6e 67 20 74 6f 20 73 6f 6c 69 64 20 73 75 72 66 61 63 65 73 1a 10 41 75 6e 74 27 73 20 43 68 65 72 72 79 20 50 69 65 22 0e 54 68 65 79 20 61 72 65 20 73 6f 20 6d 61 6e 79

Il s’agit exactement des mêmes informations sur les super-héros, mais sérialisées au format binaire de Protobuf. C’est efficace et compact, mais totalement illisible à l’œil nu. Sans décodage, vous n’auriez aucune idée que cela représente quelqu’un avec une histoire liée aux araignées et qui apprécie la tarte aux cerises de tante !

Pourquoi n’est-il pas lisible ?

• Format binaire: Protobuf utilise un codage binaire pour stocker les données, ce qui est efficace mais n’a pas la transparence des formats de texte.
• Numérotation des champs: Chaque champ est identifié par un numéro (par exemple, 1 pour le nom, 2 pour le super pouvoir, etc.) au lieu de son nom au format binaire, ce qui rend difficile d’en déduire la signification sans connaître le schéma.
• Compacité: Le format binaire est conçu pour être aussi compact que possible, de sorte que les chaînes, les nombres et autres types de données sont codés de manière à minimiser l’espace mais à sacrifier la lisibilité.

Tout en énumérant les avantages du format binaire de Protobuf tels que le stockage de données compact, l’analyse rapide, la compatibilité entre langues et entre projets, ainsi que la compatibilité ascendante, le manque de structure lisible par l’homme signifie que vous avez besoin d’outils ou de code pour décoder et interpréter les données. En revanche, les formats JSON ou XML sacrifient les performances pour une meilleure lisibilité, ce qui les rend plus adaptés lorsqu’une inspection humaine est requise.

Cela peut créer un défi lorsque vous essayez d’inspecter le trafic gRPC à des fins de débogage, de test ou de journalisation. Si vous capturez des appels gRPC avec un analyseur de réseau traditionnel, vous verrez généralement des blobs binaires illisibles, ce qui rend difficile la vérification du contenu des demandes et des réponses.

Entrez Fiddler partout

L’un des obstacles courants auxquels les développeurs sont confrontés lorsqu’ils travaillent avec gRPC est la surveillance et le débogage de ses données codées en binaire. Des outils comme Fiddler Everywhere qui prennent en charge HTTP/2 peuvent apporter une solution à ce problème car ils sont capables d’analyser et d’afficher le trafic gRPC dans un format lisible par l’homme. En remarque, vous pouvez également utiliser gRPC avec mode « transcodé » sur HTTP/1.

Pour le bien de cet article de blog, j’ai créé un client et un serveur gRPC dans ASP.NET Core à l’aide de Visual Studio 2022 et .NET 8. Dans mes fichiers de projet de service gRPC, le Protos/salutation.proto le fichier ressemble à ceci :

syntax = "proto3";
option csharp_namespace = "GrpcGreeter";
package  greet;

service  Greeter {
  rpc  SayHello (HelloRequest) returns (Superhero);
}

message  HelloRequest {
  string name = 1;
}

message  Superhero {
  optional  string name = 1;
  optional  string superpower = 2;
  optional  string favorite_food = 3;
  optional  string sidekick_name = 4;
}

Mon client gRPC est une application console .NET et son Protos/salutation.proto le fichier ressemble à ceci :

syntax = "proto3";
option csharp_namespace = "GrpcGreeterClient";
package  greet;


service  Greeter {
  
  rpc  SayHello (HelloRequest) returns (Superhero);
}


message  HelloRequest {
  string name = 1;
}


message  Superhero {
  optional  string name = 1;
  optional  string superpower = 2;
  optional  string favorite_food = 3;
  optional  string sidekick_name = 4;
}

Une fois l’exécution réussie, j’obtiens ce qui suit dans l’invite de commande :

Configuration et capture

Dans Fiddler Everywhere, vous devez configurer le client à l’aide du framework gRPC pour passer par le proxy Fiddler. Cette condition dépend des différents types de clients utilisés.

Cela peut être délicat, surtout si vous utilisez .NET, comme dans mon projet. Si tel est le cas, vous devez connaître un cas spécifique dans gRPC qui empêche un canal gRPC d’utiliser les paramètres de proxy. Une solution possible à cela serait de remplacer le gestionnaire de socket par défaut par HttpHandler (qui désactive/supprime une partie de la logique d’origine et prend en charge l’utilisation des paramètres de proxy). Ceci est valable non seulement pour Fiddler mais pour n’importe quel proxy.

Sans cette solution de contournement, chaque fois que vous exécutez le client avec un proxy activé, vous obtiendrez une erreur du type «HttpRequestException : impossible d’obtenir le sous-canal à partir de HttpRequestMessage. » J’appelle cela une solution de contournement parce qu’un membre de l’équipe grpc-dotnet a suggéré dans l’un des fils de discussion que HttpClientHandler doit être utilisé lorsqu’un proxy se trouve au milieu. Vous pouvez en savoir plus à ce sujet ici et ici.

Après avoir ajouté ce qui suit au client Programme.cs fichier, tout devrait bien se passer et Fiddler Everywhere est prêt à capturer mon super-héros gRPC.

var URL = ;

using  var channel = GrpcChannel.ForAddress(
  URL,
  new GrpcChannelOptions
  {
    HttpHandler = new HttpClientHandler()
  });

var client = new Greeter.GreeterClient(channel);

Inspecter

La session gRPC capturée affiche un badge vert jusqu’à ce que le canal gRPC soit ouvert et un badge rouge lorsque le canal gRPC est fermé.

Double-cliquez sur une session gRPC pour ouvrir le Messages l’onglet et le Inspecteur de messages pour inspecter chaque message gRPC tel qu’il a été reçu à l’origine (le menu contextuel fournit une option de décodage) ou via le Inspecteur HEX. Le Messages L’onglet répertorie les messages gRPC sortants (Expéditeur : Client) et entrants (Expéditeur : Serveur). Vous pouvez voir la taille et le contenu original de chaque message.

Le Messages L’onglet répertorie les messages gRPC sortants (Expéditeur : Client) et entrants (Expéditeur : Serveur). Vous pouvez voir la taille et le contenu original de chaque message.

Décoder

Le contenu brut de Protobuf capturé peut être partiellement visualisé sous forme de texte via le Valeur de décodage et Inspecteur HEX. Le plaisir commence cependant une fois que vous avez le .proto (propriété du créateur du schéma), vous pouvez obtenir les valeurs décodées des champs de message.

Fournir le .proto déposer via le Paramètres > Protobuf > Décoder via le fichier .proto champ. Ainsi, le message gRPC aura une info-bulle indiquant que Fiddler a utilisé un fichier Protobuf pour son décodage. Voici à quoi ça ressemble de mon côté.

Alternativement, les messages gRPC reçus seront automatiquement décodés si la réflexion du serveur est disponible. Fiddler Everywhere détecte immédiatement si le serveur gRPC prend en charge et utilise la réflexion du serveur. Notez que la réflexion du serveur peut ne pas fonctionner lorsqu’il utilise TLS en raison d’erreurs de certificat. Vous pouvez ignorer les erreurs via le Paramètres > HTTPS > Ignorer les erreurs de certificat du serveur option.

Gardez le contrôle de votre trafic gRPC avec Fiddler Everywehre

1. Inspection simplifiée des données Protobuf: Avec la prise en charge intégrée du décodage des messages Protobuf, Fiddler Everywhere vous permet d’afficher les données exactes transmises via gRPC dans un format familier et lisible par l’homme comme JSON. Cela facilite considérablement le débogage, car vous n’avez plus besoin de décoder ou d’écrire manuellement des scripts personnalisés pour analyser les données binaires.
2. Enregistrement complet du trafic: En fournissant un journal complet de toutes les requêtes et réponses gRPC, vous avez un aperçu complet du flux de communication entre les services. Ceci est particulièrement utile pour résoudre des problèmes tels que des appels échoués, des goulots d’étranglement de performances ou des réponses inattendues.
3. Informations détaillées sur la demande et la réponse : Vous pouvez ainsi vérifier que les métadonnées correctes sont envoyées et que l’intégrité des données est intacte entre les services.
4. Expérience de débogage transparente: Son interface conviviale et ses fonctionnalités puissantes permettent un débogage transparent des services gRPC, permettant aux développeurs de se concentrer sur la résolution rapide des problèmes sans avoir à gérer des formats de données encombrants.
5. Prise en charge multiplateforme: Il fonctionne sur macOS, Windows et Linux et peut capturer le trafic de presque n’importe quel client utilisant le protocole HTTP(S).

Alors que gRPC continue de gagner du terrain, le besoin d’outils de débogage et d’inspection efficaces n’a jamais été aussi grand. Fiddler Everywhere intervient en tant que solution polyvalente et multiplateforme qui permet aux développeurs de rendre le trafic gRPC lisible par l’homme, simplifiant ainsi le processus de débogage, de surveillance et de compréhension des interactions gRPC. Que vous dépanniez des interactions de service complexes ou que vous vérifiiez simplement que vos API fonctionnent comme prévu, vous pouvez vous concentrer davantage sur la création et la maintenance d’applications gRPC fiables, et moins sur la gestion des données illisibles.

Bon débogage !

Fiddler Everywhere est livré avec un essai gratuit. Prêt à tenter votre chance ?

Essayez maintenant