5 ms·
Show HN: Ezy – open-source gRPC client, alternative to Postman and Insomnia
In this release I have concentrated on user experience:
- Full support of shortcuts
- Reworked collections management
- Notifications
- Improved UX
gRPC clients I’ve worked with had drawbacks and didn’t fit my use-case in a way I was expecting, since I’ve started working with gRPC 3+ years ago.
Since then, I wanted a tool that fits any need in gRPC world. This is why I created ezy.
Compared to Insomnia and Postman, ezy offers better streams support, allows you to use Server-Side and Mutual TLS with custom TLS certificates, works with gRPC-Web and has a more slick UI/UX.
If you are looking for a gRPC/gRPC-Web client which fits your needs, give ezy a chance!
I’d love to hear your feedback and answer any questions regarding ezy.
- deleted 4y ago[deleted]
- codetrotter 4y agoGlad to see that this supports mTLS. Will have a look at this tool. 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? Is it able to import proto files to define endpoints automatically, and to fill in generated data for the types?
- notmedia 4y agoHi! Great, feel free to return back with any feedback! > 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!
- ushakov 4y agoWhen we were working on adding gRPC support to Step CI, I needed a client that I could use to test my mock APIs manually BloomRPC looked ugly and outdated, Kreya would crash on my M1 mac and Insomnia didn’t have all the features I needed. Ezy was a new discovery and offered both great UX and features that were missing from other clients When I’m working with gRPC APIs, Ezy is the client I reach out to!
- notmedia 4y agoHi! Thank you, I'm happy to hear that you found ezy helpful for your needs!
- hankchinaski 4y agoAnyone knows of web based HTTP client? Compatible with Postman Insomnia?
- mxuribe 4y agoI've not used it, but have heard of Prestige (https://github.com/sharat87/prestige https://github.com/sharat87/prestige). It bills itself as "A text-based HTTP client in the browser. An interface-less Postman." I hope that helps!
- notmedia 4y agoHey! Buy the way I have plans to support different protocols later such as HTTP, GraphQL, etc. :)
- bob2047 4y agoYou may try https://hoppscotch.io/ https://hoppscotch.io/
- kermire 4y agoYou can try https://github.com/flawiddsouza/Restfox https://github.com/flawiddsouza/Restfox. It's a web based HTTP client based on Postman and Insomnia. Disclaimer: I'm the maintainer for it.
- notmedia 4y agoWow! You have an interesting project! I will try it!
- atombender 4y agoLooks promising. I have to say this is still really rough, though. Some feedback after 5 minutes of testing: * 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". * If you create a collection and click "Create", and it errors saying an imported proto resource wasn't found, the entire collection disappears. * 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. * Similarly, response is shown in JSON, rather than Proto data. So I can't see what the returned types actually are. * 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? * Clicking on an endpoint adds another tab. Click around and you end up with dozens of tabs. Seems a bit pointless. * No support for setting HTTP headers or seeing the returned headers.
- notmedia 4y agoHi! Thank you for testing! > 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 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.
- wdb 4y agoPretty happy with Paw (https://paw.cloud https://paw.cloud, macOs) also supports gRPC
- HatchedLake721 4y agoYou forgot to mention the best part, no Electron! Native macOS app
- notmedia 4y agoInteresting tool, never seen this before! 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.
- jim180 4y ago1. Streams are coming next year. 2. Could you elaborate more about this? 3. Currently, Paw supports TLS with by entering grpcs://grpcb.in:9001. No custom certificates yet. 4. 5. It should not freeze. I'm gonna check this. Thanks. Our gRPC is not final yet, but improvements are coming!
- notmedia 4y ago> 2. Could you elaborate more about this? 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.
- topicseed 4y agoGood. Postman is an example of very useful and good software turning into inconvenient bloatware.
- notmedia 4y agoThank you! If you have any feedback feel free to share!
- inshadows 4y ago
- arein3 4y agoBest grpc client is to not use grpc. Better use json over http2 (and enable compression if needed).
- notmedia 4y agoHey! I think it's really depends on your needs and expectations from protocol you choose. 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.
- arein3 4y agogRPC has been a pain (customization of the generated clients, automation testing, even usual testing). I haven't heard of Ezy (used BloomRPC, insomnia, and another client, all of them were an incomplete solution). I will be sure to check Ezy next time I have to use gRPC. Some of the features I couldnt find on the gRPC apps I tried were: 1) the ability to have complete information about the request and the response, and also I couldn't add headers to the grpc request. 2) the ability to automate (run the requests without a GUI), the way newman works for postman. I just wish gRPC would not be used on any new projects and people would use more sensible solutions.
- ushakov 4y agoFor automating gRPC tests you can use Step CI Disclosure: I'm the author https://docs.stepci.com/guides/testing-grpc.html https://docs.stepci.com/guides/testing-grpc.html
- notmedia 4y ago> the ability to have complete information about the request and the response 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