The Best BloomRPC Alternative

BloomRPC answered a question every gRPC developer eventually asks: where is the Postman for gRPC? You loaded a .proto file, edited a generated JSON request body, and sent the call. It was simple, free, and earned around 9,000 GitHub stars. But on January 4, 2023, the repository was archived. Its README states that the project stalled, issues accumulated, and “its usage is no longer recommended.”

Try Apidog today

For most teams, Apidog is a practical BloomRPC replacement. It supports unary, server-streaming, client-streaming, and bidirectional-streaming calls; imports .proto files from local paths, URLs, or server reflection; and keeps gRPC requests alongside REST, WebSocket, and GraphQL APIs. This guide shows how to replace BloomRPC and migrate your existing workflow.

What BloomRPC was, and why it is gone

BloomRPC launched in 2018 as an Electron desktop app for making gRPC calls without writing a client. Its workflow was straightforward:

1. Import .proto files.
2. Select a service and RPC method.
3. Edit the generated JSON request.
4. Add metadata.
5. Send the request.

That was enough for unary calls and basic streaming. However, an archived repository means no bug fixes, dependency updates, or releases. For an Electron application, that also means its bundled Chromium and Node.js versions continue aging without security support.

The project also had long-standing issues with proto imports and some streaming flows. The maintainers’ recommendation is clear: do not use it for new setups.

Developers still search for BloomRPC because the original workflow was useful. The decision now is whether to choose another isolated gRPC client or consolidate API workflows in one tool. A modern gRPC client should do more than load protos and send calls.

The replacement: Apidog

Apidog is an API development platform for API design, debugging, testing, mocking, and documentation. According to the official gRPC documentation, its gRPC workflow covers BloomRPC’s core use cases and adds support for production-oriented workflows.

1. Run every gRPC call type

Apidog supports:

• Unary calls
• Server streaming
• Client streaming
• Bidirectional streaming

For streaming requests, treat the RPC as an active session:

1. Open the RPC method.
2. Start the connection.
3. Send messages from the Message tab.
4. Inspect sent and received messages in timeline order.

This is especially important if your services use client or bidirectional streaming, where BloomRPC had known limitations.

2. Import API definitions in three ways

You can load a gRPC API from:

• A local .proto file
• A URL
• Server reflection

For local proto files with imports, add the directory containing dependencies. For example, if your service imports Google protobuf types:

import "google/protobuf/timestamp.proto";

Add the directory that contains google/protobuf as a dependency path during import.

If a staging server has reflection enabled, skip proto-file management entirely:

1. Enter the server address.
2. Enable or use server reflection.
3. Browse the discovered services and methods.
4. Send requests directly.

3. Work with JSON request bodies

Like BloomRPC, Apidog renders protobuf request messages as editable JSON.

For example, a protobuf message such as:

message GetUserRequest {
  string user_id = 1;
}

can be sent as:

{
  "userId": "user_123"
}

For details about this mapping, see protobuf to JSON.

4. Configure TLS, metadata, and authentication

For each request, configure the endpoint scheme:

• grpc:// for plaintext connections
• grpcs:// for TLS-enabled connections

Then add metadata as needed:

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

For token handling and mTLS patterns, refer to this gRPC authentication guide.

5. Save and share working requests

Instead of re-importing protos and retyping metadata on every machine, save the request configuration with the project:

• Server URL
• Request body
• Metadata
• Authentication configuration
• TLS settings

This makes a debugged gRPC call reusable by the rest of the team.

How the workflow changes

Making unary calls

The basic workflow remains familiar:

1. Import your proto definitions.
2. Select a service and method.
3. Set the target server address.
4. Edit the generated JSON request.
5. Add metadata or authentication.
6. Send the request.
7. Inspect the response and gRPC status.

Keep a gRPC status code reference nearby during migration, since gRPC statuses differ from HTTP status codes.

Testing streaming calls

Streaming is the most significant upgrade from BloomRPC.

For a client-streaming or bidirectional-streaming RPC:

1. Open the method.
2. Connect to the server.
3. Enter a JSON message.
4. Send the message.
5. Continue sending messages as needed.
6. Inspect the message timeline for incoming and outgoing traffic.
7. End the stream when the test is complete.

For a deeper explanation of the RPC patterns, see gRPC streaming explained.

Using server reflection

Server reflection is useful when you need to inspect a running environment but do not have the matching proto revision locally.

Use it for scenarios such as:

• Investigating a staging service owned by another team
• Checking available RPC methods quickly
• Verifying a deployed API before updating local proto files

Connect to a reflection-enabled server, browse the exposed services, select a method, and send a request without manually locating proto files.

Keeping gRPC work with other API work

BloomRPC was a standalone gRPC window. Apidog keeps gRPC requests in the same project as REST, WebSocket, SSE, and GraphQL endpoints.

That matters when a backend exposes multiple protocols. You can keep:

