Announcing gRPC Support in Nginx • Hacker News Board

Re: Announcing gRPC Support in Nginx

#31

Post by andrewflnr » Sun, Mar 18, 2018, 5:59 PM UTC

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…

Name some. Seriously, I'm interested in protocol design, so I'll read them. But also, yeah, just declaring that things exist is kind of unhelpful.

Re: Announcing gRPC Support in Nginx

#32

Post by sigmonsays » Sun, Mar 18, 2018, 6:00 PM UTC

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.

Re: Announcing gRPC Support in Nginx

#33

Post by throwawaysunday » Sun, Mar 18, 2018, 6:05 PM UTC

pagnol wrote: post #12

colordrops wrote: post #9

Earlier quoted context omitted.

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

I would also like to know why you don't consider it 'modern' and how you would define modern-ness in this context.

I answered above.

Re: Announcing gRPC Support in Nginx

#34

Post by detaro » Sun, Mar 18, 2018, 6:09 PM UTC

throwawaysunday wrote: post #7

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, protob…

"Not cool" is telling the long-term maintainers of software what "has no place in their software" and not to fulfill user/customer requests because that'd be helping a company you don't like.

Google's influence in many parts is a problem, but people using an internal protocol they've made up is basically irrelevant IMHO, unless you have a really good argument why it is a problem.

Re: Announcing gRPC Support in Nginx

#35

Post by haberman » Sun, Mar 18, 2018, 6:11 PM UTC

tilpner wrote: post #20

colordrops wrote: post #9

Earlier quoted context omitted.

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

https://google.github.io/flatbuffers/ and https://capnproto.org/ are both successors to protobuf

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

(Disclosure: I work at Google on the protobuf team)

Re: Announcing gRPC Support in Nginx

#36

Post by an_d_rew » Sun, Mar 18, 2018, 6:13 PM UTC

StevePerkins wrote: post #29

adamkl wrote: post #22

Earlier quoted context omitted.

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.

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…

> 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.

Re: Announcing gRPC Support in Nginx

#37

Post by pacala » Sun, Mar 18, 2018, 6:17 PM UTC

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/master/go/gr...

Re: Announcing gRPC Support in Nginx

#38

Post by dankohn1 » Sun, Mar 18, 2018, 6:17 PM UTC

throwawaysunday wrote: post #7

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, protob…

Note that gRPC was created by Google but was contributed to CNCF last year. https://www.cncf.io/blog/2017/03/01/cloud-native-computing-f...

It's now being used by tons of different companies, including Google competitors like Microsoft Azure.

Disclosure: I'm the executive director of CNCF.

Re: Announcing gRPC Support in Nginx

#39

Post by jbreiding » Sun, Mar 18, 2018, 6:18 PM UTC

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…

It's easy to argue you are just rattling off buzzwords if you don't provide examples.

I would also argue that not based on a schema is even more brittle as you end up implementing validation logic and client marshalling that the schema would allow you to just generate.

Re: Announcing gRPC Support in Nginx

#40

Post by acidus » Sun, Mar 18, 2018, 6:20 PM UTC

StevePerkins wrote: post #29

adamkl wrote: post #22

Earlier quoted context omitted.

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.

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…

I actually think that the design of gRPC must have been a great deal of effort. The project proposes an scalable solution with simple enough interfaces that smaller teams have been able to adopt quickly. I admire that very much!