Build gRPC Services in Node.js with @grpc/grpc-js (2026)

The most surprising thing about gRPC services in Node.js is how effortlessly they can achieve performance parity with compiled languages.

Let’s see it in action. Imagine we have a simple Greeter service defined in Protocol Buffers:

// greeter.proto
syntax = "proto3";

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

First, we generate the Node.js code using grpc_tools:

npx grpc_tools_node_protoc \
  --js_out=import_style=commonjs,binary:./generated \
  --grpc_out=grpc_js:./generated \
  greeter.proto

This creates generated/greeter_grpc_pb.js and generated/greeter_pb.js.

Now, let’s build a basic server:

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

const PROTO_PATH = path.resolve(__dirname, './greeter.proto');

const packageDefinition = protoLoader.loadSync(PROTO_PATH, {
  keepCase: true,
  longs: String,
  enums: String,
  defaults: true,
  oneofs: true,
});

const protoDescriptor = grpc.loadPackageDefinition(packageDefinition).greeter;

const server = new grpc.Server();

server.addService(protoDescriptor.Greeter.service, {
  sayHello: (call, callback) => {
    callback(null, { message: `Hello ${call.request.name}` });
  },
});

server.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), () => {
  server.start();
  console.log('Greeter server running at 0.0.0.0:50051');
});

And a client to interact with it:

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

const PROTO_PATH = path.resolve(__dirname, './greeter.proto');

const packageDefinition = protoLoader.loadSync(PROTO_PATH, {
  keepCase: true,
  longs: String,
  enums: String,
  defaults: true,
  oneofs: true,
});

const protoDescriptor = grpc.loadPackageDefinition(packageDefinition).greeter;

const client = new protoDescriptor.Greeter('localhost:50051', grpc.credentials.createInsecure());

client.sayHello({ name: 'World' }, (error, response) => {
  if (error) {
    console.error('Error:', error);
  } else {
    console.log('Greeting:', response.message);
  }
});

Run node server.js and then node client.js. You’ll see "Greeting: Hello World" printed by the client.

The core problem gRPC solves is efficient inter-service communication, especially in microservice architectures. Traditional REST APIs, often using JSON over HTTP/1.1, involve verbose serialization, text-based protocols, and overhead from HTTP headers. gRPC, on the other hand, utilizes Protocol Buffers (protobuf) for highly efficient binary serialization and HTTP/2 for multiplexing, header compression, and bi-directional streaming. This results in significantly smaller payloads, lower latency, and higher throughput.

Internally, @grpc/grpc-js is a pure JavaScript implementation of the gRPC core library. It interfaces with Node.js’s native http2 module to handle the transport layer. When you define your service in .proto files, protobuf compilers translate them into JavaScript classes for your request and response messages. The grpc.loadPackageDefinition function and the generated _grpc_pb.js files provide the necessary glue to register your service methods on the server and create client stubs for making remote calls. The call object on the server contains the incoming request, and the callback function is how you send the response back. On the client, the client.sayHello method, generated from the .proto definition, handles serializing the request, sending it over the wire, and deserializing the response.

The grpc.ServerCredentials.createInsecure() and grpc.credentials.createInsecure() are crucial for development and testing, but for production, you must use grpc.ServerCredentials.createSsl() and grpc.credentials.createSsl() with proper TLS certificates. This ensures secure, encrypted communication between your services.

The single most impactful configuration for performance tuning lies in how you handle keepAlive and maxConcurrentStreams on the underlying HTTP/2 connections. While not directly exposed as simple parameters on the grpc.Server or grpc.Client constructors, these are managed by the http2 module and can be influenced through options passed during channel creation or server binding. For instance, setting keepAlive: true and keepAliveTimeout: 30000 on the client-side channel can significantly reduce latency for subsequent requests to the same server by reusing established connections, but excessively aggressive keep-alive settings can consume more resources than necessary.

The next hurdle you’ll likely face is implementing more advanced gRPC features like client-side load balancing or understanding the nuances of stream cancellation.