8 ms·

Announcing gRPC Support in Nginx

384 points by tex0 9y ago

x25519 9y ago
Code Initial commit: https://hg.nginx.org/nginx/rev/2713b2dbf5bb https://hg.nginx.org/nginx/rev/2713b2dbf5bb Additional features: https://hg.nginx.org/nginx/rev/c693daca57f7 https://hg.nginx.org/nginx/rev/c693daca57f7 and https://hg.nginx.org/nginx/rev/c2a0a838c40f https://hg.nginx.org/nginx/rev/c2a0a838c40f
- nginxgrpc 9y ago
  Wow, I was surprised at the sheer size of the diff. Huge! Can any of you tell if it includes unit tests? I didn't see any.
  - an_account_name 9y ago
    Their tests live in a separate repo
    - philipwhiuk 9y ago
      That must make working out whether a code change is well tested a whole bunch of fun.
  - x25519 9y ago
    They're here: https://hg.nginx.org/nginx-tests/ https://hg.nginx.org/nginx-tests/
perfmode 9y ago
Seems they punted on graceful handling of bidirectional streams.
- whyrusleeping 9y ago
  last i checked grpc could only technically support bidirectional streams. None of the libraries I looked at actually implemented it.
  - maltalex 9y ago
    > None of the libraries I looked at actually implemented it. Can you elaborate on that? AFAIK gRPC comes with bidirectional streams out of the box. I played around with gRPC on Java and it seemed to work.
    - jimmy1 9y ago
      Go user checking in here as well -- bidirectional streams work just fine
  - anameaname 9y ago
    All core grpc libraries support bidirectional streaming. It's the "routeguide" example.
  - pebers 9y ago
    We're using them between Python <-> Go with no problems. Can't remember exactly what version it was at when I first tried it but it's worked fine for two years or more.
toprerules 9y ago
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.
- adamkl 9y ago
  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.
  - StevePerkins 9y ago
    And CORBA/IDL was doing exactly the same 20 years prior to that. We get tired of things because they accumulate cruft, or are deemed "ugly" by younger developers. So we replace them with newer alternatives, that are more light and easy to reason about for newbies entering the profession. But then we eventually find that we needed more features after all, so we gradually re-implement them again until the cycle repeats. The industry wheel just keeps on spinning...
    - an_d_rew 9y ago
      > But then we eventually find that we needed more features after all, so we gradually re-implement them again until the cycle repeats. If the protocols and standards were designed lock-step with concrete implementation, I'd agree with you. But too much of SOAP, CORBA, yada-yada was designed _before_ any implementation occurred. So they are nasty and cruft-filled long before even version 1.0. Protocol Buffers ain't perfect, but they've been vastly deployed and hugely battle tested, so their ratio of cruft/useful remains tolerably low.
      - jchw 9y ago
        SOAP was overdesigned and yet somehow still underspecified at the same time. You could implement two different implementations that both followed the specs religiously that could not interop at all. It's hard to overstate how crappy working with SOAP really was. I think as the industry matures we really will see serialization formats and protocols stabilize, I think we've already seen a bit of it with JSON.
grizzles 9y ago
This is great; I also recently published an alternative designed for browser clients: https://github.com/ericbets/danby https://github.com/ericbets/danby It's designed to be very simple to configure. It doesn't support streams yet, but it should soon.
throwawaysunday 9y ago
This is not cool There is no place for gRPC in NGINX. This is Google trying to thin end of the wedge their own proprietary protocols into web standards yet again. My idea of a good time is not a future where the internet is built using Google technologies dressed as "open technologies".. that.. uh-huh just happen to be the exact same as infrastructure protocols that span the internal Googleverse. Besides that, protobuf and its ilk aren't even good or modern. People who say, yay look at it growing are very naive imho
- colordrops 9y ago
  Just out of curiosity, what's a modern alternative to protobufs?
  - pagnol 9y ago
    I would also like to know why you don't consider it 'modern' and how you would define modern-ness in this context.
    - throwawaysunday 9y ago
      I answered above.
  - tilpner 9y ago
    https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/ and https://capnproto.org/ https://capnproto.org/ are both successors to protobuf
    - jkaplowitz 9y ago
      gRPC uses Protobuf version 3. Both it and CapnProto are successors to Protobuf version 2. Flatbuffers is not a successor but is targeted at a different use case.
    - haberman 9y ago
      I don't think they are successors, just different. Protobuf is a sparse wire format, whereas FlatBuffers and Cap'n Proto use a fixed-layout wire format. There are plusses and minuses to both. I wrote a little bit about this here: https://news.ycombinator.com/item?id=6329041#6330426 https://news.ycombinator.com/item?id=6329041#6330426 (Disclosure: I work at Google on the protobuf team)
