Good. Postman is an example of very useful and good software turning into inconvenient bloatware.
Show HN: Ezy – open-source gRPC client, alternative to Postman and Insomnia
21–30 of 32 posts
Re: Show HN: Ezy – open-source gRPC client, alternative to Postman and Insomnia
#22Pretty happy with Paw ( https://paw.cloud , macOs) also supports gRPC
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…
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!
Re: Show HN: Ezy – open-source gRPC client, alternative to Postman and Insomnia
#23Earlier quoted context omitted.
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…
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!
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.
Re: Show HN: Ezy – open-source gRPC client, alternative to Postman and Insomnia
#24Anyone knows of web based HTTP client? Compatible with Postman Insomnia?
Disclaimer: I'm the maintainer for it.
Re: Show HN: Ezy – open-source gRPC client, alternative to Postman and Insomnia
#25Re: Show HN: Ezy – open-source gRPC client, alternative to Postman and Insomnia
#26Best grpc client is to not use grpc. Better use json over http2 (and enable compression if needed).
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.
Re: Show HN: Ezy – open-source gRPC client, alternative to Postman and Insomnia
#27Re: Show HN: Ezy – open-source gRPC client, alternative to Postman and Insomnia
#28Best grpc client is to not use grpc. Better use json over http2 (and enable compression if needed).
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…
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.
Re: Show HN: Ezy – open-source gRPC client, alternative to Postman and Insomnia
#29Earlier quoted context omitted.
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…
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, a…
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
Re: Show HN: Ezy – open-source gRPC client, alternative to Postman and Insomnia
#30Earlier quoted context omitted.
> 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: http…
> 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:…