Here are some frequently asked questions. Hope you find your answer in here :-)
gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. It enables client and server applications to communicate transparently, and makes it easier to build connected systems.
Read the longer Motivation & Design Principles post for background on why we created gRPC.
gRPC Remote Procedure Calls, of course!
The main usage scenarios:
gRPC is a CNCF project.
Google has been using a lot of the underlying technologies and concepts in gRPC for a long time. The current implementation is being used in several of Google’s cloud products and Google externally facing APIs. It is also being used by Square, Netflix, CoreOS, Docker, Cockroachdb, Cisco, Juniper Networks and many other organizations and individuals.
C++, Java, Objective-C, Python, Ruby, Go, C#, Node.js. All of the above mentioned languages are now in GA and follow semantic versioning.
Java implementation supports Android and Objective-C is targeted at iOS and are also at 1.0 now.
All implementations are licensed under Apache 2.0.
Contributors are highly welcome and the repositories are hosted on GitHub. We look forward to community feedback, additions and bugs. Both individual contributors and corporate contributors need to sign our CLA. If you have ideas for a project around gRPC, please read guidelines and submit here. We have a growing list of projects under gRPC Ecosystem
Check out the documentation right here on grpc.io.
The gRPC project has an RFC process, through which new features are designed and approved for implementation. They are tracked in this repository.
The latest release branch is v1.10.x
The gRPC project does not do LTS releases. Given the rolling release model above, we support the current, latest release and the release prior to that. Support here means bug fixes and security fixes.
The gRPC project works in a model where the tip of the master branch is stable at all times. The project (across the various runtimes) targets to ship checkpoint releases every 6 weeks on a best effort basis. If for some reason, a release is skipped by a particular runtime, we may opt to skip that release altogether, and ship the next release, along with the other runtimes and catch up.
Yes. gRPC is designed to be extensible to support multiple content types. The initial release contains support for Protobuf and with external support for other content types such as FlatBuffers and Thrift, at varying levels of maturity.
gRPC and Protobuf provide an easy way to precisely define a service and auto generate reliable client libraries for iOS, Android and the servers providing the back end. The clients can take advantage of advanced streaming and connection features which help save bandwidth, do more over fewer TCP connections and save CPU usage and battery life.
This is largely what gRPC is on the wire. However gRPC is also a set of libraries that will provide higher-level features consistently across platforms that common HTTP libraries typically do not. Examples of such features include:
gRPC largely follows HTTP semantics over HTTP/2 but we explicitly allow for full-duplex streaming. We diverge from typical REST conventions as we use static paths for performance reasons during call dispatch as parsing call parameters from paths, query parameters and payload body adds latency and complexity. We have also formalized a set of errors that we believe are more directly applicable to API use cases than the HTTP status codes.