La Meilleure Alternative à BloomRPC

BloomRPC répondait à une question simple : « quel est mon Postman pour gRPC ? ». Vous chargiez un fichier .proto, modifiiez un corps de requête JSON, puis envoyiez l’appel. Mais le dépôt a été archivé le 4 janvier 2023 : les mainteneurs indiquent explicitement que son utilisation n’est plus recommandée. Pour une équipe qui travaille encore avec gRPC, il est temps de remplacer cet outil non maintenu.

Essayez Apidog dès aujourd’hui

Apidog est une alternative à BloomRPC qui permet d’exécuter des appels gRPC tout en regroupant REST, WebSocket et GraphQL dans le même projet. Vous pouvez importer des fichiers .proto locaux, une URL ou utiliser la réflexion de serveur, puis enregistrer les requêtes, métadonnées et configurations de débogage pour l’équipe. Si vous avez uniquement besoin d’un appel ponctuel en terminal, des outils plus légers comme grpcurl restent pertinents ; ils sont également présentés plus loin.

Ce qu’était BloomRPC et pourquoi il faut le remplacer

BloomRPC était une application Electron lancée en 2018 pour tester des services gRPC sans écrire de client. Son flux de travail était direct :

1. Importer des fichiers .proto.
2. Sélectionner un service et une méthode RPC.
3. Modifier le JSON généré pour la requête.
4. Ajouter des métadonnées.
5. Envoyer l’appel.

Ce fonctionnement suffisait pour les appels unaires et certains scénarios de streaming. Cependant, un dépôt archivé ne reçoit plus de correctifs, de mises à jour de dépendances ni de nouvelles versions. Pour une application Electron, cela signifie notamment que les dépendances Chromium et Node intégrées vieillissent sans suivi de sécurité.

Les problèmes historiques liés aux imports Proto et à certains flux de streaming restent donc ouverts. Le bon réflexe n’est pas de chercher une ancienne version de BloomRPC : remplacez-le par un client maintenu.

La question est aussi organisationnelle. BloomRPC était un outil gRPC isolé, alors que la plupart des équipes exposent également des API REST, GraphQL ou WebSocket. Utiliser des clients séparés fragmente les requêtes de débogage, les configurations d’authentification et la documentation. Pour les critères d’un client moderne, consultez ce guide sur les clients gRPC.

Remplacer BloomRPC avec Apidog

Selon la documentation officielle, Apidog couvre les besoins principaux de BloomRPC et ajoute des workflows utiles pour les équipes.

1. Tester les quatre types d’appels gRPC

Apidog prend en charge :

• les appels unaires ;
• le streaming côté serveur ;
• le streaming côté client ;
• le streaming bidirectionnel.

Pour les appels en streaming, ouvrez la session, envoyez les messages depuis l’onglet dédié, puis suivez les messages envoyés et reçus dans la chronologie. Cette approche est plus adaptée qu’un modèle de requête unique lorsque votre service maintient une connexion active.

2. Importer les définitions Proto de plusieurs façons

Vous pouvez charger une définition d’API gRPC depuis :

• un fichier .proto local ;
• une URL ;
• la réflexion de serveur.

Si vos fichiers Proto importent d’autres définitions, ajoutez le répertoire de dépendances au projet. Si la réflexion est activée sur le serveur gRPC, vous pouvez parcourir directement les services exposés sans rechercher la bonne version des fichiers .proto.

3. Modifier les messages en JSON

Comme dans BloomRPC, les messages Protobuf sont affichés sous forme de JSON modifiable. Vous évitez ainsi de construire manuellement des charges utiles binaires.

Exemple de requête JSON pour une méthode unaire :

{
  "userId": "42",
  "includeArchived": false
}

Pour comprendre les règles de conversion entre les deux formats, consultez ce guide sur la conversion de Protobuf vers JSON.

4. Configurer TLS, métadonnées et authentification

Pour chaque requête, définissez l’adresse cible avec :

• grpc:// pour une connexion non chiffrée ;
• grpcs:// pour une connexion TLS.

Ajoutez ensuite les métadonnées requises par le service, par exemple :

authorization: Bearer <token>
x-request-id: debug-001

Pour les jetons, mTLS et les autres stratégies d’accès, référez-vous aux bonnes pratiques d’authentification gRPC.

