The Best BloomRPC Alternative

BloomRPC was the answer to a question every gRPC developer eventually asks: “where’s my Postman for gRPC?” Load a .proto file, get an editable JSON request body, hit send. It was simple, it was free, and it earned around 9,000 GitHub stars doing one thing well. Then, on January 4, 2023, the repository was archived. The README doesn’t mince words: the project stalled, issues piled up, and the maintainers now state plainly that “its usage is no longer recommended.” They point you at the awesome-grpc list and wish you luck.

Here’s the direct answer: Apidog is the best BloomRPC alternative for most teams, because it doesn’t just replace the .proto-loading window. It supports all four gRPC call types (unary, server streaming, client streaming, and bidirectional streaming), imports .proto files from a local path, a URL, or server reflection, and puts your gRPC work in the same project as your REST, WebSocket, and GraphQL endpoints, with docs, collaboration, and saved debugging setups included. If you only need a throwaway call from a terminal, lighter tools exist, and we’ll cover those honestly too. This article explains what died with BloomRPC, what to replace it with, and exactly how to migrate.

What BloomRPC was, and why it’s gone

BloomRPC shipped in 2018 as an Electron desktop app with one job: make gRPC calls without writing a client. You imported your .proto files, it listed the services and methods, generated a JSON skeleton for each request message, and let you edit metadata and send. For unary calls and basic streaming it was fine, and “fine and free” made it the default gRPC GUI for years.

The archive notice ends that era cleanly. An archived repository means no bug fixes, no dependency updates, and no releases. For an Electron app, that’s not a neutral state: the bundled Chromium and Node versions age out of security support, newer proto syntax and gRPC features go unhandled, and known bugs (BloomRPC had long-standing ones around proto imports and certain streaming flows) stay exactly where they are. The maintainers were honest about it, which is more than many dead projects manage. The message is: stop installing this.

People still search for BloomRPC because the shape of the tool was right. The question is whether you replace the shape (another standalone gRPC window) or fix the underlying fragmentation: most teams that run gRPC also run REST, and testing them in two disconnected tools was always the tax BloomRPC quietly charged. We’ve written before about what makes a good gRPC client; the short version is that “loads protos, sends calls” is now table stakes, and the differentiators live above that.

The answer: Apidog

Apidog is an API development platform used by over 500,000 developers, covering design, debugging, testing, mocking, and documentation. Its gRPC support, per the official docs, covers what BloomRPC did and the parts BloomRPC never finished:

1. All four call types. Unary, server streaming, client streaming, and bidirectional streaming are all supported. Streaming calls work like a WebSocket session: open the call, then write and send messages from a Message tab while a timeline view shows sent and received messages in order. BloomRPC’s streaming support was partial and buggy at the end; here it’s a documented feature.
2. Three ways to import your API definition. Load a local .proto file, import from a URL, or use server reflection to pull services straight from a running gRPC server with no proto files at hand. If your protos depend on other protos, you add the dependency directory once.
3. JSON in, JSON out. Like BloomRPC, Apidog renders protobuf messages as editable JSON, so you’re not hand-encoding binary payloads. If you need to reason about that mapping, see protobuf to JSON.
4. TLS, metadata, and auth. Toggle grpc:// or grpcs:// per request, and attach metadata and auth configuration for the setups real services actually have. For token and mTLS patterns, our gRPC authentication guide pairs well with this.
5. It’s not a dead end. Saved gRPC calls (server URL, messages, metadata) are shareable with teammates, and they live in the same workspace as your REST endpoints, test scenarios, and published docs. That’s the part no standalone gRPC window ever offered.

What the switch looks like feature by feature

Making calls

Day-to-day usage will feel familiar. Import protos, pick a service and method, edit the generated JSON body, set the server address, send. Unary calls return a response pane; streaming calls open a session where you push messages and watch the timeline. Status codes come back as gRPC status codes, which read differently from HTTP; keep the gRPC status code reference handy the first week.

Streaming, specifically

This is the sharpest upgrade. BloomRPC’s client-side and bidirectional streaming were common sources of its open issues. Apidog documents all four modes and treats a streaming call as a live session rather than a one-shot request. If your services lean on streams, that difference is the whole decision; for background on the modes themselves, see gRPC streaming explained.

Server reflection

