Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing gRPC Support in Nginx

nginx.com

Post reply on HN
Print view View original

61–70 of 81 posts

Re: Announcing gRPC Support in Nginx

#61

Post by pieterlouw »

pacala wrote: post #37
anameaname wrote: post #8

Finally! Up until now, when people ask how they are supposed to proxy grpc traffic, we could only recommend Envoy. Pretty much no one wants to hear that they have to change their stack to use new technology. Since a large part of the world is already on nginx, this was a a real barrier for adoption. Next up, browser support?

> Next up, browser support? Please! There is a working TypeScript client implementation [0] of gRPC-Web [1], which relies on a custom proxy for converting gRPC to gRPC-Web [2]. Would be nice to bring that proxy functionality into Nginx. [0] https://github.com/improbable-eng/grpc-web/tree/master/ts [1] https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md [2] https://github.com/improbable-eng/grpc-web/tree/mast…

Caddy Web Server (https://caddyserver.com) have support for gRPC-Web through it's grpc plugin: https://caddyserver.com/docs/http.grpc

Re: Announcing gRPC Support in Nginx

#62

Post by ericjang »

andrewstuart wrote: post #59

OK so what are good use cases for gRPC? What problem does it solve, and in what contexts should I be reaching for gRPC?

I used gRPC for numerous hobby projects during my undergrad to glue together binaries running in different languages (e.g. a simulation server running in C++ and a scripting client in Python). By passing around a shared data structure (Protobufs), one does not need to waste time writing serialization/de-serialization adapters. It is also useful for gluing together microservices.

FB's Thrift also solves the same problem, and is an alternative to gRPC.

Re: Announcing gRPC Support in Nginx

#63

Post by rejectedalot »

ericjang wrote: post #62
andrewstuart wrote: post #59

OK so what are good use cases for gRPC? What problem does it solve, and in what contexts should I be reaching for gRPC?

I used gRPC for numerous hobby projects during my undergrad to glue together binaries running in different languages (e.g. a simulation server running in C++ and a scripting client in Python). By passing around a shared data structure (Protobufs), one does not need to waste time writing serialization/de-serialization adapters. It is also useful for gluing together microservices. FB's Thrift also solves the same probl…

Going into the microservice aspect above, it provides a nice abstraction of remote function calls, so that you can write microservice code that looks like it's executing a local function, but is really just expecting a remote server to implement the method name. In general, that's just RPC calls though. Google's implementation has proven very intuitive to learn, and has a nice size community online for help debugging, etc.

Re: Announcing gRPC Support in Nginx

#64

Post by awinder »

Does this mean anything for http2, specifically anything for support for http2 upstreams? I would imagine that’s was a necessity to support for grpc so any way that will come to generic http2 as well?

Re: Announcing gRPC Support in Nginx

#65

Post by awinder »

andrewstuart wrote: post #59

OK so what are good use cases for gRPC? What problem does it solve, and in what contexts should I be reaching for gRPC?

Latency-sensitive / chatty microservices can benefit greatly. Some of this is by nature of http2 but it’s extended by protocol buffer packaging of messages and other client smarts. Inter-service comms is where this popped onto my radar recently.

Re: Announcing gRPC Support in Nginx

#66

Post by dbmikus »

andrewstuart wrote: post #59

OK so what are good use cases for gRPC? What problem does it solve, and in what contexts should I be reaching for gRPC?

If you want to have a set of globally defined types and/or language-independent types to share between your various programs or services, gRPC and Protobufs are a good option.

Also, anywhere that you might use RPC you could use gRPC. It has a compact wire format and is pretty user-friendly as far as designing your RPC req/rep types.

Re: Announcing gRPC Support in Nginx

#68

Post by ebikelaw »

adamkl wrote: post #22
toprerules wrote: post #5

I love seeing grpc grow. An rpc system with a schema and code generation is a must for internal services. Grpc has worked really well for me.

No disrespect intended, but I find this comment pretty funny. SOAP/XML has been exactly this for 20 years. It definitely has some major warts, but gRPC isn’t doing anything new.

Seems like a bad comparison. On the one hand you are apparently willing to overlook a 100x performance penalty associated with XML compared to protobuf. And then you apparently assign no value to the safety of a strongly-typed representation in C++ vs Doc*-you-figure-out-what-this-means.

Re: Announcing gRPC Support in Nginx

#69

Post by _skel »

andrewstuart wrote: post #59

OK so what are good use cases for gRPC? What problem does it solve, and in what contexts should I be reaching for gRPC?

You get type safety in your API, you get autogenerated client code, and you get http2 out of the box.

Personally I find the autogenerated client code to be the biggest upside. Anyone who wants to use your API, in any language supported by the RPC, can start doing it with very little work. Gone are the days of maintaining officially-supported client libraries.

Re: Announcing gRPC Support in Nginx

#70

Post by tango12 »

brunosutic wrote: post #16

This is great! TL;DR: instead of building JSON or GraphQL API now you can easily expose your gRPC service to the outside world! We use gRPC in my company. We're happy but some things were not easy or straightforward to implement. With this update nginx makes load balancing and authentication easier to implement.

I was actually just about to say that. There seems to be fair bit of overlap in graphql and grpc from the Codegen and Schema POV. Graphql is more intended to be a data query language and grpc more generic function calls.

But they’re both essentially solving the dev problem of having ‘typed contracts’ right?

Very interesting evolution! SOAP to REST to graphql more popular on the ‘frontend’ side and grpc on the ‘backend’ side.

Post reply on HN