I’ve been thinking about how we build services that talk to each other. You know, those little programs that work together to make big things happen. For years, REST has been the go-to method. It’s like sending letters in the mail. But what if there was a faster, more reliable way? A way that feels like a direct phone line instead of postal service.
That’s where gRPC comes in. It’s a different approach to connecting services, and it solves many problems we face with traditional REST APIs. I want to show you how to use it with NestJS, a framework I’ve come to appreciate for building organized applications.
Think about this: when one service needs data from another, why should it wait for a full HTTP request cycle? Why use text-based JSON when we could use a compact binary format? These questions led me down a path of discovery, and I want to share what I found with you.
Let’s start with the basics. gRPC uses something called Protocol Buffers, or Protobuf for short. Instead of writing documentation that says “send a JSON object with these fields,” you write a contract. This contract defines exactly what your service can do and what data it expects.
Here’s what a simple contract looks like:
syntax = "proto3";
package user;
service UserService {
rpc GetUser (GetUserRequest) returns (User) {}
}
message User {
string id = 1;
string email = 2;
string name = 3;
}
message GetUserRequest {
string id = 1;
}This file says: “There’s a UserService with one method called GetUser. Give it a GetUserRequest with an id, and it will give you back a User object.” The numbers next to each field (like string id = 1) are important - they help gRPC pack data efficiently.
Now, here’s the magic part. From this contract file, we can automatically create code. Both the server code that provides the service and the client code that calls it. This means both sides agree on what’s being sent and received. No more guessing about field names or data types.
Have you ever had bugs because one service expected a field called user_name and another sent username? With gRPC, that can’t happen. The contract enforces consistency.
Let’s build a simple service. First, we set up our NestJS project with the right tools:
nest new user-service
cd user-service
npm install @nestjs/microservices @grpc/grpc-jsWe need to tell NestJS about our gRPC service. In our main application file, it might look like this:
import { NestFactory } from '@nestjs/core';
import { MicroserviceOptions, Transport } from '@nestjs/microservices';
import { join } from 'path';
import { AppModule } from './app.module';
async function bootstrap() {
const app = await NestFactory.createMicroservice<MicroserviceOptions>(
AppModule,
{
transport: Transport.GRPC,
options: {
package: 'user',
protoPath: join(__dirname, 'proto/user.proto'),
url: 'localhost:5000',
},
},
);
await app.listen();
}
bootstrap();Notice how we point to our contract file (proto/user.proto). NestJS reads this file and knows what methods to expect. Now let’s create the actual service that handles requests:
import { Controller } from '@nestjs/common';
import { GrpcMethod } from '@nestjs/microservices';
import { User, GetUserRequest } from './generated/user';
@Controller()
export class UserController {
private users = new Map<string, User>();
@GrpcMethod('UserService', 'GetUser')
getUser(data: GetUserRequest): User {
const user = this.users.get(data.id);
if (!user) {
throw new Error('User not found');
}
return user;
}
}The @GrpcMethod decorator tells NestJS: “This method handles the GetUser call from our contract.” The types (GetUserRequest and User) come from code generated from our Protobuf file. This gives us type checking - if we try to return something that doesn’t match the User type, TypeScript will complain.
What about calling this service from another application? That’s where the client comes in. Here’s how you might call our GetUser method:
import { ClientGrpc, ClientProxyFactory, Transport } from '@nestjs/microservices';
import { join } from 'path';
import { Observable } from 'rxjs';
import { UserServiceClient, GetUserRequest, User } from './generated/user';
class UserClient {
private userService: UserServiceClient;
constructor() {
const client: ClientGrpc = ClientProxyFactory.create({
transport: Transport.GRPC,
options: {
package: 'user',
protoPath: join(__dirname, 'proto/user.proto'),
url: 'localhost:5000',
},
});
this.userService = client.getService<UserServiceClient>('UserService');
}
async getUser(id: string): Promise<User> {
const request: GetUserRequest = { id };
return this.userService.getUser(request).toPromise();
}
}The client code also uses the generated types. This means if the service contract changes, our client code will show errors until we fix it. This prevents runtime surprises.
But gRPC offers more than simple request-response patterns. What if you need to send a lot of data, or receive updates over time? That’s where streaming comes in.
Imagine a stock ticker service. Instead of asking “what’s the price now?” every second, you could open a stream and get continuous updates. Here’s how that might look in a contract:
service StockService {
rpc GetPriceUpdates (StockRequest) returns (stream PriceUpdate) {}
}
message StockRequest {
string symbol = 1;
}
message PriceUpdate {
string symbol = 1;
double price = 2;
int64 timestamp = 3;
}The stream keyword before PriceUpdate means “this will send multiple responses.” On the server side, we can implement this using RxJS observables:
@GrpcMethod('StockService', 'GetPriceUpdates')
getPriceUpdates(data: StockRequest): Observable<PriceUpdate> {
return new Observable((observer) => {
// Send price updates every second
const interval = setInterval(() => {
const update: PriceUpdate = {
symbol: data.symbol,
price: Math.random() * 100,
timestamp: Date.now(),
};
observer.next(update);
}, 1000);
// Clean up when client disconnects
return () => clearInterval(interval);
});
}The client can then listen to this stream:
const updates = stockService.getPriceUpdates({ symbol: 'AAPL' });
updates.subscribe({
next: (update: PriceUpdate) => {
console.log(`Price: ${update.price}`);
},
error: (err) => {
console.error('Stream error:', err);
},
});This pattern is perfect for real-time applications. Chat systems, live dashboards, notification services - all can benefit from streaming.
But what about errors? In REST, we use HTTP status codes. In gRPC, we have a different system. gRPC uses status codes that are more detailed than HTTP codes. Here’s how you might handle errors:
@GrpcMethod('UserService', 'GetUser')
getUser(data: GetUserRequest): User {
const user = this.users.get(data.id);
if (!user) {
throw new RpcException({
code: Status.NOT_FOUND,
message: `User ${data.id} not found`,
});
}
return user;
}The client can catch these errors:
try {
const user = await userService.getUser(request).toPromise();
} catch (error) {
if (error.code === Status.NOT_FOUND) {
console.log('User was not found');
}
}This error handling is consistent across all gRPC services, regardless of what language they’re written in.
Security is another important consideration. You don’t want just anyone calling your services. gRPC supports several authentication methods. One common approach is using metadata, which is like HTTP headers:
// Client side
const metadata = new Metadata();
metadata.add('authorization', `Bearer ${token}`);
userService.getUser(request, metadata).subscribe(...);
// Server side
@GrpcMethod('UserService', 'GetUser')
@UseGuards(AuthGuard)
getUser(data: GetUserRequest): User {
// User is authenticated
}You can create guards that check this metadata, similar to how you’d protect REST endpoints.
Testing gRPC services requires a different approach than testing REST APIs. Since gRPC is binary, you can’t just use curl. But NestJS provides testing utilities:
describe('UserService', () => {
let client: ClientGrpc;
beforeAll(async () => {
const module = await Test.createTestingModule({
imports: [UserModule],
}).compile();
const app = module.createNestMicroservice({
transport: Transport.GRPC,
options: {
package: 'user',
protoPath: join(__dirname, '../proto/user.proto'),
},
});
await app.listen();
client = ClientProxyFactory.create({
transport: Transport.GRPC,
options: {
package: 'user',
protoPath: join(__dirname, '../proto/user.proto'),
},
});
});
it('should get user', async () => {
const service = client.getService<UserServiceClient>('UserService');
const user = await service.getUser({ id: 'test' }).toPromise();
expect(user.id).toBe('test');
});
});This setup might seem complex at first, but it ensures your services work correctly.
When you’re ready to deploy, there are some considerations. gRPC uses HTTP/2, which most modern infrastructure supports. Load balancers need to understand HTTP/2, and you might need to configure them differently than for HTTP/1.1.
Monitoring is also important. Since gRPC is binary, you can’t just read the traffic like you can with JSON. You’ll need tools that understand gRPC. Many observability platforms now support gRPC natively.
One challenge you might face is browser support. Browsers don’t fully support HTTP/2 in a way that works with gRPC. For web clients, you might need a gateway that translates between gRPC and HTTP/1.1. Tools like grpc-web exist for this purpose.
So when should you use gRPC instead of REST? If you’re building internal services that need to communicate quickly and reliably, gRPC is excellent. If you need streaming capabilities, gRPC has them built in. If you’re working in a polyglot environment with services in different languages, gRPC’s code generation ensures consistency.
But if you’re building a public API for third-party developers, REST might still be better. More developers are familiar with REST, and tools for testing REST APIs are more widespread.
The choice isn’t either-or, by the way. Many systems use both. Public-facing REST APIs that internally call gRPC services. This gives you the best of both worlds: developer-friendly public interfaces and high-performance internal communication.
I’ve found that once teams try gRPC for internal services, they rarely want to go back. The type safety alone prevents so many bugs. The performance improvements are noticeable, especially when services communicate frequently.
Remember that first service contract we wrote? That’s the heart of the system. It serves as documentation, as a source of truth, and as the foundation for all your generated code. Keep it versioned, keep it clear, and update it carefully.
Building with gRPC requires shifting how you think about APIs. Instead of thinking about endpoints and HTTP methods, you think about services and methods. Instead of JSON schemas, you write Protobuf definitions. The initial learning curve pays off in reliability and performance.
What patterns have you found work well for service communication? Have you tried gRPC, or are you considering it for your next project? I’d love to hear about your experiences and answer any questions you might have.
If this exploration of gRPC and NestJS was helpful, please share it with others who might benefit. Your comments and questions help make these guides better for everyone. Let’s keep building better systems together.
As a best-selling author, I invite you to explore my books on Amazon. Don’t forget to follow me on Medium and show your support. Thank you! Your support means the world!
101 Books
101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.
Check out our book Golang Clean Code available on Amazon.
Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!
📘 Checkout my latest ebook for free on my channel!
Be sure to like, share, comment, and subscribe to the channel!
Our Creations
Be sure to check out our creations:
Investor Central | Investor Central Spanish | Investor Central German | Smart Living | Epochs & Echoes | Puzzling Mysteries | Hindutva | Elite Dev | JS Schools
We are on Medium
Tech Koala Insights | Epochs & Echoes World | Investor Central Medium | Puzzling Mysteries Medium | Science & Epochs Medium | Modern Hindutva
