NestJS har innebygd mikrotjeneststøtte — det kan kjøres som en mikrotjeneste som kommuniserer over ulike transporter (TCP, Redis, NATS, RabbitMQ, Kafka, gRPC) i stedet for HTTP, ved å bruke en konsistent, meldingsbasert programmeringsmodell. Den samme NestJS-strukturen (moduler, tjenester, DI) gjelder; bare transporten og meldingsmønstrene endres.
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
}
}
To kommunikasjonsstiler: @MessagePattern for forespørsel-svar (den som kaller venter på et resultat, som RPC) og @EventPattern for hendelser (send-og-glem, frakoblet — utgiver venter ikke).
@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 (konfigurert via ClientsModule) sender meldinger/hendelser til andre tjenester — send() for forespørsel-svar, emit() for hendelser.
// 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 sin innebygde mikrotjeneststøtte er betydningsfull fordi den lar deg bygge distribuerte systemer ved å bruke den samme kjente NestJS-strukturen (moduler, leverandører, DI, dekoratører) mens du bytter HTTP ut med meldingsbaserte transporter — en stor produktivitets- og konsistensfordel.
Å forstå det er viktig for arkitektur av skalerbare systemer: meldingsmønster (forespørsel-svar) vs hendelsesmønster (send-og-glem) skillelinjen korresponderer direkte med det fundamentale mikrotjenestekommunikasjonsvalget — synkrone RPC-stilkall versus asynkrone, frakoblede hendelser (sistnevnte, via meldingsmeglerere, gir motstandskraft og løs kobling som gjør mikrotjenester robuste).
Å vite hvordan man oppretter mikrotjenester, definerer meldinga/hendelsesbehandlere, kaller andre tjenester via ClientProxy, bygger hybrid HTTP+mikrotjenesteapper, og velger transporter (lett pub/sub versus holdbare køer som Kafka/RabbitMQ versus høyytelse gRPC) er verdifull senior-nivå kunnskap for utforming av distribuerte back-ender.
Altfor mikrotjenester legger til reell kompleksitet (og er ikke alltid riktig valg fremfor en monolitt), gjør NestJS implementeringen ren og konsistent, noe som gjør dette til et viktig arkitektonisk emne for bygning av store, distribuerte NestJS-systemer.