[HN Gopher] Show HN: Ezy - open-source gRPC client, alternative ...
___________________________________________________________________
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.
Author : notmedia
Score : 146 points
Date : 2022-12-08 10:50 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| atombender wrote:
| Looks 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 wrote:
| Hi! 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
|
| > 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.
| atombender wrote:
| > you selected the file and then just delete it before
| clicking create :)
|
| No, I had a proto file which imported another proto file,
| which could not be found, because I had not added its path to
| the import path list. Seems like it would be a common enough
| issue.
|
| > Maybe you have an idea on how we can represent decoded
| message (which an object) and map it to Protobuf Message
| definition?
|
| Something like Grip, maybe: https://gripgrpc.dev/.
|
| > Interesting, this is the first feedback about app
| performance.
|
| Appears to be related to the number of tabs. If I have only
| one tab open, it's not particularly laggy.
|
| > Sorry, I can't reproduce this bug. You said clicking
| around, where exactly I need to click?
|
| Click on an endpoint. It always opens a new tab.
| notmedia wrote:
| > No, I had a proto file which imported another proto file,
| which could not be found, because I had not added its path
| to the import path list. Seems like it would be a common
| enough issue.
|
| 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.
| [deleted]
| hankchinaski wrote:
| Anyone knows of web based HTTP client? Compatible with Postman
| Insomnia?
| bob2047 wrote:
| You may try https://hoppscotch.io/
| notmedia wrote:
| Hey! Buy the way I have plans to support different protocols
| later such as HTTP, GraphQL, etc. :)
| kermire wrote:
| You can try 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 wrote:
| Wow! You have an interesting project! I will try it!
| mxuribe wrote:
| I've not used it, but have heard of 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!
| [deleted]
| wdb wrote:
| Pretty happy with Paw (https://paw.cloud, macOs) also supports
| gRPC
| HatchedLake721 wrote:
| You forgot to mention the best part, no Electron! Native macOS
| app
| notmedia wrote:
| Interesting 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 wrote:
| 1. Streams are coming next year.
|
| 2. Could you elaborate more about this?
|
| 3. Currently, Paw supports TLS with by entering grpc _s_
| ://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 wrote:
| > 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.
| codetrotter wrote:
| Glad 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 wrote:
| Hi! 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!
| topicseed wrote:
| Good. Postman is an example of very useful and good software
| turning into inconvenient bloatware.
| notmedia wrote:
| Thank you! If you have any feedback feel free to share!
| inshadows wrote:
| ushakov wrote:
| When 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 wrote:
| Hi! Thank you, I'm happy to hear that you found ezy helpful for
| your needs!
| arein3 wrote:
| Best grpc client is to not use grpc. Better use json over http2
| (and enable compression if needed).
| notmedia wrote:
| Hey! 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 wrote:
| gRPC 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.
___________________________________________________________________
(page generated 2022-12-08 23:01 UTC)