What is grpc?

Getting gRPC Right: An Introduction and Review

by | 19.09.2021 | Engineering

The question of APIs and their best implementation through online websites will always remain a tough nut to crack as the web undergoes scaled changes each year. It’s hard to think that the web was once draped by HTML and PHP alone until CSS and Javascript made introductions to make it more fluid and responsive. But if there is one interesting framework to study about APIs, it’s gRPC.

Originally designed as a framework for implementing RPC APIs via HTTP/2, gRPC is the advanced alternative to build APIs.

What Exactly Is RPC?

A common abbreviation that appears when creating APIs. RPC (Remote Procedure Call) refers to a format of API deployment that uses procedure calls to receive a service from a remote server, resembling a local system communication, accomplished via direct actions that are sent to the server.

Being rather lightweight and reliable, RPC APIs are commonly used by businesses and are often written in various languages. Adopting RPCs across the larger swathes of the internet has still been complicated due to its vulnerability for leaks and attacks.

gRPC: Concepts and History

gRPC is a part of the Cloud Native Computing Foundation Project (CNCF) project and has a long history of being a favourite at Google where it was spearheaded as an alternative to existing online API formats. The company originally envisioned it for its externally facing APIs.

gRPC example network
gRPC example network Source: gRPC

gRPC is a part of the Cloud Native Computing Foundation Project(CNCF) project and has a long history of being a favourite at Google where it was spearheaded as an alternative to existing online API formats. The company originally envisioned it for its externally facing APIs.

gPRC stood out as the sixth project voted in by CNCF’s Technical Oversight Committee (TOC), after a change in license from BSD-3 and a new grant being published to Apache v2.

Learn more about CNCF here:

Some of its native features, components and concepts were well defined even back then, in 2017:-

Service definitions

gRPC mimics the same notion shared by most RPCs i.e., defining a service and specifying the methods that can be called remotely with their parameters and return types. gRPC uses protocol buffers as the primary Interface Definition Language (IDL) for running both service interface and payload messages.

Synchronous vs. asynchronous

Users will find that while most networks are normally asynchronous, it’s more meaningful to start the RPCs without blocking the current thread. Most RPCs aspire call blocks until a response arrives from the server. gRPC removes all these hassles by allowing users to play between synchronous and asynchronous modes.

Deadlines & Timeouts

Users can employ gRPC to define a waiting period for the RPC to complete before termination. On the server side, the server can also be queried to see if a particular RPC has timed out, or configure the time left to complete a particular RPC. gRPC also allows users to do this across all language types for easier compatibility as some language APIs work in terms of timeouts (durations of time), while others use a deadline (a fixed point in time).

Metadata

Metadata information about all RPC calls exist in the mainframe in the form of key-value pairs. gRPC stores the keys as strings and the values as either strings or binary data. This is again all language dependent and is seamlessly taken up by gRPC.

Channels

Channels provide a connection to a gRPC server through a specified host and port and are commonly used when creating a client stub. Clients can specify channel arguments to modify the original behaviour of the system. A channel has state, including connected and idle. This is another key platforming feature where language plays an important role.

grpc API structure
gRPC API structure Source: gRPC

The Duel of RPC and REST

From the get go, it seems clear that RPC stands shoulder to shoulder against REST API formats but it is important to illustrate the exact difference between the two before we go about using them.

Experts agree that gRPC, despite being a younger contender in the industry, has promising features against REST and other formats. Unlike its counterparts, it holds multi-language systems, real-time streaming, most importantly, uses lightweight messaging transmission. gRPC is slowly becoming a preferred choice for cloud native infrastructures since it was designed to remove the numerous challenges of other mainframes, as seen in the previous sections. Google particularly has used the system for its microservice applications, especially for BigQuery, DataWarehouse and Google Cloud.

Multi-language support and a streamlined format for messaging also should attract viewers who want to try another platform for building mobile applications. It’s no surprise that IoT applications are gaining a lot of headway using gRPC since mobile applications hosting the devices don’t even need a browser and can benefit from high processing speeds.

REST API and others for that matter, are still popular due to the time and expanded outreach they’ve had, but can still falter in certain areas.

What gRPC Brings To The Table

gRPC held the main intention of ironing out many of the supposed issues with RPC methods by making a singular framework that is flexible, efficient and compatible with all languages. Here are some of the most professed benefits of using gRPC for API development:-

  1. A standardized format for platforming that allows communication with multiple servers and backends with minimal complications in setting up or deployment.
  2. Compared to conventional methods such as JSON, gRPC employs a lightweight messaging technique, making it less prone to breakdowns and communication issues. This also provides it an edge as a high performance system, even compared to REST API.
  3. gRPC allows for automated code generation across multiple formats including Java, C++, Python, Go, Ruby and so on.
  4. Connection options are plentiful with tremendous support for data streaming using event-driven architectures, server streaming, client streaming and bidirectional streaming.
