La Meilleure Alternative à BloomRPC

BloomRPC était la réponse à une question que tout développeur gRPC finit par se poser : « où est mon Postman pour gRPC ? » Chargez un fichier .proto, obtenez un corps de requête JSON éditable, appuyez sur envoyer. C'était simple, c'était gratuit, et cela a récolté environ 9 000 étoiles sur GitHub en faisant une seule chose bien. Puis, le 4 janvier 2023, le dépôt a été archivé. Le README ne mâche pas ses mots : le projet a stagné, les problèmes se sont accumulés, et les mainteneurs déclarent maintenant clairement que « son utilisation n'est plus recommandée ». Ils vous orientent vers la liste awesome-grpc et vous souhaitent bonne chance.

Voici la réponse directe : Apidog est la meilleure alternative à BloomRPC pour la plupart des équipes, car il ne se contente pas de remplacer la fenêtre de chargement .proto. Il prend en charge les quatre types d'appels gRPC (unaires, streaming côté serveur, streaming côté client et streaming bidirectionnel), importe les fichiers .proto à partir d'un chemin local, d'une URL ou de la réflexion de serveur, et place votre travail gRPC dans le même projet que vos points de terminaison REST, WebSocket et GraphQL, avec documentation, collaboration et configurations de débogage enregistrées incluses. Si vous n'avez besoin que d'un appel ponctuel depuis un terminal, des outils plus légers existent, et nous les couvrirons honnêtement aussi. Cet article explique ce qui est mort avec BloomRPC, par quoi le remplacer, et exactement comment migrer.

Ce qu'était BloomRPC et pourquoi il a disparu

BloomRPC a été lancé en 2018 sous forme d'application de bureau Electron avec une seule tâche : effectuer des appels gRPC sans écrire de client. Vous importiez vos fichiers .proto, il listait les services et les méthodes, générait un squelette JSON pour chaque message de requête, et vous permettait de modifier les métadonnées et d'envoyer. Pour les appels unaires et le streaming de base, c'était suffisant, et « suffisant et gratuit » en a fait l'interface graphique gRPC par défaut pendant des années.

L'avis d'archivage met fin à cette ère proprement. Un dépôt archivé signifie pas de corrections de bugs, pas de mises à jour de dépendances et pas de nouvelles versions. Pour une application Electron, ce n'est pas un état neutre : les versions embarquées de Chromium et Node vieillissent et perdent leur support de sécurité, les nouvelles syntaxes proto et les fonctionnalités gRPC ne sont pas gérées, et les bugs connus (BloomRPC avait des problèmes de longue date concernant les importations proto et certains flux de streaming) restent exactement là où ils sont. Les mainteneurs ont été honnêtes à ce sujet, ce que de nombreux projets abandonnés ne parviennent pas à faire. Le message est clair : arrêtez d'installer ceci.

Les gens recherchent toujours BloomRPC parce que la forme de l'outil était bonne. La question est de savoir si vous remplacez la forme (une autre fenêtre gRPC autonome) ou si vous corrigez la fragmentation sous-jacente : la plupart des équipes qui exécutent gRPC exécutent également REST, et les tester dans deux outils déconnectés a toujours été la taxe que BloomRPC facturait discrètement. Nous avons déjà écrit sur ce qui fait un bon client gRPC ; la version courte est que « charge les protos, envoie les appels » est désormais la base, et les différenciateurs se situent au-dessus de cela.

La réponse : Apidog

Apidog est une plateforme de développement d'API utilisée par plus de 500 000 développeurs, couvrant la conception, le débogage, les tests, le mocking et la documentation. Son support gRPC, selon la documentation officielle, couvre ce que BloomRPC faisait et les parties que BloomRPC n'a jamais terminées :

