What does HackerNews think of grpc-gateway?

I don't have any example that's public atm, but the guide in grpc-gateway is pretty clear/can be followed step by step.

https://github.com/grpc-ecosystem/grpc-gateway

To integrate with Fiber, I used the Fiber Adaptor (also pretty straightforward): https://docs.gofiber.io/api/middleware/adaptor

There's no reason you couldn't use gRPC with json as a serialized message format. For example grpc-gateway [0] provides a very effective way of mapping a gRPC concept to HTTP/JSON. The thing is, after moving to gRPC, I've never really felt a desire to move back to JSON. While it may be correct to say "parsing json is fast enough" it's important to note that there's a "for most use cases" after that. Parsing protos is fast enough for even more use cases. You also get streams which are amazing for APIs where you have to sync some large amounts of data (listing large collections from a DB for example) across two services.

With gRPC you also have a standardized middleware API that is implemented for "all" languages. The concepts cleanly map across multiple languages and types are mostly solved for you.

Adding to that you can easily define some conventions for a proto and make amazing libraries for your team. At a previous job I made this: https://github.com/CaperAi/pronto/

Made it super easy to prototype multiple services as if you mock a service backed by memory we could plop it into a DB with zero effort.

I think this "gRPC vs X" method of thinking isn't appropriate here because protos are more like a Object.prototype in JavaScript. They're a template for what you're sending. If you have the Message you want to send you can serialize that to JSON or read from JSON or XML or another propriety format and automatically get a host of cool features (pretty printing, serialization to text/binary, sending over the network, etc).

[0] - https://github.com/grpc-ecosystem/grpc-gateway

I had really good success with https://github.com/grpc-ecosystem/grpc-gateway for returning json to the web from a grpc system

That's available with GRPC to JSON transcoding https://github.com/grpc-ecosystem/grpc-gateway

> I think what you describe is the shortcoming of the initial grpc spec. It was for some reason decided to define it on top of features which are barely implemented outside of HTTP/2 and special libraries (especially: Trailers). But it would have been possible to just define things on top of common HTTP semantics. This is what grpc-web now fixes according to my understanding.

This is also my understanding (minus the Trailers bit) -- there's stuff like grpc-gateway[0] that I've considered using before so I know there's a mapping (whether it's easy to use is another thing) from grpc to HTTP/1.1 ...

> I think even streaming should have been possible with HTTP/1.1. Bodies can be streamed there just fine, if libraries support it (for browsers the issue was up to now that the APIs don't support access to bodies as streams). The only thing I'm not sure if there is an issue in HTTP/1.1 with request streams still running while the response stream has already finished.

For streaming I was thinking mostly of the duplex streams, i.e. what Websockets brought to the table, everything else would be pretty hacky. I suspect that grpc translates to regular browser-ready HTTP/1.1 REST pretty easily (outside of trying to decide how), minus the streaming bit, since you'd have to do some sort of comet/long polling/sse/websockets approach.

[0]: https://github.com/grpc-ecosystem/grpc-gateway

Check out grpc-gateway[1]

[1]: https://github.com/grpc-ecosystem/grpc-gateway/

Does this work? https://github.com/grpc-ecosystem/grpc-gateway

Seems to generate a REST proxy server side.

That's pretty much exactly what tools like https://github.com/grpc-ecosystem/grpc-gateway are doing

There is also the grpc-gateway project for JSON transcoding https://github.com/grpc-ecosystem/grpc-gateway

Have you seen https://github.com/grpc-ecosystem/grpc-gateway? It generates a reverse proxy that converts proto <-> JSON and will even output a Swagger definition you can use with a JS client library.

There's actually a stand-alone proxy that translates the REST mappings of `google.api.http` into gRPC requests. It relies on code-generation: https://github.com/grpc-ecosystem/grpc-gateway

This has been the way we've been shipping our REST services until now, but the need to recompile the proxy was a major hinderence to our development speed. Hence gRPC-Web implementation.

The best part about Swagger is there's a lot of good open-source tooling for it (though this depends on the language).

One alternative I find super interesting lately is defining APIs with grpc and then exposing them with the gateway proxy: https://github.com/grpc-ecosystem/grpc-gateway

In this way, you get strongly-typed interfaces and Swagger is autogenned for you.

There's already a project that auto-generates a normal REST proxy from a gRPC definition: https://github.com/grpc-ecosystem/grpc-gateway

Useful related project: http://www.grpc.io/ is an excellent layer on top of HTTP2 for comms between backend services. It's from Google, and used by Docker and Square among others. It even comes with a rest-focused gateway https://github.com/grpc-ecosystem/grpc-gateway