NestJS har inbyggt stöd för mikrotjänster — det kan köras som en mikrotjänst som kommunicerar över olika transporter (TCP, Redis, NATS, RabbitMQ, Kafka, gRPC) istället för HTTP, med en konsekvent, meddelandebaserad programmeringsmodell. Samma NestJS-struktur (moduler, tjänster, DI) gäller; endast transporten och meddelandemönstren ändras.
app = .(, {
: .,
: { : , : },
});
app.();
@Controller()
export class MathController {
// REQUEST-RESPONSE: respond to a message and RETURN a result (RPC-style)
@MessagePattern({ cmd: "sum" })
sum(data: number[]): number {
return data.reduce((a, b) => a + b, 0); // the caller awaits this result
}
// EVENT-BASED: react to an event, NO response expected (fire-and-forget)
@EventPattern("order_created")
handleOrderCreated(data: OrderDto) {
this.processOrder(data); // just react; nothing returned
}
}
Två kommunikationsstilar: @MessagePattern för request-response (anroparen väntar på ett resultat, som RPC) och @EventPattern för händelser (fire-and-forget, låst koppling — utgivaren väntar inte).
@Injectable()
export class AppService {
constructor(@Inject("MATH_SERVICE") private client: ClientProxy) {}
async getSum() {
// send() → request-response (returns an Observable of the result)
return this.client.send({ cmd: "sum" }, [1, 2, 3]);
// emit() → fire an event (no response)
this.client.emit("order_created", orderData);
}
}
En ClientProxy (konfigurerad via ClientsModule) skickar meddelanden/händelser till andra tjänster — send() för request-response, emit() för händelser.
// an app can serve HTTP AND connect microservice transports simultaneously
const app = await NestFactory.create(AppModule);
app.connectMicroservice({ transport: Transport.RMQ, options: {...} });
await app.startAllMicroservices();
await app.listen(3000); // HTTP too
TCP → simple direct service-to-service
Redis/NATS → lightweight pub/sub messaging
RabbitMQ/Kafka → robust message queues/streams (durability, retries, decoupling)
gRPC → high-performance, strongly-typed RPC (protobuf)
→ Async message brokers (RMQ/Kafka) give decoupling & resilience; gRPC gives speed+typing.
NestJS:s inbyggda stöd för mikrotjänster är betydelsefullt eftersom det låter dig bygga distribuerade system med samma bekanta NestJS-struktur (moduler, providers, DI, dekoratörer) samtidigt som du byter HTTP mot meddelandebaserade transporter — en stor produktivitets- och konsistensfördel.
Att förstå det är viktigt för att arkitekturera skalbara system: meddelandemönster (request-response) vs händelsemönster (fire-and-forget) distinktionen mappar direkt till det grundläggande valet för mikrotjänstkomminikation — synkrona RPC-liknande samtal kontra asynkrona, löst kopplade händelser (det senare, via meddelandemäklare, vilket ger den motståndskraft och lösa koppling som gör mikrotjänster robusta).
Att veta hur man skapar mikrotjänster, definierar meddelande-/händelsehanterare, anropar andra tjänster via ClientProxy, bygger hybrid HTTP+mikrotjänstappar och väljer transporter (lättviktig pub/sub vs varaktiga köer som Kafka/RabbitMQ vs högpresterande gRPC) är värdefull kunskap på senior-nivå för att designa distribuerade backends.
Even om mikrotjänster tillför verklig komplexitet (och inte alltid är rätt val framför ett monoliter), gör NestJS implementationen ren och konsekvent, vilket gör detta till ett viktigt arkitekturamne för att bygga storskaliga, distribuerade NestJS-system.