anameaname 9y ago
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?
- pacala 9y ago
  > 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 https://github.com/improbable-eng/grpc-web/tree/master/ts [1] https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md [2] https://github.com/improbable-eng/grpc-web/tree/master/go/grpcwebproxy https://github.com/improbable-eng/grpc-web/tree/master/go/gr...
  - pieterlouw 9y ago
    Caddy Web Server (https://caddyserver.com https://caddyserver.com) have support for gRPC-Web through it's grpc plugin: https://caddyserver.com/docs/http.grpc https://caddyserver.com/docs/http.grpc
  - trustin 9y ago
    Armeria [0] supports pretty much every possible combination of gRPC variants, including gRPC-Web - HTTP/1 and 2, TLS and cleartext, Protobuf and JSON, framed and unframed. (Disclosure: My team and I wrote it.) [0] https://line.github.io/armeria https://line.github.io/armeria
- rubiquity 9y ago
  I remember seeing that Nginx has TCP proxying as well. Couldn’t that be an option?
  - jacques_chester 9y ago
brunosutic 9y ago
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.
- merb 9y ago
  from my understanding this only works over h2 or h2c
- tango12 9y ago
  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.
sigmonsays 9y ago
haproxy has had http/2 supports beginning 1.6 ( May 2015) however I have not yet looked into using it. I do wonder if it posses the same features in terms of inspecting the method names on a per request basis.
Matthias247 9y ago
If gRPC would have been designed slightly different, they could have had good proxy support AND browser support right from the start. E.g. it's already based on top of HTTP(/2), and uses normal path for distinguishing methods, which would actually be a good prerequisite to make it work everywhere. But then OTOH it uses barely support HTTP features like trailers, which require very special HTTP libraries and are not universally supported. If the status codes there would have been implemented as just another chunk of the HTTP body, and if some other small changes had been done, we could have had gprc from browsers already a long time ago. I guess that's what grpc-web now tries to fix, but I haven't dug into that in detail.
- mratzloff 9y ago
  I'm using grpc-web in a service that's going live soon. It works great.
- anameaname 9y ago
  For the record, the reason grpc uses trailers is because it uses http/2, not the other way around. It was expected that since the whole transport was completely new, adopters of http/2 would add trailer support. As it turns out, they mostly didn't. Particularly Firefox and Chrome did not expose trailers. This is even despite being part of the new Fetch API.
chuckdries 9y ago
Anyone have a good ELI5 of gRPC? It says it's a fast RPC implementation, but all the explanations of RPC seem very in-the-weeds.
- compsciphd 9y ago
  short: protobuf based (so relatively language agnostic) rpc mechanisms that communicates over http2 slightly longer: one writes a protobuf that gets compiled into a language specific server and client code. All you have to do is implement the server functions or call the generated client functions to make rpc calls.
- adrianmonk 9y ago
  Not sure if you're looking for an explanation of RPC in general or just specifically how gRPC does it, but I guess I'll kind of cover both. You define a series of set method calls, using a custom language. Each method call has a single message as its request and another message as its response. (You can actually get fancier than this, but you usually don't.) In gRPC, the messages are usually protocol buffers (though other formats are supported like JSON). The method calls are organized into groups called services. You stick these definitions in a file, then run a tool that takes these definitions and generates code in your desired language (Java, Python, etc. -- gRPC supports many languages). This code allows you to build objects that will get turned into protocol buffers wire format and sent across from client to server and back. So for example, if you define a method Foo that takes a FooRequest and returns a FooResponse, you would put this a definition file, run a tool that generates some code. For the sake of this example, we'll say you're using Java for everything, so you tell the tool to generate Java code. This generated Java code would include code to create a FooRequest object, set values in it (strings, ints, etc.). It would also include a Java method you can call that takes your FooRequest and sends it to the server and that gives you back a FooResponse after the server responds. On the server side, you also get Java code that is generated to help you respond to this request. Your Java code on the server side will receive a FooRequest, and it can use generated Java code to read the fields out of it (those same strings, ints, etc.), and then it can build a response in the same way that the client built the request. On the client, there is obviously some work involved in opening connections to the server, converting the FooRequest into wire-format data (and vice versa for FooResponse), but that is done for you, and you just need to tell it the server's address. On the server, there is work involved in listening for connections from clients, figuring out which RPC method is being called and routing it to the right Java method, converting the wire-format data into objects (and vice versa), but all that is done for you, and you just need to tell it what port to listen on. gRPC itself uses HTTP/2 and makes POST calls when your client calls a method. The methods and services you define are mapped to URLs. So if you define a Bar service with a Foo method inside, it will be turned into /Bar/Foo when the HTTP call is made.
andrewstuart 9y ago
OK so what are good use cases for gRPC? What problem does it solve, and in what contexts should I be reaching for gRPC?
- ericjang 9y ago
  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.
  - rejectedalot 9y ago
    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.
  - vasco 9y ago
    Thrift mostly solves the problem of crashing a lot and being an undependable mess.
- awinder 9y ago
  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.
- dbmikus 9y ago
  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.
awinder 9y ago
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?
wolfspider 9y ago
congrats to the Nginx team and contributors! some of us have been waiting anxiously for this release- this will be great!

384 points by tex0 9y ago

Code Initial commit: https://hg.nginx.org/nginx/rev/2713b2dbf5bb https://hg.nginx.org/nginx/rev/2713b2dbf5bb Additional features: https://hg.nginx.org/nginx/rev/c693daca57f7 https://hg.nginx.org/nginx/rev/c693daca57f7 and https://hg.nginx.org/nginx/rev/c2a0a838c40f https://hg.nginx.org/nginx/rev/c2a0a838c40f

nginxgrpc 9y ago
Wow, I was surprised at the sheer size of the diff. Huge! Can any of you tell if it includes unit tests? I didn't see any.
- an_account_name 9y ago
  Their tests live in a separate repo
  - philipwhiuk 9y ago
    That must make working out whether a code change is well tested a whole bunch of fun.
- x25519 9y ago
  They're here: https://hg.nginx.org/nginx-tests/ https://hg.nginx.org/nginx-tests/

perfmode 9y ago

Seems they punted on graceful handling of bidirectional streams.

whyrusleeping 9y ago
last i checked grpc could only technically support bidirectional streams. None of the libraries I looked at actually implemented it.
- maltalex 9y ago
  > None of the libraries I looked at actually implemented it. Can you elaborate on that? AFAIK gRPC comes with bidirectional streams out of the box. I played around with gRPC on Java and it seemed to work.
  - jimmy1 9y ago
    Go user checking in here as well -- bidirectional streams work just fine
- anameaname 9y ago
  All core grpc libraries support bidirectional streaming. It's the "routeguide" example.
- pebers 9y ago
  We're using them between Python <-> Go with no problems. Can't remember exactly what version it was at when I first tried it but it's worked fine for two years or more.

toprerules 9y ago

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.

adamkl 9y ago
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.
- StevePerkins 9y ago
  And CORBA/IDL was doing exactly the same 20 years prior to that. We get tired of things because they accumulate cruft, or are deemed "ugly" by younger developers. So we replace them with newer alternatives, that are more light and easy to reason about for newbies entering the profession. But then we eventually find that we needed more features after all, so we gradually re-implement them again until the cycle repeats. The industry wheel just keeps on spinning...
  - an_d_rew 9y ago
    > But then we eventually find that we needed more features after all, so we gradually re-implement them again until the cycle repeats. If the protocols and standards were designed lock-step with concrete implementation, I'd agree with you. But too much of SOAP, CORBA, yada-yada was designed _before_ any implementation occurred. So they are nasty and cruft-filled long before even version 1.0. Protocol Buffers ain't perfect, but they've been vastly deployed and hugely battle tested, so their ratio of cruft/useful remains tolerably low.
    - jchw 9y ago
      SOAP was overdesigned and yet somehow still underspecified at the same time. You could implement two different implementations that both followed the specs religiously that could not interop at all. It's hard to overstate how crappy working with SOAP really was. I think as the industry matures we really will see serialization formats and protocols stabilize, I think we've already seen a bit of it with JSON.

grizzles 9y ago

This is great; I also recently published an alternative designed for browser clients: https://github.com/ericbets/danby https://github.com/ericbets/danby It's designed to be very simple to configure. It doesn't support streams yet, but it should soon.

throwawaysunday 9y ago

This is not cool There is no place for gRPC in NGINX. This is Google trying to thin end of the wedge their own proprietary protocols into web standards yet again. My idea of a good time is not a future where the internet is built using Google technologies dressed as "open technologies".. that.. uh-huh just happen to be the exact same as infrastructure protocols that span the internal Googleverse. Besides that, protobuf and its ilk aren't even good or modern. People who say, yay look at it growing are very naive imho

colordrops 9y ago
Just out of curiosity, what's a modern alternative to protobufs?
- pagnol 9y ago
  I would also like to know why you don't consider it 'modern' and how you would define modern-ness in this context.
  - throwawaysunday 9y ago
    I answered above.
- tilpner 9y ago
  https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/ and https://capnproto.org/ https://capnproto.org/ are both successors to protobuf
  - jkaplowitz 9y ago
    gRPC uses Protobuf version 3. Both it and CapnProto are successors to Protobuf version 2. Flatbuffers is not a successor but is targeted at a different use case.
  - haberman 9y ago
    I don't think they are successors, just different. Protobuf is a sparse wire format, whereas FlatBuffers and Cap'n Proto use a fixed-layout wire format. There are plusses and minuses to both. I wrote a little bit about this here: https://news.ycombinator.com/item?id=6329041#6330426 https://news.ycombinator.com/item?id=6329041#6330426 (Disclosure: I work at Google on the protobuf team)

anameaname 9y ago

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?

pacala 9y ago
> 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 https://github.com/improbable-eng/grpc-web/tree/master/ts [1] https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md [2] https://github.com/improbable-eng/grpc-web/tree/master/go/grpcwebproxy https://github.com/improbable-eng/grpc-web/tree/master/go/gr...
- pieterlouw 9y ago
  Caddy Web Server (https://caddyserver.com https://caddyserver.com) have support for gRPC-Web through it's grpc plugin: https://caddyserver.com/docs/http.grpc https://caddyserver.com/docs/http.grpc
- trustin 9y ago
  Armeria [0] supports pretty much every possible combination of gRPC variants, including gRPC-Web - HTTP/1 and 2, TLS and cleartext, Protobuf and JSON, framed and unframed. (Disclosure: My team and I wrote it.) [0] https://line.github.io/armeria https://line.github.io/armeria
rubiquity 9y ago
I remember seeing that Nginx has TCP proxying as well. Couldn’t that be an option?
- jacques_chester 9y ago

brunosutic 9y ago

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.

merb 9y ago
from my understanding this only works over h2 or h2c
tango12 9y ago
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.

sigmonsays 9y ago

haproxy has had http/2 supports beginning 1.6 ( May 2015) however I have not yet looked into using it. I do wonder if it posses the same features in terms of inspecting the method names on a per request basis.

Matthias247 9y ago

If gRPC would have been designed slightly different, they could have had good proxy support AND browser support right from the start. E.g. it's already based on top of HTTP(/2), and uses normal path for distinguishing methods, which would actually be a good prerequisite to make it work everywhere. But then OTOH it uses barely support HTTP features like trailers, which require very special HTTP libraries and are not universally supported. If the status codes there would have been implemented as just another chunk of the HTTP body, and if some other small changes had been done, we could have had gprc from browsers already a long time ago. I guess that's what grpc-web now tries to fix, but I haven't dug into that in detail.

mratzloff 9y ago
I'm using grpc-web in a service that's going live soon. It works great.
anameaname 9y ago
For the record, the reason grpc uses trailers is because it uses http/2, not the other way around. It was expected that since the whole transport was completely new, adopters of http/2 would add trailer support. As it turns out, they mostly didn't. Particularly Firefox and Chrome did not expose trailers. This is even despite being part of the new Fetch API.

chuckdries 9y ago

Anyone have a good ELI5 of gRPC? It says it's a fast RPC implementation, but all the explanations of RPC seem very in-the-weeds.

compsciphd 9y ago
short: protobuf based (so relatively language agnostic) rpc mechanisms that communicates over http2 slightly longer: one writes a protobuf that gets compiled into a language specific server and client code. All you have to do is implement the server functions or call the generated client functions to make rpc calls.
adrianmonk 9y ago
Not sure if you're looking for an explanation of RPC in general or just specifically how gRPC does it, but I guess I'll kind of cover both. You define a series of set method calls, using a custom language. Each method call has a single message as its request and another message as its response. (You can actually get fancier than this, but you usually don't.) In gRPC, the messages are usually protocol buffers (though other formats are supported like JSON). The method calls are organized into groups called services. You stick these definitions in a file, then run a tool that takes these definitions and generates code in your desired language (Java, Python, etc. -- gRPC supports many languages). This code allows you to build objects that will get turned into protocol buffers wire format and sent across from client to server and back. So for example, if you define a method Foo that takes a FooRequest and returns a FooResponse, you would put this a definition file, run a tool that generates some code. For the sake of this example, we'll say you're using Java for everything, so you tell the tool to generate Java code. This generated Java code would include code to create a FooRequest object, set values in it (strings, ints, etc.). It would also include a Java method you can call that takes your FooRequest and sends it to the server and that gives you back a FooResponse after the server responds. On the server side, you also get Java code that is generated to help you respond to this request. Your Java code on the server side will receive a FooRequest, and it can use generated Java code to read the fields out of it (those same strings, ints, etc.), and then it can build a response in the same way that the client built the request. On the client, there is obviously some work involved in opening connections to the server, converting the FooRequest into wire-format data (and vice versa for FooResponse), but that is done for you, and you just need to tell it the server's address. On the server, there is work involved in listening for connections from clients, figuring out which RPC method is being called and routing it to the right Java method, converting the wire-format data into objects (and vice versa), but all that is done for you, and you just need to tell it what port to listen on. gRPC itself uses HTTP/2 and makes POST calls when your client calls a method. The methods and services you define are mapped to URLs. So if you define a Bar service with a Foo method inside, it will be turned into /Bar/Foo when the HTTP call is made.

andrewstuart 9y ago

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

ericjang 9y ago
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.
- rejectedalot 9y ago
  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.
- vasco 9y ago
  Thrift mostly solves the problem of crashing a lot and being an undependable mess.
awinder 9y ago
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.
dbmikus 9y ago
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.

awinder 9y ago

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?

wolfspider 9y ago

congrats to the Nginx team and contributors! some of us have been waiting anxiously for this release- this will be great!