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

21–30 of 81 posts

Re: Announcing gRPC Support in Nginx

#21

Post by manigandham »

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…

What are better options?

The difference is between open (which gRPC is) and proprietary. The origination doesn't really matter. Lots of great open tech has come from Google, Microsoft, Apple, Amazon, Facebook, Netflix, Github, etc. Almost all the big projects started at a big company that needed to get something done and had the resources to create something new.

I'd rather the industry pick something and actually standardize instead of reinventing the same thing repeatedly just for some philosophical reasons.

Re: Announcing gRPC Support in Nginx

#22

Post by adamkl »

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.

Re: Announcing gRPC Support in Nginx

#23

Post by jkaplowitz »

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

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.

Re: Announcing gRPC Support in Nginx

#24

Post by throwawaysunday »

colordrops wrote: post #9
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…

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

Re: Announcing gRPC Support in Nginx

#25

Post by throwawaysunday »

masklinn wrote: post #15
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…

> There is no place for gRPC in NGINX. Meh. There's place in NGINX for Adobe HDS[0], flv streaming[1], JWT[2], memcached[3], flash mp4 pseudo-streaming[4] and XLST[5]. Hell, spdy draft 3.1 is still supported[6]… [0] http://nginx.org/en/docs/http/ngx_http_f4f_module.html [1] http://nginx.org/en/docs/http/ngx_http_flv_module.html [2] http://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html [3] http://nginx.org/en/do…

That's all very well, but Adobe don't have aspirations of running the entire internet.

Same can be said for all the other things you hastily rushed to link to, those are not infrastructure protocols

Re: Announcing gRPC Support in Nginx

#26

Post by an_account_name »

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.

Their tests live in a separate repo

Re: Announcing gRPC Support in Nginx

#27

Post by throwawaysunday »

manigandham wrote: post #21
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…

What are better options? The difference is between open (which gRPC is) and proprietary. The origination doesn't really matter. Lots of great open tech has come from Google, Microsoft, Apple, Amazon, Facebook, Netflix, Github, etc. Almost all the big projects started at a big company that needed to get something done and had the resources to create something new. I'd rather the industry pick something and actually st…

I agree with the industry picking something part.

The part I'm not keen on is nobody asks for a discussion on things anymore, they just check stuff in and it becomes a defacto standard.

Which can be okay... but I'm not a fan of foie gras for a reason

Re: Announcing gRPC Support in Nginx

#28

Post by manigandham »

throwawaysunday wrote: post #27
manigandham wrote: post #21

Earlier quoted context omitted.

What are better options? The difference is between open (which gRPC is) and proprietary. The origination doesn't really matter. Lots of great open tech has come from Google, Microsoft, Apple, Amazon, Facebook, Netflix, Github, etc. Almost all the big projects started at a big company that needed to get something done and had the resources to create something new. I'd rather the industry pick something and actually st…

I agree with the industry picking something part. The part I'm not keen on is nobody asks for a discussion on things anymore, they just check stuff in and it becomes a defacto standard. Which can be okay... but I'm not a fan of foie gras for a reason

Ok, but what do you find are better options then? If you have examples then we can discuss why they haven't taken off as popular standards.

Re: Announcing gRPC Support in Nginx

#29

Post by StevePerkins »

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.

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

Re: Announcing gRPC Support in Nginx

#30

Post by pkaye »

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…

Is Google behind this integration effort?
Post reply on HN