20 lines
1.1 KiB
Markdown
20 lines
1.1 KiB
Markdown
# 0002 - List Realtime Uses Postgres Notify And SSE
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
The lists module needs updates from another signed-in household member to appear without a refresh. The app already plans to use Postgres `LISTEN/NOTIFY` bridged to Server-Sent Events for small-scale realtime.
|
|
|
|
## Decision
|
|
|
|
Each list has a Postgres notification channel named `list:<listId>`. List mutations call `pg_notify` after the database write. The route handler at `/api/lists/[id]/events` verifies the current household can access the list, listens on that one channel, and streams notifications as SSE messages.
|
|
|
|
Clients keep one `EventSource` open for the current list. On any message, they reload the list through the existing household-gated query path.
|
|
|
|
## Consequences
|
|
|
|
This keeps realtime scoped to the module and avoids a separate WebSocket service. The client refreshes the whole list after a notification, which is simple and acceptable for household-sized lists. If future modules need the same pattern, they can use their own entity-scoped channels and SSE route handlers without changing core registries.
|