41–50 of 81 posts
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?
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
Google doesn't own Nginx, so I find it hard to believe that there were no discussions and they just went ahead and "checked stuff in".
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?
I remember seeing that Nginx has TCP proxying as well. Couldn’t that be an option?
For example, how does a TCP proxy perform round-robin load balancing on a per-RPC basis? If it's a gRPC proxy then that capability becomes possible.
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?
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.
Earlier quoted context omitted.
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 pe…
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.
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.
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.
- The gRPC protocol is built on top of http2 - a protocol designed to overcome many of the shortcomings in http, primarily performance.
- protobuf is a much simpler serialization format that achieves far better performance than XML
- gRPC allows message streaming in both directions. For some use cases this is vital for achieving performance.
- there's a growing ecosystem to make it easier to work with large distributed systems. I could list a bunch, but I will just point to one: gRPC has many options for the load balancing of requests: https://grpc.io/blog/loadbalancing.
gRPC is clearly the better solution if you intend to build a large, multi-service, distributed system or want to build cloud APIs for mobile devices. And it's not just because developers hate XML.
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 u…