Skip to content

Notification ​

Responsibility and implementation ​

Notification owns reusable templates, notification records, channel selection, content rendering, delivery attempts, and sent/failed status. It does not own the business operation that requests a notification. Use cases and a legacy HTTP handler exist; the module currently constructs in-memory repositories despite their postgres adapter directory name. State does not survive process restart.

Delivery flow ​

A send request selects a template, renders its subject/body with variables using Go text/template, records a queued notification, dispatches through the email or SMS provider, and updates sent/failed state. Email uses the injected shared email.Sender; the API currently injects console delivery. SMS uses a development stub. Template and notification lookup/list/update operations use the same in-memory repositories.

Identity also uses the shared email sender directly; its verification/recovery flow does not rely on Notification templates or a background subscription. The module does not currently establish event subscriptions, an outbox, retry scheduling, or durable delivery guarantees.

HTTP and access ​

The API composition root mounts the legacy module at /api/v1/notifications. Its handler declares send/list/detail operations and template create/list/get/update operations. These legacy handlers do not gain Huma validation or OpenAPI coverage just because they share the router. Inspect the mounted route behavior before adopting them as a production notification API; authentication and delivery hardening remain work to be done.

Storage, examples, and testing ​

The repositories are in-memory adapters, not pgx-backed tables or embedded migration sets. Delivery tests cover template expansion, shared email invocation, provider errors, and sent/failed behavior. The email guide describes console records and provider replacement. The sent state means the current provider call succeeded; with console/stub providers it does not prove delivery to a real inbox/phone.

Code reference ​

See module, delivery use cases, and HTTP handler.

Documentation follows the source. Planned contracts are marked explicitly.