gRPC Client - A Vibe-coded Client for Testing REST/gRPC Endpoints

My current craving of vibe-coding various tools I need to do my job continues, with an attempt to build a REST/gRPC test client.

This is motivated by my distaste with all the other clients I've tried. There've been a few, and I've been unhappy with each one. For one thing, they seem more heavyweight than my needs. I don't know if this is just how they're implemented, or it's because the realm of HTTP request testing is complicated (It's probably a bit of both).

Another thing is that they're tend to add features targeting testing teams that manage a central repository of test cases. I get the feeling that's how most of them try to make money: offer the tool for free to get the foot in the door, then upsell them with a hosted test repository. This leaves half the interface either useless, or just bait for throwing up requests to setup a service account and pay them money.

Finally, some are just awkward to use. The UI is inconsistent and buggy, and just gets in the way. I did wonder if the typical UI for these REST clients is partly to blame for this, but as you will see, it's not like this project deviates from the mainstream, so I think it's just comes down to implementation.

Anyway, these frustrations, along with wanting to see what these coding agents are capable of, motivated me to requested Claude Code to make me one. And it did a pretty decent job.

It's called gRPC Client — stellar naming, I know — and it's pretty typical of most other REST/gRPC test clients out there. Request details on the left, the latest response on the right. A list of saved requests, along with a history, in the sidebar, that can be recalled and resent. There's a reflection browser for gRPC endpoints, and a command for producing an example request for service methods, a feature of Insomnia that I really like.

The right sidebar has three parts, of which the first is the ability to define environment values, which can be included in the request properties via Go templates (this is a Wails app with a Go backend and HTML+JS frontend).

One feature of this client is the ability to override HTTP headers at the global level, the second thing in the right sidebar. When testing APIs, I usually have a collection of pre-made requests for endpoints I'm familiar with. Yet I'm always editing the headers when the user or auth token changes. The motivation with this feature was to make the change once, so that I don't need to do so when I switch saved requests. I originally requested a way to do this for the hostname and port too, but I found this wasn't as useful for me.

In practice, I ended up simply using environment values and request scripts, so-called "Hooks", which is the third thing in the right sidebar. This is some JavaScript that executes before each requests, allowing the user to modify the headers and body using the values from the environment. What I would do is set the username as an environment value, and a hook would set the HTTP header, and generate the payload for a JWT token, saving me from getting this from the browser (the endpoints I need to test just need the payload, not the signature, so this simply involvers marshalling a JSON object to Base64).

These are all features of most REST clients out there, but they're always hidden away and difficult to modify, which means I'm never using them. Placing them in the main client area makes them front and centre, so to speak, and so much easier to change.

One other thing I requested was the use of HuJSON for the request body. It's a little crazy to think that all these REST/gRPC clients, designed for use by humans, require their users to write perfect JSON for the body, especially when I'm left wanting to comment out parts of the body as I test something. This gets translated to JSON when the request is being sent.

So all in all, it's a pretty decent client, and despite it being like many other clients out there, it's pleasant to use. And I can't really put my finger on why. Might be that it's just simpler than all the other ones out there. It doesn't have tabs, for example, which does making testing multiple endpoints a little annoying, and I'm wondering if it's worth asking Claude to add them. Yet at the same time, the frustration I had with other clients came about with their implementation of tabs. Likewise for saved requests. This just has a single list of saved requests that are either REST or gRPC requests. No need to worry about folders, or request types I don't use, like GraphQL.

I guess if you're vibe coding something for your own use, less is indeed more.