feat: add postgres transport

[rcottinet]

Implements a new transport backend for PostgreSQL using NOTIFY/LISTEN for pub/sub messaging

Implementation

• Transport: PostgresTransport

  • Uses escapeIdentifier() and escapeLiteral() from pg for SQL safety
  • Channel handlers map for multi-channel subscriptions

• Dependencies: pg as optional peer dependency, @testcontainers/postgresql for tests

Usage

import { postgres } from '@boringnode/bus/transports/postgres'

const manager = new BusManager({
  transports: {
    main: {
      transport: postgres({
        host: 'localhost',
        port: 5432,
        database: 'mydb',
        user: 'postgres',
        password: 'password',
      }),
    },
  },
})

// Or with connection string
const manager = new BusManager({
  transports: {
    main: {
      transport: postgres('postgresql://user:pass@localhost/dbname'),
    },
  },
})

Notes

• Reconnection handler implemented but requires reconnection logic at application level (pg client doesn't auto-reconnect)
• NOTIFY payload size limited to 8000 bytes by PostgreSQL

Warning

I think it's only compatible with v14+ postgres

[ThisIsMissEm]

Another approach here could be to have a events database table which you insert a row to, and then trigger a notify to signal that that table has been updated. That means that clients which are disconnected when the notify happens can still retrieve the messages when they reconnect.

[ThisIsMissEm]

You'll probably want to use some form of exponential backoff with randomised jitter to ensure safe reconnection during outages.

You probably also want to check here if you should reconnect, e.g., disconnect may emit an end event (I can't recall if it does)

[ThisIsMissEm]

You'll also want to track that you are in fact actually reconnecting, and in that case, block ensureConnected on that reconnection promise, otherwise it's possible that a temporary disconnect can trigger a double connection.

[rcottinet]

Another approach here could be to have a events database table which you insert a row to, and then trigger a notify to signal that that table has been updated. That means that clients which are disconnected when the notify happens can still retrieve the messages when they reconnect.

hi @ThisIsMissEm thanks for your review
That’s a fair point regarding persistence (and also avoid payload size limitation), but I find the current LISTEN/NOTIFY setup less invasive, to keep the architecture simple without adding extra tables - or maybe with some kind of temp table ?