NestJS har indbygget microservices-understøttelse — det kan køre som en microservice, der kommunikerer over forskellige transporter (TCP, Redis, NATS, RabbitMQ, Kafka, gRPC) i stedet for HTTP, ved hjælp af en konsistent, meddelelsesbaseret programmeringsmodel. Den samme NestJS-struktur (moduler, services, DI) gælder; kun transporten og meddelelsesmønstrene ændres.
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 kommunikationsstile: @MessagePattern til request-response (kalderen venter på et resultat, som RPC) og @EventPattern til events (fire-and-forget, ukoblet — publisheren 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 (konfigureret via ClientsModule) sender meddelelser/events til andre services — send() til request-response, emit() til events.
// 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' indbyggede microservices-understøttelse er betydningsfuld, fordi det giver dig mulighed for at bygge distribuerede systemer ved hjælp af den samme velkendte NestJS-struktur (moduler, providers, DI, decorators), samtidig med at du udskifter HTTP med meddelelsesbaserede transporter — en stor fordel for produktivitet og konsistens.
At forstå det er vigtigt for at arkitekturere skalérbare systemer: message-pattern (request-response) vs event-pattern (fire-and-forget) skelnen mapper direkte til det grundlæggende microservices-kommunikationsvalg — synkrone RPC-lignende kald versus asynkrone, ukoblede events (sidstnævnte via message brokers, der giver den robusthed og løs koblingkvalitet, der gør microservices robuste).
At vide, hvordan man opretter microservices, definerer message/event-handlere, kalder andre services via ClientProxy, bygger hybrid HTTP+microservice-apps og vælger transporter (let pub/sub vs holdbare queues som Kafka/RabbitMQ vs høj-ydeevne gRPC), er værdifuld senior-niveau viden til at designe distribuerede back-ends.
Mens microservices tilføjer reel kompleksitet (og er ikke altid det rigtige valg frem for en monolitisk app), gør NestJS implementeringen ren og konsistent, hvilket gør dette til et vigtigt arkitekturemne for at bygge store, distribuerede NestJS-systemer.