1. Les quatre types d'appels. Les appels unaires, le streaming côté serveur, le streaming côté client et le streaming bidirectionnel sont tous pris en charge. Les appels de streaming fonctionnent comme une session WebSocket : ouvrez l'appel, puis écrivez et envoyez des messages depuis un onglet Message pendant qu'une vue chronologique affiche les messages envoyés et reçus dans l'ordre. Le support de streaming de BloomRPC était partiel et bogué à la fin ; ici, c'est une fonctionnalité documentée.
2. Trois façons d'importer votre définition d'API. Chargez un fichier .proto local, importez à partir d'une URL, ou utilisez la réflexion de serveur pour extraire les services directement d'un serveur gRPC en cours d'exécution sans avoir de fichiers proto sous la main. Si vos protos dépendent d'autres protos, vous ajoutez le répertoire de dépendances une seule fois.
3. JSON en entrée, JSON en sortie. Comme BloomRPC, Apidog rend les messages protobuf sous forme de JSON éditable, vous n'avez donc pas à coder manuellement des charges utiles binaires. Si vous avez besoin de comprendre ce mappage, consultez protobuf vers JSON.
4. TLS, métadonnées et authentification. Activez grpc:// ou grpcs:// par requête, et attachez des métadonnées et une configuration d'authentification pour les configurations que les services réels utilisent réellement. Pour les modèles de jetons et mTLS, notre guide d'authentification gRPC se marie bien avec cela.
5. Ce n'est pas une impasse. Les appels gRPC enregistrés (URL du serveur, messages, métadonnées) peuvent être partagés avec les membres de l'équipe, et ils vivent dans le même espace de travail que vos points de terminaison REST, vos scénarios de test et vos documents publiés. C'est la partie qu'aucune fenêtre gRPC autonome n'a jamais offerte.

À quoi ressemble le passage, fonctionnalité par fonctionnalité

Effectuer des appels

L'utilisation quotidienne sera familière. Importez les protos, choisissez un service et une méthode, modifiez le corps JSON généré, définissez l'adresse du serveur, envoyez. Les appels unaires renvoient un panneau de réponse ; les appels en streaming ouvrent une session où vous envoyez des messages et observez la chronologie. Les codes de statut sont renvoyés en tant que codes de statut gRPC, qui se lisent différemment du HTTP ; gardez la référence des codes de statut gRPC à portée de main la première semaine.

Le streaming, spécifiquement

C'est l'amélioration la plus nette. Le streaming côté client et bidirectionnel de BloomRPC était une source courante de ses problèmes ouverts. Apidog documente les quatre modes et traite un appel en streaming comme une session en direct plutôt que comme une requête unique. Si vos services s'appuient sur des flux, cette différence est toute la décision ; pour des informations sur les modes eux-mêmes, voir explication du streaming gRPC.

Réflexion de serveur

BloomRPC nécessitait des fichiers proto. Apidog prend également en charge la réflexion de serveur, vous pouvez donc le pointer vers un serveur activé pour la réflexion et parcourir ses services sans avoir à rechercher la bonne révision proto. Pour examiner rapidement un serveur de staging appartenant à quelqu'un d'autre, cela supprime l'étape la plus ennuyeuse.

Au-delà du client

Voici le saut de catégorie. Dans BloomRPC, un appel débogué s'évaporait lorsque vous fermiez la fenêtre. Dans Apidog, les services gRPC se trouvent au sein d'un projet : les coéquipiers réutilisent votre configuration de débogage enregistrée au lieu de réimporter des protos et de retaper des métadonnées, et le même espace de travail contient votre travail REST et WebSocket, des tests d'API gRPC automatisés, des mocks pour vos points de terminaison HTTP, et des documents publiables. La plupart des backends gRPC servent également REST ou GraphQL quelque part ; si vous pesez ces limites de protocole, nous les avons comparés dans REST vs GraphQL vs gRPC et approfondi les compromis dans gRPC vs REST.

BloomRPC vs Apidog en un coup d'œil

Migration depuis BloomRPC

La note honnête sur la migration : il n'y a rien à exporter. BloomRPC ne conservait aucun état portable significatif, ce qui rend son abandon trivial :

1. Rassemblez vos fichiers .proto. Ils résident dans votre dépôt, pas dans BloomRPC. C'est toute l'« exportation ».
2. Importez-les dans Apidog. Créez un projet, ajoutez les protos (ou leur URL), et ajoutez des répertoires de dépendances si vos protos en importent d'autres. Les services et les méthodes rpc apparaissent comme des services et des méthodes. Ou ignorez entièrement les fichiers et utilisez la réflexion de serveur sur un serveur en cours d'exécution.
3. Définissez l'adresse du serveur et TLS. Entrez l'URL cible et choisissez grpc:// ou grpcs://.
4. Recréez les métadonnées et l'authentification. Réajoutez les en-têtes et les jetons que vous aviez collés dans BloomRPC, cette fois-ci enregistrés avec la requête afin de les taper une seule fois.
5. Enregistrez et partagez. Les appels enregistrés deviennent la configuration de débogage partagée de l'équipe, ce qui est la première chose que vous remarquerez que vous n'aviez jamais eue.