5. Enregistrer et partager les requêtes

Dans BloomRPC, une configuration de débogage restait principalement locale. Dans Apidog, vous pouvez enregistrer l’URL du serveur, les messages, les métadonnées et les configurations associées dans le projet partagé.

Cela permet aux autres membres de l’équipe de réutiliser un appel sans :

• réimporter les fichiers Proto ;
• retrouver les en-têtes nécessaires ;
• recopier les paramètres TLS ;
• reconstruire la requête JSON.

Flux de travail : effectuer un appel gRPC

Voici un flux de migration pratique pour vos appels habituels.

Appel unaire

1. Importez vos fichiers .proto.
2. Sélectionnez le service et la méthode RPC.
3. Saisissez l’URL du serveur.
4. Choisissez grpc:// ou grpcs://.
5. Ajoutez les métadonnées nécessaires.
6. Modifiez le JSON de requête généré.
7. Envoyez l’appel.
8. Vérifiez le message de réponse et le code de statut gRPC.
9. Enregistrez la requête si elle doit être réutilisée.

Les codes de statut gRPC diffèrent des codes HTTP. Gardez cette référence des codes de statut gRPC à portée de main lors de la migration.

Appel en streaming

Pour un appel client-streaming ou bidirectionnel :

1. Ouvrez la méthode RPC concernée.
2. Démarrez la session.
3. Envoyez un premier message JSON.
4. Continuez à envoyer les messages nécessaires.
5. Surveillez la chronologie des messages entrants et sortants.
6. Fermez la session lorsque le scénario est terminé.

Le streaming est l’un des points qui justifie le plus fortement le remplacement de BloomRPC. Son support historique était partiel et source de problèmes ouverts. Pour choisir le bon mode, consultez ce guide sur le streaming gRPC.

Utiliser la réflexion de serveur

La réflexion de serveur permet d’inspecter un serveur gRPC sans récupérer manuellement ses fichiers .proto.

Utilisez-la lorsque :

• vous diagnostiquez un environnement de staging ;
• vous devez explorer un service détenu par une autre équipe ;
• vous ne connaissez pas la révision exacte des Proto ;
• le serveur expose déjà la réflexion gRPC.

Le flux est simple :

1. Connectez-vous au serveur gRPC.
2. Utilisez la réflexion de serveur.
3. Parcourez les services et méthodes disponibles.
4. Sélectionnez une méthode.
5. Renseignez les métadonnées et le corps JSON.
6. Envoyez l’appel.

BloomRPC vs Apidog en un coup d’œil

Fonctionnalité	BloomRPC	Apidog
Statut	Archivé en janvier 2023 ; utilisation non recommandée	Activement développé
Appels unaires	Oui	Oui
Streaming serveur, client et bidirectionnel	Partiel, avec des problèmes connus	Pris en charge avec chronologie de session
Importation Proto	Fichiers .proto locaux	Fichier local, URL, réflexion de serveur
TLS	Basique	Choix grpc:// / grpcs:// par requête
Métadonnées et authentification	Édition des métadonnées	Métadonnées et configuration d’authentification
Partage d’équipe	Local uniquement	Requêtes enregistrées dans l’espace de travail
Autres protocoles	gRPC uniquement	REST, WebSocket, SSE, GraphQL, gRPC
Documentation, tests et mocks	Non	Dans le même projet
Prix	Gratuit, mais abandonné	Plan gratuit jusqu’à 4 utilisateurs

Migrer depuis BloomRPC

BloomRPC ne stockait pas d’état portable significatif. La migration est donc courte.

Étape 1 — Rassemblez les fichiers .proto

Vos fichiers .proto doivent déjà se trouver dans votre dépôt ou dans un registre interne. C’est l’essentiel de la migration.

Étape 2 — Créez ou ouvrez un projet Apidog

Dans Apidog, créez un projet, puis importez :

• les fichiers .proto locaux ;
• ou l’URL qui les expose ;
• ou les services disponibles par réflexion de serveur.

Ajoutez les dossiers de dépendances si vos Proto importent d’autres fichiers.

Étape 3 — Définissez la cible gRPC

Renseignez l’adresse du serveur, par exemple :

grpcs://api.example.com:443

