Transform gRPC gateway into RESTful APIs and make them accessible to the global REST community.
Gateway gRPC
Performance is undoubtedly crucial when creating a contemporary microservice architecture. An additional millisecond matters greatly in inter-service communication, even in scenarios not related to high-frequency trading or near-real-time systems, to improve the overall user experience. Due to its robust typing, low latency, and effective serialization, gRPC has become a popular high-performance communication protocol in this setting.
HTTP API
However, they must also admit that HTTP APIs continue to play a major role in the majority of inter-service connections across system boundaries. This is because converting APIs to gRPC would generate a great deal of friction since they essentially function as a contract between disconnected entities, such as API providers and consumers. Furthermore, not every developer has the necessary skills or knowledge to use gRPC services. Thus, API providers that restricted their exposure to gRPC services alone run the risk of losing out on a potential audience.
Google Cloud show in this blog post how to quickly and simply connect the highly-efficient gRPC services with the extensively used RESTful HTTP API environment. In order to manage the protocol translation that will provide an HTTP interface, they suggest a strategy that makes use of an automatically created gRPC gateway that can be installed alongside the current gRPC service. In conclusion, they present Apigee as the platform for managing corporate APIs, which allows for the safe and self-service exposure of a clear RESTful API façade.
gRPC-to-HTTP gateway
Assume for the moment that a fictional firm running an online store came to the realization that some of the parts may stand alone as valuable assets and be included into their strategic API economy initiatives. The microservices architecture on which their example is built consists of many sub-components written in various programming languages. The currency service is the first feature they want to investigate when onboarding users to their API platform. It offers two gRPC methods that enable clients to convert currencies between different ones and list the supported currencies.
gRPC services are a common option for internal or so-called “east-west” service-to-service connections, as was indicated in the introduction. Even though gRPC has better performance characteristics, HTTP is still the main communication protocol used by a large number of APIs. It would take a significant financial commitment to convert these APIs to gRPC, especially because not all developers are conversant with the gRPC framework.
Google Cloud want to build an adaptor layer that offers a more conventional JSON HTTP-based API for the service in order to get around this problem. They chose to utilize the open-source gRPC gateway project to automatically produce an adapter for their use case rather than doing the protocol translation ourselves.
The.proto file, which lists the services and messages, serves as the foundation for the gateway. It acts as the only reliable source of information or contract between customers and service providers. They developed a convenience wrapper that enables us to produce the gRPC gateway simply passing it a reference to the.proto file, making the process of creating the gRPC gateway simpler.
./generate-gateway.sh --proto-path ./examples/currency.proto
The aforementioned code creates the go module for converting an incoming HTTP REST request to gRPC and sends it to the designated endpoint after parsing the provided.proto file. Ultimately, it encapsulates the gRPC gateway inside a go module that is self-deploying.
API Proxy Server
They should create a container image for the finished architecture and deploy it to a target runtime like Cloud Run. They may also run the gRPC gateway locally to learn how it functions:
(cd generated/gateway && docker build . -t gateway:latest)
docker run -p 8080:8080 -e GRPC_SERVER_ENDPOINT=localhost:9090 gateway:latest
Here, the gRPC endpoint that the gateway should use to route traffic is indicated by the GRPC_SERVER_ENDPOINT environment variable. In this instance, the local gRPC currency service is already up and operating on port 9090. You may now make a standard JSON HTTP request to the gRPC gateway‘s endpoint once it has been started:
curl -X POST localhost:8080/hipstershop.CurrencyService/Convert -d '{"from": {"units": 3, "currency_code": "USD", "nanos": 0}, "to_code": "CHF"}'As you can see, they’ve released their gRPC currency service as a JSON HTTP API, which may be more user-friendly and integrated into a larger API ecosystem. When they take into account how this new API fits with the business’s well-established API strategy, there is still space for improvement:
- The API retains much of the original’s structure while deviating from the generally recognized RESTful API design guidelines.prototype guidelines.
- Features related to API administration, like error handling, centralized logging and monitoring, authentication, and monetization, are not supported by the API.
- There is no self-service alternative available to developers to help them find new APIs and register as API users.
API Proxy
They may use an Apigee API Proxy façade as an API management layer to accomplish some of these goals and eventually increase API adoption. Although Apigee is capable of exposing gRPC services in pass-through mode natively, in this case, they are using the previously converted protocol, which enables us to apply a variety of helpful settings and rules for:
- Translations of the method, path, and payload that enable us to provide a suitable RESTful façade and abstract the underlying gRPC message format.
- Metrics and rich analytics data gathering to assess the API program’s operational effectiveness and success.
- Enforcing traffic management, error handling, and consistent API security to safeguard other systems and enforce client quotas.
Reduce obstacles to entry with API management
In order to safely access their gRPC gateway and build upon it, they must first get the API proxy. This proxy can be deployed to Cloud Run, where Cloud IAM may be used to enforce authentication. Their API proxy has to be set up to either utilise Google Cloud authentication directly or pass along the credentials obtained from the API client in order to comply with this security measure.
Google Cloud can expose a RESTful path to API consumers and rebuild the path at runtime to match what their gRPC gateway expects thanks to Apigee’s thorough and flexible approach to managing routes with an API proxy.
curl -X POST "https://$APIGEE_HOSTNAME/currency/v1/convert" -d '{"from": {"units": 3, "currency_code": "USD", "nanos": 0}, "to_code": "CHF"}'When they use an Apigee API proxy to proxy their currency service, analytics and API metrics are automatically collected, giving us valuable information about the performance and health of their APIs. By adding more traffic management, security, mediation, and even code extension rules, Google Cloud may further enhance their API proxy.
Google Cloud may publish an API product on Apigee’s developer portal so that developers can find, use, and experiment with the API, creating new possibilities, and introducing and promoting this API to a new audience. To expand on this further, they may choose monetize an API product to open up new income streams via a range of alternative approaches, such subscription plans or usage-based pricing.
Final thoughts and future actions
Ultimately, they have shown how gRPC services may be simply made available to new users via HTTP APIs, all the while using the advantages of an all-inclusive API management platform such as Apigee. Google Cloud can expand the reach of their services and data to a larger developer and application community by fusing the efficiency of gRPC with the familiarity and tools of REST APIs. They can bridge the gap between gRPC gateway and REST when developing an API ecosystem by adopting this hybrid method, allowing you to take use of the greatest features from both perspectives.