BloomRPC required proto files. Apidog also supports server reflection, so you can point it at a reflection-enabled server and browse its services without hunting down the right proto revision. For quickly poking at a staging server someone else owns, this removes the most annoying step.

Beyond the client

Here’s the category jump. In BloomRPC, a debugged call evaporated when you closed the window. In Apidog, gRPC services sit inside a project: teammates reuse your saved debugging setup instead of re-importing protos and re-typing metadata, and the same workspace holds your REST and WebSocket work, automated gRPC API tests, mocks for your HTTP endpoints, and publishable docs. Most gRPC backends serve REST or GraphQL somewhere too; if you’re weighing those protocol boundaries, we’ve compared them in REST vs GraphQL vs gRPC and dug into the tradeoffs in gRPC vs REST.

BloomRPC vs Apidog at a glance

Migrating from BloomRPC

The honest migration note: there’s nothing to export. BloomRPC kept no meaningful portable state, which makes leaving it trivial:

1. Gather your .proto files. They live in your repo, not in BloomRPC. That’s the whole “export.”
2. Import into Apidog. Create a project, add the protos (or their URL), and add dependency directories if your protos import others. Services and rpc methods appear as services and methods. Or skip the files entirely and use server reflection against a running server.
3. Set the server address and TLS. Enter the target URL and pick grpc:// or grpcs://.
4. Recreate metadata and auth. Re-add the headers and tokens you had pasted into BloomRPC, this time saved with the request so you type them once.
5. Save and share. Saved calls become the team’s shared debugging setup, which is the first thing you’ll notice you never had.

A working BloomRPC user should be sending calls in Apidog inside ten minutes, because steps 1 through 3 are the same ritual you already know.

Other BloomRPC alternatives worth knowing

Apidog is the answer if you want gRPC inside a full API platform. If your need is narrower, be fair to the narrow tools:

• grpcurl: curl for gRPC. The right tool for shell scripts, CI checks, and one-liners against reflection-enabled servers; not a GUI and doesn’t pretend to be. We compared it in depth in the best grpcurl alternative.
• grpcui: grpcurl’s sibling that serves a temporary web UI for one server. Good for a five-minute poke, with no saved state by design.
• Kreya: a dedicated desktop client for gRPC and REST with a polished proto workflow and a free tier; the closest thing to a direct BloomRPC successor if you specifically want a standalone client. See what is Kreya and the best Kreya alternative for where its limits sit.
• Postman: added gRPC support in 2022, so if your team already pays for it, it works; the usual Postman pricing and workspace tradeoffs apply, covered in the best Postman alternative.
• evans: a terminal REPL for gRPC with an interactive mode. Loved by people who live in tmux; a non-starter for anyone who wanted BloomRPC’s GUI.

The pattern: CLIs for automation, single-purpose GUIs for isolated gRPC work, Apidog when gRPC is one protocol among several and you want the calls, tests, and docs in one place.

Frequently asked questions

Is BloomRPC still maintained?

No. The repository was archived on January 4, 2023, and its README states that usage is no longer recommended. There are no updates, security fixes, or releases coming. Any current gRPC client comparison should exclude it as an option for new setups.

Can I import my BloomRPC setup into Apidog?

There’s no import file because BloomRPC stored nothing portable. Migration means re-importing the .proto files from your repo (or using server reflection), then setting the server address, TLS scheme, and metadata. It’s a ten-minute job, and afterward the configuration is saved and shareable instead of trapped on one machine.

Does Apidog support gRPC streaming?

Yes, all four call types: unary, server streaming, client streaming, and bidirectional streaming. Streaming calls run as live sessions where you send messages and watch a timeline of traffic. For a refresher on when each mode fits, see gRPC streaming.

What if I just need quick command-line gRPC calls?

Use grpcurl. It handles scripted and ad-hoc calls well, especially against reflection-enabled servers, and belongs in CI regardless of which GUI you pick. Our grpcurl alternative guide covers where it stops being enough.

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

In Apidog, yes: gRPC, REST, WebSocket, SSE, and GraphQL live in one project, so a service that exposes both gRPC and REST surfaces gets one home. Our guide to testing gRPC APIs shows the workflow end to end.

Retire the archived client

BloomRPC told you to leave; the only question is where to. Point Apidog at your .proto files or a reflection-enabled server, make your first unary and streaming calls, and keep them saved next to the rest of your API work. Download Apidog free; a team of 4 pays nothing, and your protos are the only migration file you need.