Microservices: How to choose right API style that fits to your Solution Requirements gRPC over Restful
Hello Welcome to this post!
An effective API design is vital in a Microservices architecture because all data exchange between services happens either through messages or API calls. REST style is probably the most known as it has become common among the Web API. But lately, the gRPC framework is becoming quite popular to build high performance systems. So, you might get these questions when involving in designing an API architecture.
In this post, you would be able to find answers and to understand the capabilities of gRPC framework, features of Protobuf and HTTP/2 protocol and finally overview of common use cases of gRPC over REST API. so, let's keep reading further for technical insights.
REST: a brief overview
Before we start looking into details of the gRPC framework,
let’s take a brief overview of RESTful services first.
- The standard REST methods built on HTTP 1.x. with well-defined status codes help in identifying cause of problems. Generated contracts, messages and JSON responses are human readable.
- There
are tools for inspection, modification, testing is readily available in
the market and there are a lot of frameworks in most of the widely used
languages to create RESTful API’s.
- REST
enforces stateless communication, which improves scalability. And loosely
coupling between client and server makes changes relatively easy.
In a nutshell, REST is a very efficient, effective, and powerful solution for the modern microservice API industry. Now, let’s have a look briefly what gRPC service is,
 |
What are gRPC services?
- gRPC
is actually a new take on an old approach known as RPC, or Remote
Procedure Call from Google.
- RPC is
a method for executing a procedure on a remote server, somewhat like
running a program on a friend’s machine that far away from your
workstation.
- gRPC
framework is now an open-source project available originally developed by
Google. The framework runs over the newer HTTP/2 protocol and exchanges
data in binary format with Protobuf.
So, “When to choose the gRPC STYLE architecture over HTTP-based REST API?”. In order to find an answer to this question, let's first understand What is the concrete result of designing and deploying a gRPC based APIs?
Here are the major benefits of the gRPC framework.
- gRPC
improves Performance because, Messages are serialized using
Google’s Protobuf, which is a lightweight and an efficient binary message
format. In fact, a gRPC message is always smaller than an equivalent JSON
message.
- The gRPC
framework is designed for HTTP/2 protocol that provides
significant performance over HTTP/1 version because it leverages the
low-level capabilities of HTTP/2.
 |
- Duplex streaming to send data in both directions at the same time, i.e. you can have two threads, one for writing data and another one for reading data, executing concurrently.
- Multiplexing
that allows the client to communicate to the server by making another
request on the same TCP connection.
As a result, these are turning a gRPC communication into a
sort of superfast messaging.
Next thing is, Integrated authentication,
Yes, gRPC has a very effective and powerful authentication system either you
can use SSL/TLS authentication or token-based with oAUTH model. Or even you can
plug in your own AUTH system by extending the code as well.
Another major benefit is, gRPC framework saves
development time by different ways, let’s see what those are,
 |
- Auto
code generation, in a typical development scenario, you used to
generate a client from the endpoint/WSDL. In case there are multiple
services exist then client’s generation will become a tedious task. But
gRPC frameworks provide first-class support for code generation. A core
file to gRPC development is the .proto file, in which gRPC frameworks
define the contract of gRPC services and messages. From this file, the
gRPC frameworks will generate a service base class, messages, and a
strongly-typed client. So, by sharing the proto file between server and
client, you can generate the messages and client code easily.
- Strict specification, a formal specification for HTTP API with JSON does not exist, so developers usually debate the best format of endpoints, HTTP verbs and response codes. Whereas the gRPC specification is prescriptive about the format a gRPC service must follow. So that developers can refer and follow in development because gRPC is consistent across platforms and implementations.
- Polyglot environments, you can develop the gRPC services using any of popular programming languages: from Java to Python, to PHP, to C# and so on without worrying about your team’s skill sets.
Let’s see how gRPC handles an efficient Point-to-point
real-time communication,
- gRPC supports Unary, Client to Server, Server to Client and Bi-directional streaming combinations. With REST style you can stream only from client to server.
- You can leverage the advanced streaming capabilities of the gRPC framework to make it possible to arrange a bi-directional channel between two endpoints, that way messages can be exchanged in real time without polling. If you want to achieve the same with REST architecture then you need to write multiple distinct requests like a chatty style of streaming, which is against the “Chatty – I/O” anti-design pattern that must be avoided in general.
Ideal Use-cases of gRPC
Let's see some of the ideal scenarios for your
understanding here, please note this is not an extensive list and there could
be a lot more possible real time use cases.
- When you build multiple microservices with different technologies and programming languages, because the framework creates auto-generated classes across languages which makes it very easy to get started.
- For back-end microservice-to-microservice communication with high load of data because you can leverage a binary protocol (Protobuf) over HTTP/2 rather using a conventional text-based messaging (JSON, XML, CVS over HTTP) protocol. With bi-directional communication, duplex streaming, and multiplexing, you can realistically increase the performance of every single call by at least a few milliseconds, especially in applications with heavy loads where every bit counts, it could really make a difference.
- When design a secured architecture with Google’s integrated authentication model (i.e. SSL or oAUTH Token) for device-to-device and device-to-cloud communications.
- When a system requires a set amount of data or processing routinely, and in which the Requester is low power. e.g. IoT applications. And, for low latency/ bandwidth data transfer in M2M communication, especially when the client and servers are done in different languages.
- For mobile and desktop applications because you can precisely define a service and auto generate reliable client libraries for iOS, Android using gRPC framework and Protobuf. The clients can take advantage of advanced streaming and connection features which help save bandwidth, CPU usage and battery life.
- But, preferably not for Web UI based applications because web browsers does not fully support HTTP/2 features for now, so browsers can’t directly call a gRPC service, alternatively to overcome this, you should create one external facing Microservice using REST for the internal gRPC services as shown in below diagram.
To conclude
After seeing the features of gRPC framework and Protobuf benefits, now you might have understood when to choose the gRPC style that fits for your business or solution requirements. On a high level, we can conclude as that,
- Multiplexing, full-duplex, and proto request / responses make gRPC much faster as compared to REST. It is only available for internal services because there are no APIs available for external use until gRPC-web evolves fully, so as shown in the above diagram the GRPC style API design should be great for communications between internal microservices where low latency and high throughput communication are critical.
- Other synchronous messaging technologies such as RESTful services and GraphQL should be more suitable for external-facing services.
As a final note
Happy learning!!
Comments