8 ms·

And yet -- grpc is still "incubating". Do these statuses really mean much?

phillipcarter 3y ago
They do have meaning, but the meaning is orthogonal from metrics like total use throughout an industry: https://github.com/cncf/toc/blob/main/process/graduation_criteria.md#graduation-stage https://github.com/cncf/toc/blob/main/process/graduation_cri... There is little doubt in my mind that gRPC is a larger and more impactful project than Istio.
sdesol 3y ago
Here's the insights for grpc https://devboard.gitsense.com/grpc/grpc https://devboard.gitsense.com/grpc/grpc They are attracting less people than istio but not by much. Full disclosure: This is my tool
- verst 3y ago
  The CNCF has their own tool - a Grafana dashboard for all their projects: https://devstats.cncf.io https://devstats.cncf.io A bit awkward to use but lots of great info there. I use it every now and then (I'm a maintainer of Dapr).
  - sdesol 3y ago
    Yeah I was aware of devstats and yes the UI is awkward to use. I'm planning on open sourcing DevBoard, since GitSense is really the differentiating factor, so CNCF is free to use it, if it wants to. I personally think Grafana is great for analyzing time series data but I don't believe it's a very good dashboard system if you need to tell a story, which is what I believe software development insights needs. If you goto to https://devboard.gitsense.com/dapr/dapr?board=gitsense_examples.intro_to_widgets 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.
qbasic_forever 3y ago
IMHO that's accurate for grpc. The project works great if you're all golang on backend. As soon as you use other languages it gets complicated and the story falls apart--you almost certainly have to pull in tooling to manage protobuf generation, and proxying your grpc backend code to web frontend code (easy if your backend is golang, but many more options and questions if not). The fact grpc (and protobufs in general) need so much extra tooling is a bit of a code smell of immaturity and incubation IMHO.
- pjmlp 3y ago
  .NET tooling is quite good, although I have only used it in toy examples.
  - akshayshah 3y ago
    It's maintained by James Newton-King, so it's in the hands of .NET royalty :) 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.
    - pjmlp 3y ago
      Even if I only briefly used it, I wish they had the same love for the COM tooling, after 30 years, Visual Studio still can't offer an IDL editing experience similar to editing proto files. Maybe it is about time to gRPC Windows. :)
  - jayd16 3y ago
    +1 for gRPC for .NET. Its quite nice _except_ on macos. I forget the exact issue but there's some extra friction to hosting https locally on macos that makes the dev flow a lot more cumbersome.
    - 3y ago
akshayshah 3y ago
gRPC had a graduation application open for 3 years. It was rejected very recently: https://github.com/cncf/toc/pull/300 https://github.com/cncf/toc/pull/300. 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.
- bushbaba 3y ago
  100% this. GRPC has nearly all its code contributions by google. If google removed its funding the project would be at risk. It’s closer to a proprietary offering with source code available than a mature FOSS ecosystem. Think redhat enterprise Linux is to gRPC where-as istio/k8s is closer to Debian.
- evntdrvn 3y ago
  It’s really hard to have any influence on it unless you’re inside the Google fence. Even for the primary maintainers of those two external parties that you mentioned.
- tgma 3y ago
  You acknowledge contributions from several large companies. It's obvious it won't go away if Google pulls support or anything. Perhaps the fact that some random folks across the internet don't feel compelled to submit patches is simply due to the low level nature of the project and that it does the job quite well and its scope is limited by its nature, thereby limiting the need for customization by every individual. I really wonder what the standard is. If I recall correctly, for instance a certain proxy graduated by CNCF was such crap at one point that it linear searched routes. That naturally necessitates contributions if you actually use such software in production at scale.
- havnagiggle 3y ago
arein3 3y ago
Hopefully grpc will never graduate as to not encourage people to use it. There are better ways.
- hardwaresofton 3y ago
  c'mon, you gotta at least drop some of the "better ways" you prefer.
  - devmunchies 3y ago
    I prefer another CNCF incubating project, NATS. (nats.io) 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.
    - dilyevsky 3y ago
      There's a proto service implementation from NATS folks that I think does what you want - https://github.com/nats-rpc/nrpc https://github.com/nats-rpc/nrpc
      - devmunchies 3y ago
        Nice! We don’t use Go though :) we use F#, Rust, and C. Would love to see this work supported by the core Nats team. A standard spec so others could make clients.
    - FridgeSeal 3y ago
      Nats is a message bus/queue though, which is different from the serialisation format and rpc framework offered by protobufs +grpc. I love a good queue, but these are “orthogonal” to borrow a favourite HN term.
throwawaaarrgh 3y ago
Some of Google Cloud's critical APIs only seem to use gRPC over HTTPS. It relies on such an esoteric part of the TLS specification that many (most?) proxies can't carry the traffic. You end up hunting for 2 days to find out why your connections don't work only to realize they probably never will. So I would say it's good that gRPC isn't being pushed hard yet. 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.
- akshayshah 3y ago
  I've never encountered a proxy that can't do the portions of TLS 1.3 that gRPC requires - NGINX, Envoy, linkerd, all the managed cloud offerings I know of, and any random Go binary can handle it. What esoteric portions of the spec are you referring to? 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).
