I created the poll - https://github.com/getezy/ezy/discussions/35
112 karma · joined August 16, 2022
Can you describe what information you want to see?
> the ability to automate (run the requests without a GUI)
Yeah, this is my goal - I want to add tests support to ezy with ability to run them on CI/CD
gRPC is not a silver bullet, but it offers you structure via protobuf messages and automatically generated clients for most used languages. Not in all places in your architecture you need to use high-performance protocols. It's a trade-off and only you decide whats better in concrete section.
The problem which ezy solves - gRPC is popular, and yes, maybe we have faster protocols, but a lot of developers using it and this tool just help them to work with it.
Include directories is an option which defines paths for your imports in protobuf files. In large projects it's commonly use case when you have directory of protobuf types that used in another files with service definitions for example.
> Our gRPC is not final yet, but improvements are coming!
You do the great project, I tested HTTP features and they looks good! I'm sure that you will improve gRPC experience soon. Thank you for your comment, I will subscribe for your updates!
I like that a lot of projects enters gRPC world - this promotes gRPC and making it easy to use.
Tested it with common gRPC cases. Just some things why it's not good for gRPC:
1. It doesn't support streams.
2. It doesn't support "include directories" option.
3. It doesn't support Server-Side/Mutual TLS with custom
certificates.
4. When I entered URL like 0.0.0.0:4000 app freezes and won't work, so I can't send any request.
5. I think it support only gRPC-Web, because my URL 0.0.0.0:4000 converts to http://0.0.0.0:4000. If yes, it only covers gRPC-Web that is not fit all user needs.Ah, this make sense. I agree that this could be a common issue while importing a protobuf. I will fix this in next release :)
> Something like Grip, maybe: https://gripgrpc.dev/. Got it, we have a related discussion here -https://github.com/getezy/ezy/discussions/29 I will think how to show it, thank you!
> Appears to be related to the number of tabs. If I have only one tab open, it's not particularly laggy.
The main problem here is persistance (saving all data on the disk), and this make performance problems. I have plans to rewrite this section to improve it.
> Click on an endpoint. It always opens a new tab.
I think I need to create a poll :) Some users saying that they want to open new tab by one click, others wants double click.
And here I really don't know whats the better way of UX should be.
> It doesn't remember your "environment". So if I call endpoint A and then click on endpoint B to try that, it forgets which environment is being targeted. Similarly, metadata is also specific to the request. If you use metadata for providing authorization headers, that means you have to enter the metadata separately every time you make a different request; there's no way to share metadata as an "environment".
Yeah, I have this in plans for taking environment and Metadata from previous tab - https://github.com/getezy/ezy/issues/30
> If you create a collection and click "Create", and it errors saying an imported proto resource wasn't found, the entire collection disappears.
Ha, interesting case, you selected the file and then just delete it before clicking create :) I will think how to handle this.
> The app uses the proto schema to show a list of endpoints, but it doesn't know anything about the message and response schemas, and you can't browse the types? It seems tedious to have to manually enter the request as a JSON payload.
This is the great point, was already mentioned earlier, I have plans to add auto-mocking feature for request payloads and autocompletion in code editor this will fix this issue. Also I will think for option to show raw Protobuf definitions
> Similarly, response is shown in JSON, rather than Proto data. So I can't see what the returned types actually are.
Maybe you have an idea on how we can represent decoded message (which an object) and map it to Protobuf Message definition?
> The "Request" and "Metadata" editors are super laggy to the point of being unusable. It takes several seconds for what I type to appear in the editor, and my computer's CPU usage goes to 150% while it's sitting there doing nothing. Is there some kind of autocompletion that's supposed to kick in that's going into overdrive?
Interesting, this is the first feedback about app performance. Can you open an issue and put more details there? I need to know app version, your OS, how much tabs opened and how much are you typing. Will be helpfull, but I try to reproduce it anyway.
> Clicking on an endpoint adds another tab. Click around and you end up with dozens of tabs. Seems a bit pointless.
Sorry, I can't reproduce this bug. You said clicking around, where exactly I need to click?
> No support for setting HTTP headers or seeing the returned headers.
You can set it in your Metadata and this should work as expected.
> Does the TLS/mTLS settings allow you to override the host name of the server, so that I can connect to localhost even though the cert CN is example.com?
Yes, in TLS settings you can override SSL target name for this cases.
> Is it able to import protobuf files to define endpoints automatically, and to fill in generated data for the types?
When you importing the protobuf files ezy parse them and generate to you collection of all existing services and methods. I have plans to add auto-mocking feature, which will generate prefilled values for the request payload, stay tuned!
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)
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!
Why another one? I'm working with gRPC every day and for my opinion all existed GUI clients do not well designed or do not have fully gRPC features support. And some of them like BloomRPC unfortunately are unmaintained.
Features:
Localy persisted collections. Multi-tabs. Environments. Unary calls. Client/Server/Bidirectional streaming. Metadata support. TLS (Server-side/Mutual) support. Good errors output.
Coming soon: grpc-web, server reflection
If you are interested in this project, please share your feedback/ideas here or in GitHub discussions