Un utilisateur de BloomRPC opérationnel devrait envoyer des appels dans Apidog en moins de dix minutes, car les étapes 1 à 3 sont le même rituel que vous connaissez déjà.

Autres alternatives à BloomRPC à connaître

Apidog est la réponse si vous souhaitez gRPC au sein d'une plateforme API complète. Si votre besoin est plus étroit, soyez juste envers les outils spécifiques :

• grpcurl : curl pour gRPC. L'outil idéal pour les scripts shell, les contrôles CI et les commandes en une ligne sur des serveurs compatibles avec la réflexion ; ce n'est pas une interface graphique et il ne prétend pas l'être. Nous l'avons comparé en profondeur dans la meilleure alternative à grpcurl.
• grpcui : le frère de grpcurl qui sert une interface utilisateur web temporaire pour un seul serveur. Bon pour un coup d'œil de cinq minutes, sans état enregistré par conception.
• Kreya : un client de bureau dédié à gRPC et REST avec un workflow proto soigné et un niveau gratuit ; ce qui se rapproche le plus d'un successeur direct de BloomRPC si vous voulez spécifiquement un client autonome. Voir ce qu'est Kreya et la meilleure alternative à Kreya pour connaître ses limites.
• Postman : a ajouté le support gRPC en 2022, donc si votre équipe le paie déjà, cela fonctionne ; les tarifs habituels de Postman et les compromis liés à l'espace de travail s'appliquent, couverts dans la meilleure alternative à Postman.
• evans : un REPL terminal pour gRPC avec un mode interactif. Apprécié par les personnes qui vivent dans tmux ; un non-départ pour quiconque voulait l'interface graphique de BloomRPC.

Le schéma : les CLI pour l'automatisation, les interfaces graphiques à usage unique pour le travail gRPC isolé, Apidog lorsque gRPC est un protocole parmi plusieurs et que vous voulez les appels, les tests et la documentation en un seul endroit.

Questions fréquemment posées

BloomRPC est-il toujours maintenu ?

Non. Le dépôt a été archivé le 4 janvier 2023, et son README indique que son utilisation n'est plus recommandée. Il n'y a pas de mises à jour, de correctifs de sécurité ou de nouvelles versions à venir. Toute comparaison actuelle de client gRPC devrait l'exclure comme option pour les nouvelles configurations.

Puis-je importer ma configuration BloomRPC dans Apidog ?

Il n'y a pas de fichier d'importation car BloomRPC ne stockait rien de portable. La migration signifie réimporter les fichiers .proto de votre dépôt (ou utiliser la réflexion de serveur), puis définir l'adresse du serveur, le schéma TLS et les métadonnées. C'est un travail de dix minutes, et ensuite la configuration est enregistrée et partageable au lieu d'être piégée sur une seule machine.

Apidog prend-il en charge le streaming gRPC ?

Oui, les quatre types d'appels : unaire, streaming serveur, streaming client et streaming bidirectionnel. Les appels en streaming s'exécutent comme des sessions en direct où vous envoyez des messages et observez une chronologie du trafic. Pour un rappel sur le moment où chaque mode est approprié, consultez streaming gRPC.

Et si je n'ai besoin que d'appels gRPC rapides en ligne de commande ?

Utilisez grpcurl. Il gère bien les appels scriptés et ad-hoc, en particulier sur les serveurs activés pour la réflexion, et il devrait être dans votre CI, quel que soit l'interface graphique que vous choisissez. Notre guide des alternatives à grpcurl explique où il cesse d'être suffisant.

Puis-je tester les API gRPC et REST dans le même outil ?

Dans Apidog, oui : gRPC, REST, WebSocket, SSE et GraphQL résident dans un seul projet, de sorte qu'un service qui expose à la fois des surfaces gRPC et REST trouve un foyer unique. Notre guide sur le test des API gRPC montre le flux de travail de bout en bout.

Retirez le client archivé

BloomRPC vous a dit de partir ; la seule question est de savoir où. Pointez Apidog vers vos fichiers .proto ou un serveur activé pour la réflexion, effectuez vos premiers appels unaires et en streaming, et gardez-les enregistrés à côté du reste de votre travail API. Téléchargez Apidog gratuitement ; une équipe de 4 personnes ne paie rien, et vos protos sont le seul fichier de migration dont vous avez besoin.