gRPC Architectural styles
gRPC Architectural styles Source: gRPC

Where gRPC Misses The Mark

Despite the large number of advantages to its name, there are still some areas where gRPC either is overshadowed by its counterparts or needs more polishing.

  1. Due to the overabundance on HTTP/2, it’s not exactly possible to call a gRPC service from a web browser as no browsers can access this framework. This prompts users to use a proxy which can have its own limitations. Proxies can be implemented using a gRPC client by Google(that uses Javascript) or a proxy for TypesScript and Go.
  2. Being a relatively newer format for API creation, finding support for queries and doubts regarding gRPC is far more complicated compared to its peers like GraphQL. While this information gap is sure to fill up as more and more users adopt gRPC, getting answers to the multitude of other issues for setup, processing, maintenance and deployment is likely to deter some from starting with it. Given the open source nature of the format, this issue is only intensified.
  3. Some aspects of the data that is transferred through gRPC still suffers from the complications of additional preprocessing or debugging, caused as a consequence of files being compressed to a binary format which makes them unreadable. Users might prefer formats like XML and JSON that don’t show such problems.
  4. The lack of features and advantages for gRPC via web clients also presents users with a bit of a steep learning curve to master it. This can also be alluded to the vacuum of gRPC experts on the web compared to XML or JSON experts.

Learn more about proxy servers here:

Final Thoughts and Comments

gRPC is still a great tool in one’s arsenal for microservices and API development. It’s particularly a great tool if the goal is to build applications that need real time communication, efficient data streaming, supporting multiple languages or streamlined servers.

That being said, most experts would still weigh the practicalities of using gRPC for microservices. This is mainly due to its unmatched performance and decentralized nature, making it a great contrast to monolithic architectures. It is still a preferred choice for independent services, specifically those that need lightweight architectures and binary formats for communication. Beyond this, the potentials of transmitting multiple concurrent messages without a network overload makes gRPC ideal for microservice-to-microservice communication.

At the end of the day, there isn’t one fix-all solution to a developer’s needs when it comes to microservices and APIs. Knowing what tool to use and where it can be best used is however crucial. So, what are you waiting for? Catch on and connect with the community online and check out the documentation for gRPC for more information.

As always, stay tuned for the next set of articles as we take readers through an exploration of more awesome cloud native tools. Read our previous superb cloud native blog posts here:

CommunityNew

The DevOps Awareness Program

Subscribe to the newsletter

Join 100+ cloud native ethusiasts

#wearep3r

Join the community Slack

Discuss all things Kubernetes, DevOps and Cloud Native

Related articles6

How to clean up disk space occupied by Docker images?

How to clean up disk space occupied by Docker images?

Docker has revolutionised containers even if they weren't the first to walk the path of containerisation. The ease and agility docker provide makes it the preferred engine to explore for any beginner or enterprise looking towards containers. The one problem most of...

Parsing Packages with Porter

Parsing Packages with Porter

Porter works as a containerized tool that helps users to package the elements of any existing application or codebase along with client tools, configuration resources and deployment logic in a single bundle. This bundle can be further moved, exported, shared and distributed with just simple commands.

eBPF – The Next Frontier In Linux (Introduction)

eBPF – The Next Frontier In Linux (Introduction)

The three great giants of the operating system even today are well regarded as Linux, Windows and Mac OS. But when it comes to creating all purpose and open source applications, Linux still takes the reign as a crucial piece of a developer’s toolkit. However, you...

Falco: A Beginner’s Guide

Falco: A Beginner’s Guide

Falco shines through in resolving these issues by detecting and alerting any behaviour that makes Linux system calls. This system of alerting rules is made possible with the use of Sysdig’s filtering expressions to detect potentially suspicious activity. Users can also specify alerts for specific calls, arguments related to the calls and through the properties of the calling process.

Why DevOps Engineers Love Fluentd?

Why DevOps Engineers Love Fluentd?

Fluentd’s main operational forte lies in the exchange of communication and platforming for creating pipelines where log data can be easily transferred from log generators (such as a host or application) to their preferred destinations (data sinks such as Elasticsearch).

Operating On OpenTracing: A Beginner’s Guide

Operating On OpenTracing: A Beginner’s Guide

OpenTracing is a largely ignored variant of the more popular distributed tracing technique, commonly used in microservice architectures. Users may be familiar with the culture of using distributed tracing for profiling and monitoring applications. For the newcomers,...