O BloomRPC respondeu a uma pergunta comum entre desenvolvedores gRPC: “onde está meu Postman para gRPC?”. O fluxo era direto: carregar um arquivo .proto, editar o corpo JSON da solicitação e enviar a chamada. O projeto chegou a cerca de 9.000 estrelas no GitHub, mas foi arquivado em 4 de janeiro de 2023. O próprio README informa que o projeto estagnou, acumulou problemas e que seu uso não é mais recomendado. O repositório permanece arquivado no GitHub.
Para a maioria das equipes, o Apidog é uma alternativa prática ao BloomRPC. Além de carregar arquivos .proto, ele oferece suporte aos quatro tipos de chamadas gRPC — unário, streaming de servidor, streaming de cliente e streaming bidirecional — e permite importar definições por arquivo local, URL ou reflexão de servidor. As chamadas gRPC também ficam no mesmo projeto que endpoints REST, WebSocket e GraphQL, além de testes, documentação, colaboração e configurações de depuração salvas.
O que era o BloomRPC — e por que substituí-lo
Lançado em 2018 como um aplicativo Electron, o BloomRPC tinha um objetivo: permitir chamadas gRPC sem escrever um cliente. Você importava arquivos .proto, selecionava serviços e métodos, preenchia o JSON da mensagem, adicionava metadados e enviava a chamada.
Esse fluxo ainda é útil. O problema é que um repositório arquivado deixa de receber:
- correções de bugs;
- atualizações de dependências;
- atualizações de segurança para Chromium e Node;
- suporte a novos recursos ou sintaxes de protobuf;
- melhorias em cenários de streaming.
O BloomRPC também tinha problemas conhecidos com importações de .proto e determinados fluxos de streaming. Para novos ambientes, a recomendação dos mantenedores é clara: não utilizá-lo.
A decisão prática agora é escolher entre:
- uma GUI gRPC isolada;
- uma CLI para automação e verificações rápidas;
- uma plataforma que reúna gRPC, REST, testes e documentação.
Já explicamos os critérios de um bom cliente gRPC: carregar protos e enviar chamadas é o básico. O diferencial está em como a ferramenta lida com streaming, autenticação, compartilhamento e manutenção do fluxo de trabalho.
Por que usar o Apidog como alternativa
Segundo a documentação oficial do Apidog, o suporte a gRPC cobre os fluxos essenciais para substituir o BloomRPC.
1. Execute todos os tipos de chamadas gRPC
O Apidog oferece suporte a:
- chamadas unárias;
- streaming de servidor;
- streaming de cliente;
- streaming bidirecional.
Em chamadas de streaming, trate a requisição como uma sessão ativa: envie mensagens pela aba de mensagens e acompanhe os eventos enviados e recebidos em uma linha do tempo.
2. Importe definições por .proto, URL ou reflexão
Você pode carregar sua API de três formas:
- importar um arquivo
.protolocal; - importar um
.protopor URL; - usar a reflexão do servidor para descobrir serviços diretamente em um servidor gRPC em execução.
Se os protos tiverem dependências, configure o diretório de importação correspondente uma vez.
3. Trabalhe com JSON em vez de payload binário
Assim como no BloomRPC, as mensagens protobuf são exibidas como JSON editável. Por exemplo, para uma definição como esta:
service UserService {
rpc GetUser(GetUserRequest) returns (GetUserResponse);
}
message GetUserRequest {
string id = 1;
}
Você pode preencher a solicitação desta forma:
{
"id": "user_123"
}
Para entender melhor a conversão, consulte o guia sobre protobuf para JSON.
4. Configure TLS, metadados e autenticação
Para cada chamada, defina:
- o endereço do servidor;
- o esquema
grpc://ougrpcs://; - metadados;
- tokens ou outras configurações de autenticação.
Exemplo de metadados para um token Bearer:
authorization: Bearer <seu-token>
x-request-id: debug-local-001
Para cenários com tokens e mTLS, consulte as boas práticas de autenticação gRPC.
5. Salve e compartilhe configurações de depuração
No BloomRPC, a configuração de uma chamada ficava essencialmente local. No Apidog, chamadas salvas podem incluir:
- URL do servidor;
- método gRPC;
- corpo da mensagem;
- metadados;
- configuração de autenticação.
Isso permite que a equipe reutilize uma configuração de depuração sem reimportar protos ou copiar cabeçalhos manualmente.
Migração do BloomRPC para o Apidog
Não existe uma exportação relevante do BloomRPC. Na prática, os arquivos .proto no seu repositório são o principal artefato de migração.
Passo 1: localize os arquivos .proto
Reúna os protos e seus diretórios de dependência no repositório.
Uma estrutura comum pode ser:
proto/
├── user/
│ └── user_service.proto
└── common/
└── pagination.proto
Se user_service.proto importar common/pagination.proto, você precisará informar o diretório raiz adequado ao importar.
Passo 2: importe os protos ou use reflexão
No Apidog:
- crie ou abra um projeto;
- adicione uma API gRPC;
- importe o arquivo
.proto, uma URL ou use reflexão de servidor; - adicione diretórios de dependência quando necessário;
- selecione o serviço e o método RPC.
Se o servidor tiver reflexão habilitada, você pode evitar a busca manual pela revisão correta dos arquivos .proto.
Passo 3: configure o servidor
Defina o endpoint gRPC, por exemplo:
grpc://localhost:50051
Ou, para TLS:
grpcs://api.exemplo.com:443
Passo 4: recrie metadados e autenticação
Adicione novamente os cabeçalhos, tokens e dados de autenticação usados no BloomRPC.
Exemplo:
authorization: Bearer eyJ...
x-tenant-id: tenant_01
Salve a chamada depois de validar a configuração.
Passo 5: valide uma chamada unária
Use uma solicitação simples para confirmar conectividade, autenticação e serialização:
{
"id": "user_123"
}
Verifique:
- código de status gRPC;
- mensagem retornada;
- metadados de resposta;
- erros de validação ou autenticação.
Os códigos gRPC não correspondem diretamente aos códigos HTTP. Mantenha à mão a referência de códigos de status gRPC durante a migração.
Passo 6: teste fluxos de streaming
Para streaming de cliente ou bidirecional:
- abra a sessão;
- envie mensagens individualmente;
- observe a linha do tempo;
- confirme as mensagens recebidas;
- encerre o stream conforme o comportamento esperado pelo serviço.
Se a sua API depende de streams, esse é o ponto mais importante da substituição. Veja também gRPC streaming explicado.
Comparativo rápido: BloomRPC vs. Apidog
| Recurso | BloomRPC | Apidog |
|---|---|---|
| Status | Arquivado em janeiro de 2023; uso não recomendado | Ativamente desenvolvido |
| Chamadas unárias | Sim | Sim |
| Streaming de servidor, cliente e bidirecional | Parcial, com problemas conhecidos | Suportado nos quatro modos |
| Importação de proto | Arquivos .proto locais |
Arquivo local, URL e reflexão de servidor |
| TLS | Básico |
grpc:// ou grpcs:// por solicitação |
| Metadados e autenticação | Edição de metadados | Metadados e configurações de autenticação |
| Compartilhamento em equipe | Local | Chamadas salvas no workspace |
| Outros protocolos | Apenas gRPC | REST, WebSocket, SSE, GraphQL e gRPC |
| Documentação, testes e mocks | Não | No mesmo projeto |
| Preço | Gratuito, mas abandonado | Plano gratuito para até 4 usuários |
Além do cliente gRPC
O principal ganho não é apenas substituir a janela do BloomRPC. É centralizar o trabalho de API.
No Apidog, serviços gRPC podem coexistir com:
- endpoints REST;
- coleções WebSocket;
- APIs GraphQL;
- cenários de teste;
- mocks HTTP;
- documentação publicada.
Isso é útil quando o backend expõe mais de um protocolo. Para implementar testes automatizados, consulte o guia de testes de APIs gRPC.
Se você está escolhendo protocolos para novos serviços, veja também:
Outras alternativas ao BloomRPC
O Apidog é indicado quando gRPC é parte de um fluxo de trabalho de API mais amplo. Para necessidades específicas, outras ferramentas também podem fazer sentido.
-
grpcurl: equivalente ao
curlpara gRPC. Útil para scripts shell, CI e chamadas rápidas contra servidores com reflexão habilitada. Veja a comparação com a melhor alternativa ao grpcurl. - grpcui: interface web temporária associada ao grpcurl. Boa para inspeções rápidas, sem persistência de estado.
- Kreya: cliente desktop para gRPC e REST, mais próximo de um sucessor direto do BloomRPC para quem quer uma ferramenta autônoma. Consulte o que é Kreya e a melhor alternativa ao Kreya.
- Postman: possui suporte a gRPC desde 2022. É uma opção para equipes que já o utilizam, considerando os custos e limites do workspace. Veja a melhor alternativa ao Postman.
- evans: REPL de terminal para gRPC com modo interativo. É útil para quem trabalha no terminal, mas não substitui uma GUI para todos os perfis.
A regra prática é simples:
- use CLIs para automação;
- use clientes dedicados para trabalho gRPC isolado;
- use o Apidog quando quiser manter chamadas, testes e documentação no mesmo lugar.
Perguntas frequentes
O BloomRPC ainda é mantido?
Não. O repositório foi arquivado em 4 de janeiro de 2023, e o README informa que seu uso não é mais recomendado. Não há novos lançamentos, atualizações de segurança ou correções de bugs.
Para novos projetos, qualquer comparação de clientes gRPC deve tratá-lo como uma ferramenta descontinuada.
Posso importar a configuração do BloomRPC para o Apidog?
Não há um arquivo de importação portátil do BloomRPC. A migração consiste em:
- reimportar os arquivos
.protodo repositório, ou usar reflexão; - configurar o endereço do servidor;
- definir TLS;
- adicionar metadados e autenticação;
- salvar a chamada no projeto.
O Apidog suporta streaming gRPC?
Sim. Ele suporta chamadas unárias, streaming de servidor, streaming de cliente e streaming bidirecional.
Em chamadas de streaming, envie mensagens em uma sessão ativa e acompanhe a linha do tempo de tráfego. Para revisar os modos, consulte o guia de streaming gRPC.
E se eu precisar apenas de chamadas gRPC rápidas no terminal?
Use grpcurl. Ele funciona bem para chamadas ad-hoc, scripts e CI, especialmente quando a reflexão de servidor está habilitada.
O guia de alternativas ao grpcurl explica quando uma CLI deixa de ser suficiente.
Posso testar APIs gRPC e REST na mesma ferramenta?
No Apidog, sim. gRPC, REST, WebSocket, SSE e GraphQL ficam no mesmo projeto. Isso facilita manter testes e documentação próximos do serviço que está sendo desenvolvido.
Veja o fluxo completo no guia para testar APIs gRPC.
Aposente o cliente arquivado
O BloomRPC foi útil, mas seu próprio repositório recomenda seguir em frente. Para migrar, importe seus arquivos .proto ou conecte-se a um servidor com reflexão habilitada, valide chamadas unárias e de streaming, configure autenticação e salve as requisições para a equipe.
Você pode baixar o Apidog gratuitamente. Seus arquivos .proto são, na prática, o único artefato de migração necessário.
Top comments (0)