Show HN: Fully-featured desktop gRPC/gRPC-Web client | Hacker News Reader

Show HN: Fully-featured desktop gRPC/gRPC-Web client

github.com

33 pointsnotmedia8 comments

I decided to give it a try. It wants you to select your "proto path" as a first step. Mine is a directory; we have something like src/ and then subsystems' proto files live in src/subsystem/subsystem.proto and import each other with 'import subsystem/subsystem.proto'. It didn't let me pick a directory with the file checker, nor did it let me just type a directory name, so that's annoying.

I picked one of the subsystems at random and it fails to import gogo's proto files. Yeah, that's always an annoyance, I guess you have to "go mod download" and add the correct path under ~/go/pkg/mod/... to locate that for it.

I couldn't figure out how to let it connect to my server and just autodiscover the protos like grpcurl does. At this point I gave up. I usually just make a main.go somewhere that does cc := grpc.Dial(...); res, err := whatever.FooClient(cc).Method(&whatever.Request{...}); fmt.Println(res, err) when I want to test something, so I doubt I'd integrate this with my workflow anyway.

No support for server reflection?

Hey! Server reflection is in project backlog :) I'm working on it - https://github.com/getezy/ezy/issues/16

You made a great point! I will think about implementing ezy flow)

But right now I will try to explain and help:

Let's say you have src of protos with subfolders which you call subsystem If I understand correctly, subsystem - isolated system (like a service) with own API. If so, then in ezy you should create collection for every subsystem module where you may have root proto file. The second step is include directories - this directories are paths to your directories where gogos's proto files lives.

I hope this helps! If you have any troubles and instered in setup you can open an issue in project repository.

I love critic because without talks we can't understand what the community wants. Thank you for this it really helps!

This page has a lot of information, and still doesn't define "gRPC" for people who aren't keeping up with all of the latest acronyms.

Thank you for your feedback! I added some links to project readme that can explain what gRPC is.

Why is this better than Insomnia?

Hi! There are tools which already supports gRPC or they are specific-gRPC tools. I'm working with gRPC every day for 3+ years and unfortunately each of them are not suitable for most of cases. Some of them are unsupported at this moment (I mean the standard of gRPC tooling - BloomRPC), some of them have a lot of bugs or have problems with specific cases, or they have really bad UI.

If we talk about Insomnia:

  1. You can’t open the stream and wait for client or server interaction. For example you can’t in bidirectional streaming send three messages from client, then wait for server response and send next one message.

  2. You can’t stop streams, only cancel or wait when they will be ended by the server. When you cancel your stream - it's means error from client-side.

  3. You can’t setup custom TLS certificates

  4. You can’t work with Server-Side and Mutual TLS

  5. You can't override SSL target name which sometimes helps to test requests

  6. You can’t work with gRPC-Web

  7. From my vision Insomnia doesn't have good UI/UX (only my vision, I'm not pretending to the truth)

By the way, gRPC is only starting point for ezy. Ofcourse firstly I will implement all features in this area, then I will bring in ezy my vision on how to work in product teams in next-gen way.

Reply on news.ycombinator.com