Cloud Endpoints for gRPC

Google's gRPC is a high-performance, open-source universal RPC framework. A client programme can call methods on a server application on another machine as if it were a local object using gRPC, making it easier to construct distributed applications and services.

Overview:

A client programme can call a method on a server application on another machine as if it were a local object using gRPC, making it easier to construct distributed applications and services. gRPC, like many RPC systems, is built on the concept of creating a service, which includes describing the methods that may be called remotely, as well as their parameters and return types. On the server side, this interface is implemented and a gRPC server is used to process client requests. On the client side, the client has a stub (in some languages referred to as just a client) that provides the same methods as the server.

One of the main advantages of gRPC is that it allows you to build reference documentation for your API using your service settings and API interface definition files. For further information, see the Developer Portal Overview.

API management Endpoints allow API administration using either the Extensible Service Proxy (ESP) or the Extensible Service Proxy V2 (ESPv2).

You may use Endpoints for gRPC to add an API console, monitoring, hosting, tracing, authentication, and more to your gRPC services using Endpoints' API administration features. ESP and ESPv2 also translate RESTful JSON over HTTP into gRPC requests once you define special mapping rules. 

This means you can use Endpoints to administer a gRPC server and use a gRPC or JSON/HTTP client to call its API, allowing you a lot more flexibility and simplicity of interface with other systems.

In any gRPC-supported language, you can establish gRPC services for Endpoints. On the gRPC site, you can learn a lot more about gRPC, including how to create servers and clients using quickstarts and tutorials.

Platforms that are supported:

ESP and ESPv2 are free and open-source projects that you can use in a variety of ways:

• A container in Google Container Registry
• Source code on GitHub

The ESP container can be executed on any of the following platforms:

• Compute Engine with Docker
• Including Google Kubernetes Engine, Compute Engine with Docker, a machine running on Linux or macOS, or another cloud provider.

The ESPv2 container can be run on the following platforms:

• Cloud Run
• Cloud Run for Anthos
• GKE
• Compute Engine
• Kubernetes

Definition and setup of services:

The goal behind gRPC is to provide a service by declaring the methods that may be called remotely, together with their parameters and return types. Protocol buffers are used as the Interface Definition Language (IDL) by default in gRPC to describe both the service interface and the format of the payload messages.

You must provide a service configuration along with the service definition to utilise gRPC with Endpoints. This section configures your service's runtime behaviour, including authentication, API(s) included in the service, HTTP request to gRPC method mappings, and unique Cloud Endpoints settings.

Transcoding:

Transcoding Endpoints provides protocol translation for your gRPC services, enabling clients to communicate with a gRPC service over the ESP or ESPv2 using HTTP/JSON.

Allowing browser clients to communicate with gRPC servers without the need for separate gRPC client libraries is the most typical use case. As part of the service configuration, Endpoints provides a mechanism for mapping HTTP requests to gRPC calls.

Limitations:

Endpoints do not yet support the following gRPC features:

• Compression of the payload
• Other than protocol buffers, any IDL

Furthermore, for GKE, Compute Engine, and Cloud Run, Endpoints only supports gRPC services (Beta). For App Engine environments, Endpoints does not support gRPC services.