• gRPC debugging requests
• REST endpoint collections
• WebSocket tests
• API documentation
• Test scenarios
• HTTP mocks

in one workspace.

For testing workflows, see testing gRPC APIs. For protocol-selection context, compare REST vs GraphQL vs gRPC and gRPC vs REST.

BloomRPC vs Apidog

Feature	BloomRPC	Apidog
Status	Archived in January 2023; usage not recommended	Actively developed
Unary calls	Yes	Yes
Server, client, and bidirectional streaming	Partial, with known issues	All supported with a session-style timeline
Proto import	Local .proto files	Local file, URL, or server reflection
TLS	Basic	grpc:// / grpcs:// selection per request
Metadata and auth	Metadata editing	Metadata plus authentication configuration
Team sharing	None; local only	Saved calls in a team workspace
Other protocols	gRPC only	REST, WebSocket, SSE, GraphQL, and gRPC
Docs, tests, mocks	None	Available in the same project
Price	Free, but abandoned	Free plan for up to 4 users

Migrate from BloomRPC in five steps

BloomRPC does not provide meaningful portable state, so there is no complex export process. Your .proto files are the migration artifact.

1. Gather your proto files

Find the proto files in your repository:

proto/
  user/
    user_service.proto
  common/
    types.proto

Also identify any imported dependency directories.

2. Import the protos into Apidog

Create or open a project, then import the root .proto file.

If imports fail, add the dependency directory. For example:

import "common/types.proto";

If common is under proto/, add proto/ as an import dependency directory.

Alternatively, connect through server reflection if the target server supports it.

3. Configure the target server and TLS

Set the server address, for example:

grpc://localhost:50051

or:

grpcs://api.example.com:443

Use the correct scheme for the service environment.

4. Recreate metadata and authentication

Copy over the headers or tokens you previously pasted into BloomRPC:

authorization: Bearer <your-token>
x-tenant-id: tenant_01

Save these settings with the request so teammates do not need to recreate them.

5. Save and share the request

Save working requests as shared debugging setups. This gives the team a reusable source of truth for:

• RPC method selection
• Request payload examples
• Environment URLs
• Authentication metadata
• TLS configuration

For an existing BloomRPC user, the basic migration should take about ten minutes because the core flow—import protos, choose a method, configure a server, send a request—remains the same.

Other BloomRPC alternatives

Apidog is useful when gRPC is part of a broader API workflow. For narrower requirements, these tools are worth knowing.

• grpcurl: A curl-like CLI for gRPC. Use it for shell scripts, CI checks, and quick calls against reflection-enabled servers. See the best grpcurl alternative for a detailed comparison.
• grpcui: A grpcurl companion that serves a temporary web UI for a single server. Useful for quick inspection, with no persistent project state.
• Kreya: A desktop client for gRPC and REST with a polished proto workflow and a free tier. It is the closest standalone-client option. See what is Kreya and the best Kreya alternative.
• Postman: Added gRPC support in 2022. It can be a practical option for teams already using it, though its pricing and workspace tradeoffs still apply. See the best Postman alternative.
• evans: An interactive terminal REPL for gRPC. It is effective for developers who work primarily in a terminal, but it does not replace a GUI workflow.

The general pattern is simple:

• Use CLIs for automation and CI.
• Use standalone GUIs for isolated gRPC work.
• Use Apidog when gRPC is one of several API protocols your team owns.

Frequently asked questions

Is BloomRPC still maintained?

No. The repository was archived on January 4, 2023, and its README says usage is no longer recommended. There are no planned updates, security fixes, or releases. New setups should use a maintained gRPC client.

Can I import my BloomRPC setup into Apidog?

BloomRPC does not provide a portable setup export. Re-import your .proto files—or use server reflection—then configure the server address, TLS scheme, metadata, and authentication. Save the result in the project for reuse.

Does Apidog support gRPC streaming?

Yes. It supports unary, server-streaming, client-streaming, and bidirectional-streaming calls. Streaming requests run as live sessions where you can send messages and inspect traffic in a timeline. See gRPC streaming for a mode-by-mode overview.

What if I only need command-line gRPC calls?

Use grpcurl. It is effective for scripted and ad-hoc calls, especially when server reflection is enabled. It also fits naturally into CI workflows. The grpcurl alternative guide explains where a CLI stops being sufficient.

Can I test gRPC and REST APIs in the same tool?

Yes. In Apidog, gRPC, REST, WebSocket, SSE, and GraphQL APIs can live in one project. This is useful for services that expose both gRPC and REST interfaces. See testing gRPC APIs for an end-to-end workflow.

Retire the archived client

BloomRPC’s maintainers recommend moving on. Start by importing your .proto files or connecting to a reflection-enabled server, then recreate and save your key unary and streaming requests.

Download Apidog to begin with a free plan for up to four users. Your proto files are the only migration files you need.