Test gRPC APIs Interactively with BloomRPC (2026)

BloomRPC lets you interactively test gRPC APIs without writing a single line of client code.

Let’s say you have a simple gRPC service defined in a .proto file. Here’s a greeter.proto:

syntax = "proto3";

package greet;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

And you have a server running that implements this service. Normally, to test SayHello, you’d spin up a client application, connect to the server, serialize a HelloRequest, send it, deserialize the HelloReply, and print the message. With BloomRPC, you skip all that.

Here’s how it looks in BloomRPC:

1. Load your .proto files: In BloomRPC, you’ll see a "Proto Path" setting. You point this to the directory containing your greeter.proto file. BloomRPC will parse it and discover your Greeter service and its methods.

2. Connect to your server: You’ll enter the server’s address, for example, localhost:50051. BloomRPC establishes a connection.

3. Select a method: The left-hand pane will list your services and methods. You click on SayHello.

4. Construct the request: The main pane will show a JSON-like editor pre-populated with the structure of HelloRequest. You can directly type in the values. For name, you might enter "World".

5. Send the request: Click the "Send" button.

6. View the response: The response pane will display the HelloReply received from the server, showing the message field.

You can see this in action. Imagine your server is running on localhost:50051.

BloomRPC UI Screenshot (Conceptual):

+-------------------------------------------------+
| Proto Path: /path/to/your/protos                |
| Server Address: localhost:50051                 |
|                                                 |
| [Services]                                      |
|  greet.Greeter                                  |
|   > SayHello                                    |
|                                                 |
+-------------------------------------------------+
| Method: greet.Greeter.SayHello                  |
|                                                 |
| Request:                                        |
| {                                               |
|   "name": "BloomRPC User"                      |
| }                                               |
|                                                 |
| [ Send ]                                        |
|                                                 |
| Response:                                       |
| {                                               |
|   "message": "Hello, BloomRPC User"             |
| }                                               |
+-------------------------------------------------+

The core problem BloomRPC solves is the friction in testing gRPC services. Without it, you’re constantly writing and tearing down boilerplate client code for even the simplest request/response cycles. It democratizes gRPC testing, making it accessible to developers, QAs, and even operations folks who just need to verify service behavior.

Internally, BloomRPC uses the gRPC reflection protocol if your server supports it. If not, it loads the .proto files you provide to understand the service definition and message structures. It then dynamically generates the client-side logic to serialize your input, send it over the wire, and deserialize the response. You control the request payload and the server endpoint.

The surprising thing about BloomRPC is how seamlessly it handles complex message structures, including nested messages, oneofs, and repeated fields, directly within its intuitive JSON editor. You don’t need to manually construct serialized bytes or worry about Protobuf encoding rules; it abstracts all of that away. For instance, if your HelloRequest had a repeated field of string called tags, BloomRPC would render it as an array in the JSON editor:

{
  "name": "BloomRPC User",
  "tags": ["testing", "grpc", "interactive"]
}

And if you had a nested message Address within HelloRequest:

message HelloRequest {
  string name = 1;
  Address address = 2; // Assuming Address is another message type
}

message Address {
  string street = 1;
  string city = 2;
}

BloomRPC would render it as a nested JSON object:

{
  "name": "BloomRPC User",
  "address": {
    "street": "123 Main St",
    "city": "Anytown"
  }
}

This dynamic, schema-driven UI generation is what makes it so powerful for interactive exploration.

Beyond basic unary RPCs, BloomRPC also supports testing server streaming, client streaming, and bidirectional streaming RPCs. For streaming methods, it provides a live view of incoming messages and allows you to send messages incrementally.

The next step after mastering interactive testing is to integrate these checks into your CI/CD pipeline using BloomRPC’s command-line interface or by generating client code from your .proto files for automated test suites.