Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
gRPC graduation application #300
@srini100 thanks for this proposal.
In terms of impact and production use, gRPC clearly qualifies for graduation from my perspective. I have a few questions about governance and language support however:
@mattklein123, thanks for your review and questions. Please see my responses below:
gRPC governance process is described here. This was recently updated to have a well defined process for anyone to become a maintainer if they meet the described criteria (similar to other OSS projects). We are already making use of this new process to consider the request from a contributor from Skyscanner to become a maintainer of gRPC Core repo. We hope this will encourage more gRPC users to consider becoming maintainers. Over the years, many large contributions from different companies have been accepted.
The design and feature proposals are done on Github via the gRFC process which has been in place since Jan’17. Over 80 proposals have been made since then. Sometimes the initial ask may come from a user on another forum and one of the maintainers will work with them and make a proposal. Some examples of input from non-Google contributors are Service Config in DNS, C++ wrapping, custom transports and Interceptors in C#, NodeJS and Ruby. Most recently, Skyscanner, Dropbox and Google have been collaborating on Python Asyncio gRFC. This is a good example where a new set of APIs and features in gRPC Core repo are being driven by companies other than Google. Some PRs (1, 2, 3) are already merged. Other example PRs are public resolver API in gRPC Core and SSL session caching. So yes, if a non-Google contributor shows expertise, motivation and commitment and there are other non-Google reviewers with sufficient expertise, Google consent is not required. But, given the large number of committers from Google, it is natural that someone from Google will help with the reviews and influence the design and implementation.
Regarding the adoption of xDS APIs, the intention to move to xDS was announced on grpcio and in a gRFC proposal. The decision was based on user friction with the existing gRPC LB solution that was suffering from being proprietary and lacking open source control plane implementation. This enables a better ecosystem play for gRPC with other CNCF and open source projects and reduces dependence on Google for driving the roadmap.
It is well known that gRPC and protobuf go together very well but gRPC is designed to work with other IDLs and serialization formats and similarly protobuf can be used with other communication protocols too. We take extra care in not taking a dependency on protobuf in gRPC core (example) and keeping gRPC independent of protobuf. We published a blog to show how easy it is to use JSON with gRPC. Microsoft has also published their serialization protocol Bond over gRPC.
Regarding the governance, these are treated as independent projects. Committers/maintainers are different and have good cordial relationship. Just like gRPC has interaction with Netty and now with Envoy Data Plane APIs, it has interaction with Protocol Buffers. Most of the user friction with protobuf is unfortunately around protobuf tooling which is outside the scope of gRPC project. gRPC & Protobuf teams acknowledge the user pain. Protobuf related tools is a great place to start community contributions. It is orthogonal to gRPC project, but as a part of Protobuf community efforts, the idea of starting community efforts to improve protobuf tooling is very appealing.
Besides C++, Java and Go, Google maintainers are also fully supporting Python, Ruby, Node, ObjectiveC, C# and PHP. All these languages are on par with core languages in terms of features and version releases. This shows that Google is committed to supporting more languages than just the core languages, but of course, Google maintainers themselves cannot develop gRPC for a number of other languages that the community is interested in. To have gRPC available in more languages, we rely on community contributions which do not require Google consent. For example, gRPC-Swift is being jointly developed by Apple, Lyft, Timing and Google. Currently, it relies on gRPC C-core but soon it will move to Swift-NIO based stack for production readiness. gRPC-Dotnet is another example where contributions from Microsoft has enabled production use of gRPC in ASP.NET Core. This was announced in .NET Conf recently. Even for existing languages, we are happy to accept large community contributions like the Python Ayncio I mentioned above and Interceptors in C#, NodeJS and Ruby. For a language support to go GA we will ensure that it passes interop tests with other implementations and a sustainable test infrastructure is available for long term support.
I am happy to help on the DD. Usually the project owners + the CNCF SIG will make a draft. And the TOC member will give it a review, and "approve" it. If everything is OK, the voting process will begin.
The DD template is here: https://github.com/cncf/toc/blob/master/process/dd-review-template.md
Here are some recent DD examples: