CQRS Bridge Concepts
How the NestJS CQRS bridge routes @nestjs/cqrs CommandBus, QueryBus, and EventBus traffic over KubeMQ channels.
Understand how @kubemq/nestjs-transport/cqrs swaps the in-process @nestjs/cqrs buses for KubeMQ-backed publishers before wiring it up in the how-to guide.
What It Does
NestJS ships a first-class CQRS package, @nestjs/cqrs, built around three in-process buses: the CommandBus, the QueryBus, and the EventBus. Out of the box those buses dispatch to handlers inside the same process. The KubeMQCqrsModule from @kubemq/nestjs-transport/cqrs swaps each bus's internal publisher for a KubeMQ-backed one, so a dispatched command, query, or event leaves the process and travels over a KubeMQ channel to whichever service registered the matching handler.
The routing is purely convention based. When you call CommandBus.execute(new CreateOrderCommand(...)), the bridge resolves the message's channel segment (by default the class name, CreateOrderCommand) and sends it to {commandChannelPrefix}.{CommandName} — for example cqrs.commands.CreateOrderCommand. Queries and events follow the same rule against their own prefixes. The result is distributed CQRS: your application code keeps calling the familiar CommandBus / QueryBus / EventBus API, while the dispatch crosses a service boundary through KubeMQ.
Internally the module replaces each bus's publisher with a KubeMQ adapter: KubeMQCommandPubSub calls sendCommand, KubeMQQueryPubSub calls sendQuery, and KubeMQEventPubSub calls sendEvent (or sendEventStore when persistEvents is enabled). All three share a single KubeMQ connection created by the module on startup.
The bridge is an optional feature. It lives behind the @kubemq/nestjs-transport/cqrs subpath entry point and requires the optional peer dependency @nestjs/cqrs. If you do not use NestJS CQRS, you do not need any of this — use the handler decorators directly.
Related
Was this page helpful?