Carlos Noronha

Introduction

As web applications grow and adopt microservice-based architectures, communication between services becomes a critical aspect. Traditionally, this is done via REST APIs, which are simple and widely supported. However, REST might not be the best fit when performance, security, and scalability become top priorities.

This is where gRPC comes in — a modern, high-performance framework for inter-service communication. Backed by HTTP/2 and Protocol Buffers (protobuf), gRPC is now widely adopted by companies like Google, Netflix, and Dropbox.

In this article, we'll explore what gRPC is, its main features, pros and cons, and how it fits into the Node.js ecosystem using the NestJS framework.

What is gRPC?

gRPC (gRPC Remote Procedure Call) is an open-source framework created by Google to simplify communication between distributed systems. It allows applications to communicate quickly and efficiently using remote procedure calls (RPCs), relying on HTTP/2 for transport and Protocol Buffers for data serialization.

Key features:

Contract-based: Interfaces are defined in '.proto' files, ensuring strong typing and automatic validation.
High performance: Protobufs significantly reduce message size and boost serialization speed compared to REST/JSON.
Multiple call types: Unary, Server Streaming, Client Streaming, and Bidirectional Streaming.
Cross-language support: Services can be implemented in different languages as long as they share the same '.proto' contract.
Native TLS support: Secure communication out of the box.

Pros and Cons of gRPC

✅ Advantages

High performance: Protobufs are extremely efficient for data serialization.
Strong typing: '.proto' contracts prevent many common integration errors.
Built-in streaming support: Ideal for real-time data and IoT.
Great for internal communication: Perfect when you control both client and server environments.

⚠️ Disadvantages

Steeper learning curve: If you're used to REST, gRPC might feel overwhelming at first. I struggled a lot when learning it – configuring '.proto' files and code generation definitely takes some getting used to. 😅
Poor browser support: Browsers don't support HTTP/2 + Protobuf natively. gRPC-Web is a workaround, but requires extra setup like a reverse proxy.
Harder to debug: Unlike JSON, protobuf messages aren't human-readable. Tools like Postman or Insomnia don't help much here. I've had to log hex dumps just to understand what was going wrong.
Less intuitive error handling: gRPC uses its own set of status codes like 'INVALID_ARGUMENT' or 'NOT_FOUND', which don't directly map to HTTP codes. I once spent hours debugging a vague 'INTERNAL' error, only to realize I missed a required field in the request. 🤦

Use Case: E-commerce with gRPC Communication

Let's consider a practical example of using gRPC in a microservices architecture. In this scenario, we have two services that need to communicate efficiently without exposing internal details to the client.

📂 catalog-service (REST)

Exposes product information via HTTP to the frontend.
Returns data like name, description, price, and availability.

📋 inventory-service (gRPC)

Maintains stock data.
Exposes gRPC methods like CheckStock to verify quantity in real time.

When a user accesses /products route, the catalog-service fetches base product info and then queries the inventory-service via gRPC to get the current stock. This ensures the product availability is always accurate, without exposing the gRPC details to the client.

This architecture is great for keeping internal services efficient and modular while still exposing a clean REST interface externally.

Implementation Example

I built a simple demo that puts this idea into practice. The project is available on my GitHub: betonr/nodejs-nest-grpc

Catalog Service: REST API that serves product information to clients
Inventory Service: gRPC service that maintains real-time stock information

Architecture Overview

🔁 How It Works

Client makes an HTTP request to the Catalog Service
Catalog Service retrieves base product data from its database
Catalog Service calls Inventory Service via gRPC for stock information
Response is combined and returned to the client

This architecture provides several benefits:

Separation of concerns between product data and inventory management
Efficient internal communication using gRPC
Clean REST API for external clients
Real-time stock information without exposing internal service details

📦 Service Responsibilities

Catalog Service (REST API)

Exposes endpoints like /products and /products/:id
Maintains product data (name, description, price)
Acts as a gRPC client to the Inventory Service
Combines product data with stock info
Handles gRPC unavailability and errors gracefully

Inventory Service (gRPC)

Exposes gRPC methods like CheckStock
Maintains real-time inventory data
Returns stock quantity and availability

📄 Protocol Buffer Definition

This is the shared contract between services (inventory.proto):

syntax = "proto3";

package inventory;

service InventoryService {
  rpc CheckStock (CheckStockRequest) returns (StockResponse) {}
}

message CheckStockRequest {
  string productId = 1;
}

message StockResponse {
  string productId = 1;
  int32 quantity = 2;
  bool inStock = 3;
}

For more technical details and to try it yourself, check out the full project on GitHub: betonr/nodejs-nest-grpc

Microservice Communication with gRPC in Node.js using NestJS