3 ms·
I’ve been using BloomRPC for the past year, but it’s definitely got a few rough spots. Very excited to try this out.
by sorahn 5y ago
I’ve been using BloomRPC for the past year, but it’s definitely got a few rough spots.
Very excited to try this out.
- thcyron 5y agoIf you’re on the Mac, you might want to give Grip (https://gripgrpc.dev https://gripgrpc.dev) a chance. It’s a native client for gRPC. (Disclosure: I’m the author.)
- dewey 5y agoVery nice, thanks for sharing. I'll take a look.
- evanmoran 5y agoLooks great! How’s the reception so far? Many of our APIs have some streaming, is that something on your roadmap?
- thcyron 5y agoIt’s definitely on the roadmap. Out of curiosity, do you use client/server streaming or bidirectional streaming?
- evanmoran 5y agoServer streaming, though I'm not sure how representative we are. We have servers that use streaming for watching for real-time changes. Currently using BloomRPC, if that helps
- ProtocallDev 5y agoGrip looks super cool - it's one of the few other clients I've seen that will render structured input fields to make it easier to construct complex messages. If you have a more urgent need for server-side streaming support, you could also check out Protocall (https://protocall.dev https://protocall.dev - disclaimer, I'm the author) - it supports all four rpc types (Unary as well as Client/Server/Bidirectional streaming), along with the structured input field rendering and automatic import resolution (via Github repo import). I wrote it because existing tooling like BloomRPC and gRPCurl were difficult to use for anything more complicated than "Hello, World". I was also looking for tools that would let me send protobuf-encoded requests via HTTP/1.1 rather than gRPC, which didn't seem to exist at the time.