Backend Integration for Inbox Notification System (Front-End)

[Jose-Alarcon1]

Discussion: Backend Integration for Inbox Notification System (Front-End)

Context

The Inbox Notification System has been implemented and merged to main. It includes features such as:

• Threaded message layout with previews
• Unread message badge tracking
• Dropdown filters by message type (e.g., Success, Warning, Info)
• Search functionality based on message content
• Modular and scoped CSS using .inbox-page for clean styling

Mock data is currently powering the interface. All fields and UI elements are designed based on expected backend schema (e.g., notification_title, notification_message, created_at).

Backend Preparation

I'm ready to connect this component to the live backend once the following are confirmed:

• Final field mappings: Backend returns notification_title, notification_message, but frontend expects subject and preview (already mapped in logic)
• Date formatting is handled via a utility function converting ISO timestamps to readable UI dates
• Data filtering on type (e.g., success, warning) is working with mock fields — backend types must match

❓ Key Questions for the Team

• Should we handle filtering on the backend or keep it client-side?
• Will the backend support unread counts and message type labels consistently?
• Do we want to batch-fetch messages or implement pagination/infinite scroll later?
• Will scheduling fields (currently stubbed in the UI) be part of this endpoint or a separate system?

Let Us Know:

• Any suggestions on the backend response shape?
• Do we foresee auth or permissions logic for message access by user role?
• Should we integrate with real-time tools (e.g., polling or sockets) for future updates?

Thanks! Looking forward to thoughts on how best to structure the backend hookup and future-proof this inbox feature.

Screenshot:

Flow Diagram: