preface

Usually we write gRPC interface is how to test? There are usually the following methods:

  1. Write single-test code and simulate client tests yourself.

  1. You can build onegRPC-GatewayService, so that you canpostmanIn the simulation.

But neither approach is particularly elegant; The first approach is less straightforward to maintain in code when the nesting of request structures is particularly complex. And the code will be extremely long.

The second approach in Postman, like the request HTTP interface, seems straightforward; However, the need to maintain a GRPC-gateway service and republish when the interface definition changes is a little more complicated to use.

So I did some searching and found two tools that looked good:

  • BloomRPC
  • Github.com/fullstoryde…

First of all, the page of BloomRPC is beautiful and its function is perfect. Int64 data request is not supported, and there will be accuracy issues.

Here I write a simple interface to return the requested INT64 directly.

func (o *Order) Create(ctx context.Context, in *v1.OrderApiCreate) (*v1.Order, error) {
	fmt.Println(in.OrderId)
	return &v1.Order{
		OrderId: in.OrderId,
		Reason:  nil,},nil
}
Copy the code

The precision of the data received by the server has been lost.

This was very uncomfortable in our int64 heavy usage business, and most of the interfaces were unusable.

grpcuiI’m the one using itBloomRPCTools discovered after a period of time are more functional;BloomRPCThere is no accuracy problem in.

However, as I was used to debugging interface in BloomRPC before, and my browser almost opened dozens of TAP pages during daily development, it was not so convenient to find GRpCUI.

So I was wondering if there could be a separate APP like BloomRPC that also supports INT64.

To prepare

I looked around. I don’t think I found anything. Just some time ago to write a gRPC pressure tool, in fact, the APP needs the core function is to achieve the generalization call.

Since the core capability is realized by Go, it is better for this APP to be written with Go, which will make it more convenient to reuse the code. I also want to see how it works with Go for GUI applications.

Unfortunately, Go doesn’t have native GUI library support, so I ended up digging around and found one: Fyne

Star is used more, but also supports cross-platform packaging; So we decided to use this library to build the application.

The core function

I referred to BloomRPC for the interaction process of the whole App, but as a back-end developer who does not understand aesthetics and design, the most difficult thing in the whole process is the layout.

This is the first version of the page that I spent several nights debugging, and while it works, viewing the request and response data is very inconvenient.

So it took another weekend and the final version looks like this (at first glance, it looks the same) :

Although there is a certain gap between the page and BloomRPC, it does not affect the usage. The key is that the int64 issue is fixed; You can have fun jerking off again.

The installation

Have similar needs also want to experience friends can be downloaded here: github.com/crossoverJi…

Because I have no Windows computer, so there is no package EXE program; Friends who have relevant needs can download the source code by themselves:

git clone [email protected]:crossoverJie/ptg.git
cd ptg
make pkg-win
Copy the code

The follow-up plan

The functionality of the current version is rudimentary, supporting only common unary calls; Stream, metadata, workspace storage and restore support will also be added in the future.

Suggestions on pages and interactions are also welcome.

Originally I was going to upload it to BREW for easy installation, but it was rejected all night because of insufficient data, so please pay attention to it if you are helpful or interested (🐶).

Source code address: github.com/crossoverJi…