@boringnode/bus is a service bus implementation for Node.js. It is designed to be simple and easy to use.

Currently, it supports the following transports:

Table of Contents

• Installation
• Usage
• Retry Queue

Installation

npm install @boringnode/bus

The Redis and MQTT transports rely on optional peer dependencies. Install the client of the transport you use.

npm install ioredis # for the Redis transport
npm install mqtt # for the MQTT transport

If your project has neither ioredis nor mqtt installed and uses skipLibCheck: false, import types from @boringnode/bus/types/core. @boringnode/bus/types/main also re-exports the Redis and MQTT types.

Usage

The module exposes a manager that can be used to register buses.

import { BusManager } from '@boringnode/bus'
import { redis } from '@boringnode/bus/transports/redis'
import { mqtt } from '@boringnode/bus/transports/mqtt'
import { memory } from '@boringnode/bus/transports/memory'

const manager = new BusManager({
  default: 'main',
  transports: {
    main: {
      transport: memory(),
    },
    redis: {
      transport: redis({
        host: 'localhost',
        port: 6379,
      }),
    },
    mqtt: {
      transport: mqtt({
        host: 'localhost',
        port: 1883,
      }),
    },
  }
})

Once the manager is created, you can subscribe to channels and publish messages. A bus does not receive the messages it publishes itself, so the subscriber and the publisher usually live in different processes, connected through a shared transport like Redis.

// In one process
await manager.use('redis').subscribe('channel', (message) => {
  console.log('Received message', message)
})

// In another process
await manager.use('redis').publish('channel', 'Hello world')

The memory transport only delivers messages to other buses of the same process.

An error thrown or rejected by a handler does not crash the process, and other handlers still run. The bus catches it and logs it when NODE_DEBUG=boringnode:bus is set. Catch errors inside the handler if you need to react to them.

By default, the bus will use the default transport. You can specify different transport by using the use method.

manager.use('redis').publish('channel', 'Hello world')
manager.use('mqtt').publish('channel', 'Hello world')

MQTT topic filters

The MQTT transport accepts topic filters with the + and # wildcards, and calls the handlers of every filter matching a received topic. When filters overlap, such as orders/+ and orders/#, some brokers like Mosquitto and EMQX send one copy of the message per matching subscription, and the handlers of these filters are called once per copy. This happens with MQTT 5 too, so avoid overlapping filters when a handler must run once per message.

Without the manager

If you don't need multiple buses, you can create a single bus directly by importing the transports and the Bus class.

import { Bus } from '@boringnode/bus'
import { RedisTransport } from '@boringnode/bus/transports/redis'

const transport = new RedisTransport({
  host: 'localhost',
  port: 6379,
})

const bus = new Bus(transport, {
  retryQueue: {
    retryInterval: '100ms'
  }
})

Retry Queue

The bus also supports a retry queue. When a message fails to be published, it will be moved to the retry queue.

For example, your Redis server is down.

const manager = new BusManager({
  default: 'main',
  transports: {
    main: {
      transport: redis({
        host: 'localhost',
        port: 6379,
      }),
      retryQueue: {
        retryInterval: '100ms'
      }
    },
  }
})

manager.use('main').publish('channel', 'Hello World')

The message will be moved to the retry queue and will be retried every 100ms.

The retry queue only retries publishing. Redis and MQTT pub/sub deliver messages at most once: a successful publish does not mean a subscriber received the message, and subscribers that are disconnected when it is published never get it. If you need guaranteed delivery, use a durable mechanism such as Redis Streams or message acknowledgements in your application.

Redis Cluster does not guarantee message ordering either: it sends a keyless PUBLISH to a random node, so a subscriber can receive messages published one after the other in a different order.

You have multiple options to configure the retry queue.

export interface RetryQueueOptions {
  // Enable the retry queue (default: true)
  enabled?: boolean
  
  // Ignore a message when the same payload is already queued for the same channel (default: true)
  removeDuplicates?: boolean
  
  // The maximum size of the retry queue (default: null)
  maxSize?: number | null
  
  // The interval between each retry (default: false)
  retryInterval?: Duration | false
}

Test helpers

The module also provides some test helpers to make it easier to test the code that relies on the bus. First, you can use the MemoryTransport to create a bus that uses an in-memory transport.

You can also use the ChaosTransport to simulate a transport that fails randomly, in order to test the resilience of your code.

import { Bus } from '@boringnode/bus'
import { MemoryTransport } from '@boringnode/bus/transports/memory'
import { ChaosTransport } from '@boringnode/bus/test_helpers'

const buggyTransport = new ChaosTransport(new MemoryTransport())
const bus = new Bus(buggyTransport)

/**
 * Now, every time you will try to publish a message, the transport 
 * will throw an error.
 */
buggyTransport.alwaysThrow()