In-App Notification Repository
Component Detail
Description
Data access layer for persisting and retrieving in-app notification records displayed in the Notifications tab. Supports read/unread state, dismissal, and filtering by user and notification type including reminders and escalations.
in-app-notification-repository
Summaries
In-app notifications are the primary mechanism through which coordinators and peer mentors stay informed about assignments requiring attention, making this shared component a direct driver of programme responsiveness. When the right people are notified at the right time within the platform they are already using, response rates improve and at-risk participants receive timely support. This component underpins the notification experience across multiple product features — not just reminders but any future alert type the platform needs to surface — making it a strategic investment in the platform's communication infrastructure. A reliable notification system also reduces the need for external communication channels like email chains, keeping engagement centralised and measurable within the platform.
This is a shared, low-complexity component that will be consumed by multiple features, so it should be prioritised early in the development schedule to unblock dependent feature teams. Its interface covers the full notification lifecycle — creation, retrieval, read/unread state, dismissal, and expiry cleanup — which makes it a complete, self-contained deliverable. The main coordination requirement is agreeing on the Notification payload schema with all consuming features before implementation begins, as changes to the schema after integration will require updates across multiple consumers. Testing should include both unit tests for each method and integration tests validating that the Notifications tab UI receives correctly filtered results.
The deleteExpired() method requires a scheduled cleanup job or database trigger — confirm which team owns this operational concern. Shared component status means changes carry higher regression risk; establish a clear change-review process.
Shared backend data component persisting notification records to a dedicated notifications table. The payload structure for createNotification() should be defined as a typed interface shared across all consumers to prevent schema drift. getNotificationsForUser() must support filtering by notification type (reminder, escalation) — implement this as an optional query parameter rather than separate methods to keep the interface minimal. markAsRead() and dismiss() are separate state transitions and should update a status enum or distinct boolean columns depending on whether dismissed notifications need to remain visible with a different style.
getUnreadCount() is called on every page load for the notification badge — ensure it is backed by an index on (userId, read_at IS NULL) for sub-millisecond response. deleteExpired() is a maintenance method suitable for invocation by a pg_cron job or the cron trigger component; accept a Date threshold to keep it testable. Being shared, changes to this component's interface require coordination with all consuming services.
Responsibilities
- Persist new in-app notification records
- Retrieve notifications for a given user
- Mark notifications as read or dismissed
- Filter notifications by type (reminder, escalation)
- Delete expired or acknowledged notifications
Interfaces
createNotification(userId, payload): Notification
getNotificationsForUser(userId): Notification[]
markAsRead(notificationId)
dismiss(notificationId)
getUnreadCount(userId): number
deleteExpired(olderThan: Date)