And yet -- grpc is still "incubating". Do these statuses really mean much?
Reading between the lines, it sounds like the main problem is Google's tight control over the project. Apple contributes to the Swift implementation and MSFT drives the native .NET implementation, but there's little non-Google input in decision-making for Go, Java, C++ core, or any of the implementations that wrap core.
More subjectively, I'm impressed by the CNCF's willingness to stick to their stated graduation criteria. gRPC is widely used (even among other CNCF projects), and comes from the company that organized the CNCF - there must have been a lot of pressure to rubber-stamp the application.
Unlike the other gRPC implementations, it's also taken seriously by MSFT's entire developer division. MSFT contributed a bunch of performance improvements to the protobuf runtime and generated code for .NET, the Kestrel webserver team runs gRPC benchmarks, and support for gRPC-Web is baked right into the core frameworks. From a user perspective, it's clear that someone cares about how all the pieces fit together.
Maybe it is about time to gRPC Windows. :)
There is little doubt in my mind that gRPC is a larger and more impactful project than Istio.
Full disclosure: This is my tool
A bit awkward to use but lots of great info there. I use it every now and then (I'm a maintainer of Dapr).
If you goto to https://devboard.gitsense.com/dapr/dapr?board=gitsense_examp... you can see how my DevBoard widget system is different than Grafanas. Note, the repo that I talk about in the Intro page hasn't been pushed to GitHub yet, but will be soon (hopefully by the end of this week). I'm planning on creating widgets where you can just feed it some numbers and it will generate a graph, but since my widgets can be programmed, you can do much more with the data to tell a story and to help surface insights.
On a personal level, it's one of those projects that someone obsessed with "perfect engineering" develops, regardless of the human cost. Crappier solutions (ex. JSON-over-HTTP) are better in almost all cases.
gRPC _does_ require support for HTTP trailers, which aren't used much elsewhere. If you want to use streaming RPCs, you also need a proxy that doesn't buffer (or allows you to disable buffering).
You couldn't get a better example of good pragmatic engineering than gRPC compared to something like CORBA or DCOM. I can't talk about "all cases" but in the cases I've come across it's a much better solution than JSON over http.
It decouples the service addresses via a pubsub architecture.
So if I want service A to send a request to service B, then it is done by subscribing to a shared topic, there is no service discovery.
It kind of replaces GRPC and Istio.
I like the “static typing” and code generation you get from grpc so a hybrid of the 2 would be my preference.
I actually solved the code generation part for NATS though by using AsyncAPI (like Open API but for messaged based systems). Would be better if baked in.
Would love to see this work supported by the core Nats team. A standard spec so others could make clients.
I love a good queue, but these are “orthogonal” to borrow a favourite HN term.
If you don’t think about the tech between services, at the end of the day my service is using some protocol to send and receive data, using grpc or otherwise.
NATS has a clean request/reply paradigm built in that makes this simpler.
The proto files format is ok, because it has nullability defined in the type.
However everything else is bad. I had to use grpc on a project and it was a pain and created problems.
Want to use postman to test locally? Forget it, you have to use some grpc client, and all of them are not ideal.
Want to write automation tests? Good luck finding a tool that supports grpc.
Want to add distributed tracing to calls? You have to use some unofficial code, and better learn the grpc implementation details if you want to be sure that the code is good.
Use json over http, or json over http2 if possible. You will have a much better and less frustrating experience.
Grpc is good for servers moving petabytes of data and for low latency needs (compressed json over http2 would be the same performance in terms of low latency, maybe a few percent slower). I guess 99% of it's users would do much better with a json over http interface.
Nowdays it is very easy to make an http call. In java it can be done with an annotation over an interface method, ex: https://docs.spring.io/spring-cloud-openfeign/docs/current/r... It is also recomended to store the data types used in the interface externally, similar to how proto files work, so that you don't have code duplication on the client and the server.
gRPC itself runs on top of HTTP.