Subscribe to changes using logical replication

[porsager]

I've just finished implementing realtime capability to Postgres.js through logical replication, so you can subscribe to changes as simple as this:

Create a publication (eg. in migration)

CREATE PUBLICATION alltables FOR ALL TABLES

Subscribe to updates

const sql = postgres({ publications: 'alltables' })

const { unsubscribe } = await sql.subscribe('insert:events', row =>
  // tell about new event row over eg. websockets or do something else
)

The pattern for subscribing is [command]:[schema.table]=[primary_key] where command is insert | update | delete | * and defaults to *. schema.table defaults to * and will prepend public. if schema is not defined. As the last thing primary_key can be used to only subscribe to a specific row. It's optimized to do the least amount of work depending on what you subscribe to, so I'm really excited to see what can be built with this.

Now I still have some tests and docs to write, but if anyone would like to take this branch for a spin I would love to hear what you think..

[alextes]

Yea this would be a bunch cleaner than the notify/listen I have going on now. The only challenge for our codebase is that we only have one notify/listen and it triggers after two tabels have updated. Maybe when I have some time I can change that insert/update to be a transaction, and then the subscribe to either of those tables would work well I think 🤔 .

[porsager]

@alextes Maybe I misunderstand, but wouldn't this be equivalent?

const sql = postgres({ ... })

sql.subscribe('table1', notifyHandler)
sql.subscribe('table2', notifyHandler)

function notifyHandler() {
  // This is called when the two tables change.
}

[alextes]

@porsager my description was a bit imprecise. Some event A, causes an update to two tables, call those updates B and C, I need to call a handler when B && C have updated, or seen differently when we're done dealing with event A. Your code example results in the handler being called if B || C happens if I'm not mistaken. Now that I think about it, running B and C in a transaction would also solve this maybe at which point subscribing to either would work right?

[porsager]

Ah I see.

Yes, subscribing to either should be fine as well, but remember that if you do any kind of changes besides in that transaction it'll fire as well.