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

71–80 of 81 posts

Re: Announcing gRPC Support in Nginx

#71

Post by adrianmonk »

adrianmonk wrote: post #58
chuckdries wrote: post #52

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.

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…

In case it was confusing, I meant to type "set of method calls" in my comment above, not "series of set method calls".

(I'd edit the comment but it's too late.)

Re: Announcing gRPC Support in Nginx

#72

Post by merb »

adamkl wrote: post #60
haberman wrote: post #51

Earlier quoted context omitted.

I think this is a bit of an oversimplification. The modern approach to RPC is very different than CORBA or even SOAP/XML. CORBA was designed around the idea of distributed objects. The core idea was that you have a reference to an object but you don't know (or care) if the object lives in your address space or on a remote computer somewhere. When you make a "remote procedure call", CORBA tries to make it behave as if…

I totally agree that these new technologies are an improvement, and I have no desire to go back to SOAP/XML, I was just commenting on the statement: An rpc system with a schema and code generation is a must for internal services. Which seemed to suggest that gRPC is somehow novel in this respect.

well I would guess the difference between soap and grpc is that soap was developed as a standard, while gRPC became one (or is becoming one).

Also the biggest difference is, that soap had like a trillion implementations which all worked kinda differently. code generation, etc.. GRPC somewhat does not have this problem because basically there is only one client implementation managed by google (now the cnf).

also in soap you basically built your server first, because writing a wsdl from scratch is like... akward. the idl of grpc is extremly simple to actually start without any implementation at all. and as a bonus it works way better if you need to add/change fields.

Re: Announcing gRPC Support in Nginx

#73

Post by jkaplowitz »

_skel wrote: post #69
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.

I'd more say that it gets rid of the need for officially-supported client libraries, but such libraries can still be a nice convenience for idiomatically mapping your service's higher-level concepts to what makes sense for a given language.

Still, it's a big win to automatically make your API available in all gRPC-supported languages, since most companies can't justify the business cost of a hand-crafted library in even one of those languages, let alone all.

Re: Announcing gRPC Support in Nginx

#74

Post by pebers »

whyrusleeping wrote: post #10
perfmode wrote: post #4

Seems they punted on graceful handling of bidirectional streams.

last i checked grpc could only technically support bidirectional streams. None of the libraries I looked at actually implemented it.

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.

Re: Announcing gRPC Support in Nginx

#76

Post by icholy »

throwawaysunday wrote: post #24
colordrops wrote: post #9

Earlier quoted context omitted.

Just out of curiosity, what's a modern alternative to protobufs?

One that is type extensible, not brittle and based on schemas with fragile language integration tools, is streamable down to the atom level, naturally sortable, homoiconic in nature and efficient to produce and consume. Such things exist, I'm not just rattling off buzzwords. The main thing is protocols are serious business and people, especially any of the big five shouldn't get to own them just because it suits a bu…

> Such things exist, I'm not just rattling off buzzwords.

you are though ...

Re: Announcing gRPC Support in Nginx

#77

Post by theshrike79 »

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?

Low latency and/or low bandwidth data transfer in M2M communication, especially when the client and servers are done in different languages.

Re: Announcing gRPC Support in Nginx

#78

Post by x25519 »

nginxgrpc wrote: post #3
x25519 wrote: post #2

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

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.

They're here: https://hg.nginx.org/nginx-tests/

Re: Announcing gRPC Support in Nginx

#79

Post by trustin »

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…

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

Re: Announcing gRPC Support in Nginx

#80

Post by vasco »

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…

Thrift mostly solves the problem of crashing a lot and being an undependable mess.
Post reply on HN