Object-Oriented AMQP Client
oomq
to mimics the API of EventEmitter and hides the fact that the events are handled through AMQP server. So instead of doing:
var q = 'tasks'; var open = ; // Publisheropen; // Consumeropen;
one would write:
const q = 'tasks'; const EventEmitter events = ;const emitter = 'amqp://localhost'; // Publisherconst event = eventsJSONEvent; emitter ; // Consumeremitter;
It aims to avoid common pitfalls of building an event-driven architecture through:
- Enabling defining common event type and constructors(the static
create
function) for them; - Forces clients to document which projects can emit which events;
- Simplifies routing logic by just requiring the client to specify the event type and queue name;
- Enables defining validation and serialization for each event type.
It doesn't aim to:
- define event types out of the box, but provides mechanisms for that;
- enforce serialization, but allows implementing any as an meta Event type to extend.
Install
npm install oomq --save
API
EventEmitter
Interfaces
; ;
new EventEmitter(url: string, options: OnOptions = {})
url
: AMQP server connection string.options
: default options foron
calls.
EventEmitter#on(Event: T, queue: string, handler: HandlerFunction, options: OnOptions = {}): Promise
Event
: Event type to listen to.queue
: Queue identifier. This with stringified name of event type makes the actual queue name in the amqp server.handler
: Handler function which is expected to return a promise. Errors fromhandler
are thrown. If events are expected to be retried on failure, catch them inside the handler and resolve withemitter.REQUEUE_EVENT
symbol instead.
EventEmitter#emit(event: BaseEvent, options: EmitOptions = {}): Promise
event
: Instance of event to be emitted.
Usage
There are several examples of usage in examples folder. In simplest form:
const EventEmitter = ;const emitter = 'amqp://localhost'; // emitter.emit( ... ); emitter; // Will close the channel and connection used by the emitter
After closing the connection with emitter.close()
the client is no longer usable. Publishing events will throw and consumers will be stopped.
Common Setup
oomq
doesn't define any event types in your system, but provides mechanisms for that. It does not enforce the serialization(protobuf, JSON) nor the structure. That makes getting off ground with oomq
a bit more work. Generally you'd either:
- define all event types in a project that does producing and consuming of those events or
- in a separate project if producers and consumers are implemented in different projects so both ends could depend on the package that implements the same event types.
Every all the events have to inherit from Event
Example of defining a event type that handles serialization: JSONEVENT.ts. Example of defining a event type that handles validation and event structure: Product event.