ou, pour un environnement local :

grpc://localhost:50051

Étape 4 — Recréez les métadonnées

Ajoutez les en-têtes ou jetons que vous utilisiez dans BloomRPC :

authorization: Bearer <token>
x-tenant-id: acme

Enregistrez ensuite la requête afin d’éviter de les ressaisir.

Étape 5 — Validez les appels critiques

Commencez par les scénarios les plus utiles :

1. un appel unaire ;
2. un appel authentifié ;
3. un appel nécessitant TLS ;
4. un appel de streaming, si votre API en utilise ;
5. une erreur attendue, pour vérifier les codes de statut.

Étape 6 — Partagez les requêtes enregistrées

Transformez vos appels de débogage en configurations partagées. C’est l’amélioration immédiate par rapport à un client local isolé.

Pour un utilisateur déjà habitué à BloomRPC, les trois premières étapes prennent généralement moins de dix minutes : elles reprennent le même rituel d’import Proto, de sélection de méthode et d’envoi de requête.

Autres alternatives à BloomRPC

Apidog convient si vous voulez gérer gRPC au sein d’une plateforme API plus large. Pour des besoins plus ciblés, considérez également les outils suivants.

• grpcurl : l’équivalent de curl pour gRPC. Adapté aux scripts shell, à la CI et aux appels ponctuels, en particulier si la réflexion de serveur est disponible. Consultez aussi ce comparatif des alternatives à grpcurl.
• grpcui : une interface web temporaire servie pour un serveur donné. Pratique pour une inspection rapide, sans conserver de configuration.
• Kreya : un client de bureau dédié à gRPC et REST. C’est l’un des successeurs les plus proches de BloomRPC si vous recherchez spécifiquement un client autonome. Voir ce qu’est Kreya et ses alternatives.
• Postman : Postman a ajouté le support gRPC en 2022. C’est une option si votre équipe l’utilise déjà, avec les compromis habituels de l’espace de travail et de la tarification. Consultez les alternatives à Postman.
• evans : un REPL terminal gRPC interactif, utile pour les développeurs qui travaillent principalement dans le terminal.

En pratique :

• utilisez une CLI comme grpcurl pour l’automatisation ;
• utilisez un client autonome pour les besoins gRPC isolés ;
• utilisez Apidog lorsque gRPC coexiste avec REST, GraphQL, WebSocket, des tests et de la documentation d’API.

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 ne reçoit plus de mises à jour, de correctifs de sécurité ou de nouvelles versions. Pour une nouvelle configuration, choisissez un client gRPC maintenu.

Puis-je importer ma configuration BloomRPC dans Apidog ?

BloomRPC ne propose pas de fichier de configuration portable à importer. La migration consiste à réimporter vos fichiers .proto ou à utiliser la réflexion de serveur, puis à configurer l’adresse cible, TLS et les métadonnées.

Apidog prend-il en charge le streaming gRPC ?

Oui. Apidog prend en charge les appels unaires, le streaming côté serveur, le streaming côté client et le streaming bidirectionnel. Les appels de streaming fonctionnent comme des sessions actives avec une chronologie des messages. Pour revoir les différents modes, consultez le guide du streaming gRPC.

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

Utilisez grpcurl. Il est adapté aux appels scriptés et ponctuels, notamment sur les serveurs qui activent la réflexion. Il reste également pertinent dans une pipeline CI, quel que soit le client graphique choisi. Le guide des alternatives à grpcurl détaille ses limites selon les usages.

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

Oui. Dans Apidog, gRPC, REST, WebSocket, SSE et GraphQL résident dans un même projet. Vous pouvez donc conserver les requêtes, les tests et la documentation d’un même backend au même endroit. Consultez ce guide sur le test des API gRPC pour un workflow complet.

Retirez le client archivé

BloomRPC a rendu service, mais son dépôt archivé ne doit plus faire partie d’un workflow de développement actif. Importez vos fichiers .proto dans Apidog ou connectez-vous à un serveur qui active la réflexion, validez vos appels unaires et de streaming, puis enregistrez les configurations utiles pour l’équipe.

Téléchargez Apidog gratuitement : le plan gratuit couvre jusqu’à quatre utilisateurs, et vos fichiers Proto sont l’élément principal à migrer.