O BloomRPC foi a resposta para uma pergunta que todo desenvolvedor gRPC eventualmente faz: “onde está meu Postman para gRPC?” Carregue um arquivo .proto, obtenha um corpo de solicitação JSON editável, clique em enviar. Era simples, era gratuito e conquistou cerca de 9.000 estrelas no GitHub fazendo uma coisa bem feita. Então, em 4 de janeiro de 2023, o repositório foi arquivado. O README não mede palavras: o projeto estagnou, os problemas se acumularam, e os mantenedores agora afirmam claramente que “seu uso não é mais recomendado.” Eles o direcionam para a lista awesome-grpc e desejam boa sorte.
Aqui está a resposta direta: Apidog é a melhor alternativa ao BloomRPC para a maioria das equipes, porque não apenas substitui a janela de carregamento de .proto. Ele suporta todos os quatro tipos de chamadas gRPC (unário, streaming de servidor, streaming de cliente e streaming bidirecional), importa arquivos .proto de um caminho local, uma URL ou reflexão de servidor, e coloca seu trabalho gRPC no mesmo projeto que seus endpoints REST, WebSocket e GraphQL, com documentação, colaboração e configurações de depuração salvas incluídas. Se você precisar apenas de uma chamada descartável de um terminal, existem ferramentas mais leves, e nós as abordaremos honestamente também. Este artigo explica o que morreu com o BloomRPC, o que o substituirá e exatamente como migrar.
O que era o BloomRPC e por que ele se foi
O BloomRPC foi lançado em 2018 como um aplicativo de desktop Electron com um único objetivo: fazer chamadas gRPC sem escrever um cliente. Você importava seus arquivos .proto, ele listava os serviços e métodos, gerava um esqueleto JSON para cada mensagem de solicitação e permitia que você editasse metadados e enviasse. Para chamadas unárias e streaming básico, era bom, e "bom e gratuito" o tornou a GUI gRPC padrão por anos.
O aviso de arquivamento encerra essa era de forma limpa. Um repositório arquivado significa que não há correções de bugs, atualizações de dependências e novos lançamentos. Para um aplicativo Electron, isso não é um estado neutro: as versões empacotadas do Chromium e do Node perdem o suporte de segurança, novas sintaxes de proto e recursos gRPC permanecem sem tratamento, e bugs conhecidos (o BloomRPC tinha problemas de longa data relacionados a importações de proto e certos fluxos de streaming) permanecem exatamente onde estão. Os mantenedores foram honestos sobre isso, o que é mais do que muitos projetos "mortos" conseguem fazer. A mensagem é: pare de instalar isso.
As pessoas ainda procuram pelo BloomRPC porque o formato da ferramenta estava certo. A questão é se você substitui o formato (outra janela gRPC autônoma) ou corrige a fragmentação subjacente: a maioria das equipes que usam gRPC também usam REST, e testá-los em duas ferramentas desconectadas sempre foi o preço que o BloomRPC cobrava silenciosamente. Já escrevemos antes sobre o que torna um bom cliente gRPC; a versão curta é que “carregar protos, enviar chamadas” agora é o básico, e os diferenciais estão acima disso.
A resposta: Apidog
Apidog é uma plataforma de desenvolvimento de API usada por mais de 500.000 desenvolvedores, cobrindo design, depuração, teste, mocking e documentação. Seu suporte a gRPC, de acordo com a documentação oficial, cobre o que o BloomRPC fazia e as partes que o BloomRPC nunca terminou:
- Todos os quatro tipos de chamadas. Unário, streaming de servidor, streaming de cliente e streaming bidirecional são todos suportados. Chamadas de streaming funcionam como uma sessão WebSocket: abra a chamada, então escreva e envie mensagens de uma aba de Mensagens enquanto uma visualização de linha do tempo mostra as mensagens enviadas e recebidas em ordem. O suporte a streaming do BloomRPC era parcial e com bugs no final; aqui é um recurso documentado.
- Três maneiras de importar sua definição de API. Carregue um arquivo .proto local, importe de uma URL ou use a reflexão do servidor para obter serviços diretamente de um servidor gRPC em execução sem arquivos proto à mão. Se seus protos dependerem de outros protos, você adiciona o diretório de dependência uma vez.
- JSON na entrada, JSON na saída. Assim como o BloomRPC, o Apidog renderiza mensagens protobuf como JSON editável, para que você não precise codificar payloads binários manualmente. Se você precisar entender esse mapeamento, consulte protobuf para JSON.
- TLS, metadados e autenticação. Alterne grpc:// ou grpcs:// por solicitação e anexe metadados e configuração de autenticação para as configurações que os serviços reais realmente têm. Para padrões de token e mTLS, nosso guia de autenticação gRPC combina bem com isso.
- Não é um beco sem saída. Chamadas gRPC salvas (URL do servidor, mensagens, metadados) são compartilháveis com colegas de equipe e residem no mesmo espaço de trabalho que seus endpoints REST, cenários de teste e documentos publicados. Essa é a parte que nenhuma janela gRPC autônoma jamais ofereceu.
Como é a transição, recurso por recurso
Fazendo chamadas
O uso diário parecerá familiar. Importe protos, escolha um serviço e método, edite o corpo JSON gerado, defina o endereço do servidor, envie. Chamadas unárias retornam um painel de resposta; chamadas de streaming abrem uma sessão onde você envia mensagens e observa a linha do tempo. Códigos de status retornam como códigos de status gRPC, que são lidos de forma diferente do HTTP; mantenha a referência de código de status gRPC à mão na primeira semana.
Streaming, especificamente
Esta é a atualização mais significativa. O streaming de cliente e bidirecional do BloomRPC eram fontes comuns de seus problemas em aberto. O Apidog documenta todos os quatro modos e trata uma chamada de streaming como uma sessão ao vivo, em vez de uma solicitação única. Se seus serviços dependem de streams, essa diferença é toda a decisão; para mais informações sobre os próprios modos, consulte gRPC streaming explicado.
Reflexão de servidor
O BloomRPC exigia arquivos proto. O Apidog também suporta reflexão de servidor, então você pode apontá-lo para um servidor com reflexão habilitada e navegar em seus serviços sem ter que procurar a revisão de proto correta. Para inspecionar rapidamente um servidor de staging que pertence a outra pessoa, isso remove o passo mais chato.
Além do cliente
Aqui está o salto de categoria. No BloomRPC, uma chamada depurada evaporava quando você fechava a janela. No Apidog, os serviços gRPC ficam dentro de um projeto: colegas de equipe reutilizam sua configuração de depuração salva em vez de reimportar protos e redigitar metadados, e o mesmo espaço de trabalho contém seu trabalho com REST e WebSocket, testes de API gRPC automatizados, mocks para seus endpoints HTTP e documentação publicável. A maioria dos backends gRPC também servem REST ou GraphQL em algum lugar; se você está ponderando essas fronteiras de protocolo, nós os comparamos em REST vs GraphQL vs gRPC e aprofundamos nas compensações em gRPC vs REST.
BloomRPC vs Apidog: Um olhar rápido
| BloomRPC | Apidog | |
|---|---|---|
| Status | Arquivado em Jan 2023; README: uso não recomendado | Ativamente desenvolvido |
| Chamadas unárias | Sim | Sim |
| Streaming de servidor / cliente / bidirecional | Parcial, com problemas conhecidos | Todos suportados, estilo sessão com linha do tempo |
| Importação de Proto | Arquivos .proto locais | Arquivo local, URL, reflexão de servidor |
| TLS | Básico | Alternar grpc:// / grpcs:// por solicitação |
| Metadados e autenticação | Edição de metadados | Metadados mais configuração de autenticação |
| Compartilhamento em equipe | Nenhum (somente local) | Chamadas salvas compartilhadas no workspace da equipe |
| Outros protocolos | Somente gRPC | REST, WebSocket, SSE, GraphQL, gRPC |
| Docs, testes, mocks | Nenhum | Mesma plataforma, mesmo projeto |
| Preço | Gratuito (abandonado) | Plano gratuito para até 4 usuários |
Migrando do BloomRPC
A nota de migração honesta: não há nada para exportar. O BloomRPC não mantinha nenhum estado portátil significativo, o que torna a sua saída trivial:
- Reúna seus arquivos .proto. Eles estão no seu repositório, não no BloomRPC. Isso é todo o "exportar".
- Importe para o Apidog. Crie um projeto, adicione os protos (ou sua URL) e adicione diretórios de dependência se seus protos importarem outros. Serviços e métodos rpc aparecem como serviços e métodos. Ou ignore os arquivos completamente e use a reflexão de servidor contra um servidor em execução.
- Defina o endereço do servidor e TLS. Insira a URL de destino e escolha grpc:// ou grpcs://.
- Recrie metadados e autenticação. Re-adicione os cabeçalhos e tokens que você havia colado no BloomRPC, desta vez salvos com a solicitação para que você os digite apenas uma vez.
- Salve e compartilhe. As chamadas salvas se tornam a configuração de depuração compartilhada da equipe, o que é a primeira coisa que você notará que nunca teve.
Um usuário ativo do BloomRPC deve conseguir enviar chamadas no Apidog em dez minutos, porque os passos 1 a 3 são o mesmo ritual que você já conhece.
Outras alternativas ao BloomRPC que valem a pena conhecer
O Apidog é a resposta se você deseja gRPC dentro de uma plataforma de API completa. Se sua necessidade for mais restrita, seja justo com as ferramentas mais específicas:
- grpcurl: curl para gRPC. A ferramenta certa para scripts shell, verificações de CI e comandos únicos contra servidores com reflexão habilitada; não é uma GUI e não pretende ser. Nós o comparamos em profundidade em a melhor alternativa ao grpcurl.
- grpcui: o irmão do grpcurl que serve uma UI web temporária para um servidor. Bom para uma rápida verificação de cinco minutos, sem estado salvo por design.
- Kreya: um cliente de desktop dedicado para gRPC e REST com um fluxo de trabalho proto aprimorado e um plano gratuito; o mais próximo de um sucessor direto do BloomRPC se você deseja especificamente um cliente autônomo. Veja o que é Kreya e a melhor alternativa ao Kreya para entender seus limites.
- Postman: adicionou suporte a gRPC em 2022, então se sua equipe já paga por ele, funciona; os custos e compensações de workspace usuais do Postman se aplicam, abordados em a melhor alternativa ao Postman.
- evans: um REPL de terminal para gRPC com um modo interativo. Amado por pessoas que vivem no tmux; uma opção inviável para quem queria a GUI do BloomRPC.
O padrão: CLIs para automação, GUIs de propósito único para trabalho gRPC isolado, Apidog quando gRPC é um protocolo entre vários e você quer as chamadas, testes e documentação em um só lugar.
Perguntas frequentes
O BloomRPC ainda é mantido?
Não. O repositório foi arquivado em 4 de janeiro de 2023, e seu README afirma que o uso não é mais recomendado. Não há atualizações, correções de segurança ou novos lançamentos. Qualquer comparação atual de clientes gRPC deve excluí-lo como uma opção para novas configurações.
Posso importar minha configuração do BloomRPC para o Apidog?
Não há arquivo de importação porque o BloomRPC não armazenava nada portátil. A migração significa reimportar os arquivos .proto do seu repositório (ou usar a reflexão do servidor), depois definir o endereço do servidor, o esquema TLS e os metadados. É um trabalho de dez minutos, e depois a configuração é salva e compartilhável em vez de ficar presa em uma máquina.
O Apidog suporta streaming gRPC?
Sim, todos os quatro tipos de chamadas: unário, streaming de servidor, streaming de cliente e streaming bidirecional. Chamadas de streaming funcionam como sessões ao vivo onde você envia mensagens e observa uma linha do tempo de tráfego. Para uma revisão sobre quando cada modo se encaixa, consulte streaming gRPC.
E se eu precisar apenas de chamadas gRPC rápidas pela linha de comando?
Use grpcurl. Ele lida bem com chamadas scriptadas e ad-hoc, especialmente contra servidores com reflexão habilitada, e é adequado para CI independentemente da GUI que você escolher. Nosso guia de alternativas ao grpcurl aborda onde ele deixa de ser suficiente.
Posso testar APIs gRPC e REST na mesma ferramenta?
No Apidog, sim: gRPC, REST, WebSocket, SSE e GraphQL vivem em um projeto, então um serviço que expõe superfícies gRPC e REST tem um único lar. Nosso guia para testar APIs gRPC mostra o fluxo de trabalho de ponta a ponta.
Aposente o cliente arquivado
O BloomRPC disse para você sair; a única pergunta é para onde ir. Aponte o Apidog para seus arquivos .proto ou um servidor com reflexão habilitada, faça suas primeiras chamadas unárias e de streaming, e mantenha-as salvas junto com o resto do seu trabalho de API. Baixe o Apidog gratuitamente; uma equipe de 4 não paga nada, e seus protos são o único arquivo de migração de que você precisa.