backend-basic-concepts

Exploring gRPC: A practical guide in nodejs

5 min read
#backend-basic-concepts

gRPC, short for Google Remote Procedure Call, is a high-performance framework built on HTTP/2 that has redefined how applications communicate in distributed systems. Its unique ability to leverage HTTP/2’s features like bidirectional streaming, multiplexing, and binary framing makes it a popular choice among developers. Combined with Protocol Buffers for efficient and compact data serialization, gRPC stands out as a modern solution for client-server communication across multiple languages.

Why gRPC?

To understand why gRPC is so popular, let’s look at the problems with older ways of connecting systems and how gRPC solves them effectively.

The Problem with Existing Protocols

  1. Client Libraries Every communication protocol (e.g., REST, GraphQL) requires both the client and server to use a compatible implementation. This necessitates client libraries tailored to each protocol and language combination.

    • Maintenance Overhead: Maintaining protocol-specific libraries across different programming languages can be cumbersome. For instance:
      • SOAP libraries exist for Java, .NET, Python, etc., but their feature sets and updates may not align consistently.
      • Developers need to manually update libraries to patch vulnerabilities, add features, or ensure compatibility.
    • Versioning Conflicts: As protocols evolve, library versions may lag behind or introduce breaking changes, causing compatibility issues between the client and server.

  2. Inconsistent Support Across Languages While some protocols are language-agnostic, their implementation is often not uniform. For example:

    • SOAP and REST might have robust support in Java or .NET but limited or less optimized support in niche languages.
    • Newer protocols like GraphQL rely heavily on specific tools, which may not exist for all languages.

gRPC to the Rescue

gRPC was designed to solve these challenges by introducing a unified framework built around modern principles like HTTP/2 and Protocol Buffers. Here's how it addresses the issues:

  1. A Unified Client Library gRPC provides a single client library for each language that handles all protocol communication.

    • Simplifies Maintenance: Instead of multiple protocol-specific libraries, developers only need to manage a single gRPC library for their language of choice.
    • Streamlined Updates: Updates to the gRPC library are consistent across all supported languages, ensuring compatibility without breaking functionality.
    • Example: A team using Python, Go, and Java can rely on gRPC’s language-specific stubs generated from the same .proto file. These stubs handle all the details of communication, making it seamless for developers.

  2. Compact, Schema-Based Data Serialization gRPC uses Protocol Buffers (Protobuf) for defining and serializing data. Protobuf is a highly efficient binary format that minimizes payload size and parsing overhead.

    • Compact Payloads: Protobuf’s binary serialization ensures smaller payloads compared to text-based formats like JSON or XML.
    • Schema-Defined Communication: The .proto file defines the structure of requests and responses, ensuring both client and server strictly adhere to the schema.
    • Backward Compatibility: Protobuf supports schema evolution, allowing fields to be added or deprecated without breaking existing implementations.

  3. Cross-Language Compatibility via Stubs The .proto file serves as a contract that defines the structure of communication. gRPC uses this file to generate language-specific stubs (client and server code) for over a dozen languages, including:

    • Python
    • Java
    • Go
    • Node.js
    • C++
  • Advantages:
  • Language Neutrality: The same .proto file can be used to generate stubs for any supported language.
  • Reduced Developer Effort: Developers don’t have to write communication logic manually. The stubs handle serialization, deserialization, and communication under the hood.
  • Example: A Node.js backend can communicate with a Python client using gRPC without either team worrying about implementation differences.

Building a Simple gRPC Application

  1. Define the .proto File The Protocol Buffer (.proto) file is at the core of gRPC. It defines the service, messages, and methods.
syntax = "proto3";

package todo;

service TodoService {
  rpc CreateTodo (TodoItem) returns (TodoItem);
  rpc ReadTodos (Void) returns (TodoItems);
}

message TodoItem {
  int32 id = 1;
  string text = 2;
}

message TodoItems {
  repeated TodoItem items = 1;
}

message Void {}

  1. Generate Stubs Use the Protocol Buffers compiler (protoc) to generate client and server code in your desired language.

  2. Implement the Server The server-side logic processes requests and sends responses. Here's a snippet using Node.js:

const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');

const packageDef = protoLoader.loadSync('todo.proto');
const grpcObject = grpc.loadPackageDefinition(packageDef);
const todoPackage = grpcObject.todo;

const todos = [];

const server = new grpc.Server();

server.addService(todoPackage.TodoService.service, {
  CreateTodo: (call, callback) => {
    const todo = call.request;
    todo.id = todos.length + 1;
    todos.push(todo);
    callback(null, todo);
  },
  ReadTodos: (_, callback) => {
    callback(null, { items: todos });
  },
});

server.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), () => {
  console.log('Server running at http://0.0.0.0:50051');
  server.start();
});
  1. Implement the Client The client communicates with the server using the stubs generated earlier.
const client = new todoPackage.TodoService('localhost:50051', grpc.credentials.createInsecure());

client.CreateTodo({ text: 'Do laundry' }, (err, response) => {
  if (!err) console.log('Created Todo:', response);
});

client.ReadTodos({}, (err, response) => {
  if (!err) console.log('Todos:', response.items);
});

Pros and Cons of gRPC

  • Pros
    • Efficiency: Compact and fast due to Protocol Buffers and HTTP/2.
    • Cross-Language Compatibility: Supports many programming languages.
    • Streaming: Enables real-time communication with features like bidirectional streaming.
    • Unified Library: Simplifies client and server implementation.
  • Cons
    • Schema-Dependency: Requires managing .proto files.
    • Thick Client Libraries: Potential bugs or vulnerabilities in libraries.
    • No Native Browser Support: Relies on gRPC-Web for browser-based applications.

Conclusion

gRPC is a game-changer for developers working on scalable and efficient client-server communication. With its robust features and language neutrality, it has become a go-to protocol for microservices and real-time applications. While it may have limitations like schema management and lack of browser-native support, its benefits far outweigh the cons for many use cases.