A gRPC client that works in the browser

Service definitions from .proto files or reflection

There are several ways to tell the client what a service looks like:

• Server reflection: if your server exposes the reflection service, the client lists services and methods directly (reflection v1, falling back to v1alpha).
• Upload .proto files: add single files, or a whole folder with its relative paths kept, so import statements resolve. Extra import paths are searched in order, like protoc -I.
• A .proto URL: load a definition from a public URL.

Files are compiled in memory on the server; nothing needs protoc on your side. For each method the client builds an example request message from the schema, so you start from valid JSON instead of an empty editor.

Unary and streaming calls

Unary, server streaming, client streaming and bidirectional streaming methods are all supported. For client and bidirectional streams you send messages one at a time and end the stream when you are done; responses appear in a timestamped message log. When the call finishes you get the gRPC status code and name, the status message, response headers and trailers, the number of messages and timings.

Metadata, deadlines and TLS

Add request metadata as key/value pairs (with {{variables}}), set a deadline in milliseconds, and choose whether to use TLS. For private PKI you can supply a CA certificate, a client certificate and key for mutual TLS, and a server name override. The Settings tab also covers keepalive pings, maximum send and receive message sizes, and whether fields with default values are included in the JSON response.

authorization: Bearer {{accessToken}}
x-request-id: {{$guid}}
x-tenant: acme

grpcurl in and out

Paste a grpcurl command into the address field to fill in the target, method, metadata and message, or copy any request as a grpcurl command to share it with someone working in a terminal.

Scripts and tests for gRPC

gRPC requests have three script hooks: before invoke (change metadata or the message), on message (runs for each received message, with swc.message) and after response (runs once the call completes). Assertions read like their HTTP equivalents:

swc.test("call succeeded", () => {
  swc.response.to.have.statusCode(0);      // gRPC OK
  swc.response.to.have.metadata("content-type");
});
swc.test("returned the user", () => {
  swc.expect(swc.response.messages.count()).to.equal(1);
  swc.response.messages.to.have.property("user.id");
  swc.environment.set("userName", swc.response.messages.idx(0).data.user.name);
});

Saved gRPC requests run in the collection runner and on monitors too, so a gRPC health check can sit next to your REST checks.

How it works

1. Open the app, create a request and change its type to gRPC.
2. Enter the server address (for example grpc.example.com:443), turn TLS on if needed, and load the service via reflection or .proto files.
3. Choose a method, edit the message and invoke.

Calls need a free account. The web app relays gRPC through the Swastik Codes server, which only connects to public hosts and refuses private and loopback addresses, so localhost:50051 will not work from the browser. The desktop app for Windows and Linux calls local services directly. A single message can be up to 16 MiB.

Frequently asked questions

Do I need server reflection?

No. Reflection is convenient, but uploading the .proto files (or a folder of them) works for any server.

Does it support gRPC-Web?

The client speaks native gRPC over HTTP/2 from the server side, so your service does not need a gRPC-Web proxy.

Can I use mutual TLS?

Yes. Provide a client certificate and key (PEM), plus a CA certificate if your server uses a private CA.

Can I run gRPC checks on a schedule?

Yes. Save the gRPC request in a collection and attach a monitor; test results are recorded per run.