- discreteevent 3y ago
  > perfect engineering 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.

They do have meaning, but the meaning is orthogonal from metrics like total use throughout an industry: https://github.com/cncf/toc/blob/main/process/graduation_criteria.md#graduation-stage https://github.com/cncf/toc/blob/main/process/graduation_cri... There is little doubt in my mind that gRPC is a larger and more impactful project than Istio.

sdesol 3y ago

Here's the insights for grpc https://devboard.gitsense.com/grpc/grpc https://devboard.gitsense.com/grpc/grpc They are attracting less people than istio but not by much. Full disclosure: This is my tool

verst 3y ago
The CNCF has their own tool - a Grafana dashboard for all their projects: https://devstats.cncf.io https://devstats.cncf.io A bit awkward to use but lots of great info there. I use it every now and then (I'm a maintainer of Dapr).
- sdesol 3y ago
  Yeah I was aware of devstats and yes the UI is awkward to use. I'm planning on open sourcing DevBoard, since GitSense is really the differentiating factor, so CNCF is free to use it, if it wants to. I personally think Grafana is great for analyzing time series data but I don't believe it's a very good dashboard system if you need to tell a story, which is what I believe software development insights needs. If you goto to https://devboard.gitsense.com/dapr/dapr?board=gitsense_examples.intro_to_widgets 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.

qbasic_forever 3y ago

IMHO that's accurate for grpc. The project works great if you're all golang on backend. As soon as you use other languages it gets complicated and the story falls apart--you almost certainly have to pull in tooling to manage protobuf generation, and proxying your grpc backend code to web frontend code (easy if your backend is golang, but many more options and questions if not). The fact grpc (and protobufs in general) need so much extra tooling is a bit of a code smell of immaturity and incubation IMHO.

pjmlp 3y ago
.NET tooling is quite good, although I have only used it in toy examples.
- akshayshah 3y ago
  It's maintained by James Newton-King, so it's in the hands of .NET royalty :) 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.
  - pjmlp 3y ago
    Even if I only briefly used it, I wish they had the same love for the COM tooling, after 30 years, Visual Studio still can't offer an IDL editing experience similar to editing proto files. Maybe it is about time to gRPC Windows. :)
- jayd16 3y ago
  +1 for gRPC for .NET. Its quite nice _except_ on macos. I forget the exact issue but there's some extra friction to hosting https locally on macos that makes the dev flow a lot more cumbersome.
  - 3y ago

akshayshah 3y ago

gRPC had a graduation application open for 3 years. It was rejected very recently: https://github.com/cncf/toc/pull/300 https://github.com/cncf/toc/pull/300. 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.

bushbaba 3y ago
100% this. GRPC has nearly all its code contributions by google. If google removed its funding the project would be at risk. It’s closer to a proprietary offering with source code available than a mature FOSS ecosystem. Think redhat enterprise Linux is to gRPC where-as istio/k8s is closer to Debian.
evntdrvn 3y ago
It’s really hard to have any influence on it unless you’re inside the Google fence. Even for the primary maintainers of those two external parties that you mentioned.
tgma 3y ago
You acknowledge contributions from several large companies. It's obvious it won't go away if Google pulls support or anything. Perhaps the fact that some random folks across the internet don't feel compelled to submit patches is simply due to the low level nature of the project and that it does the job quite well and its scope is limited by its nature, thereby limiting the need for customization by every individual. I really wonder what the standard is. If I recall correctly, for instance a certain proxy graduated by CNCF was such crap at one point that it linear searched routes. That naturally necessitates contributions if you actually use such software in production at scale.
havnagiggle 3y ago

arein3 3y ago

Hopefully grpc will never graduate as to not encourage people to use it. There are better ways.

hardwaresofton 3y ago
c'mon, you gotta at least drop some of the "better ways" you prefer.
- devmunchies 3y ago
  I prefer another CNCF incubating project, NATS. (nats.io) 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.
  - dilyevsky 3y ago
    There's a proto service implementation from NATS folks that I think does what you want - https://github.com/nats-rpc/nrpc https://github.com/nats-rpc/nrpc
    - devmunchies 3y ago
      Nice! We don’t use Go though :) we use F#, Rust, and C. Would love to see this work supported by the core Nats team. A standard spec so others could make clients.
  - FridgeSeal 3y ago
    Nats is a message bus/queue though, which is different from the serialisation format and rpc framework offered by protobufs +grpc. I love a good queue, but these are “orthogonal” to borrow a favourite HN term.

throwawaaarrgh 3y ago

Some of Google Cloud's critical APIs only seem to use gRPC over HTTPS. It relies on such an esoteric part of the TLS specification that many (most?) proxies can't carry the traffic. You end up hunting for 2 days to find out why your connections don't work only to realize they probably never will. So I would say it's good that gRPC isn't being pushed hard yet. 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.

akshayshah 3y ago
I've never encountered a proxy that can't do the portions of TLS 1.3 that gRPC requires - NGINX, Envoy, linkerd, all the managed cloud offerings I know of, and any random Go binary can handle it. What esoteric portions of the spec are you referring to? 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).
discreteevent 3y ago
> perfect engineering 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.