Class Diagrams

This page explains the backend class structure used to construct and deliver web notifications. The primary goals are:

• Standardise how notification payloads are built across types.
• Keep recipient resolution consistent and testable.
• Use a gateway layer so delivery mechanisms can evolve independently.

Core Class Structure

How to Read the Diagram

• Notification (base model)

  • Represents the conceptual notification and its core fields (message params, sent_to, sent_on).
  • In practice, this maps to stored notification records and is used as the common “unit” across types.

• AbstractWebNotification (contract)

  • Defines the required lifecycle of any web notification type:
    • prepare_payload() – build the message/payload (title/body/data) from inputs and templates.
    • get_recipients() – compute who should receive the notification (lab users, roles, org, doctors).
    • send() – orchestrate persistence + delivery via configured gateway(s).

• Type-specific classes (example: OrgReportReady)

  • Encapsulate business logic for a particular notification type.
  • Common responsibilities:
    • Convert domain objects (e.g. lab_notification) into a payload.
    • Apply type-specific routing rules (which roles/topics receive it).
    • Choose delivery channel(s) via gateways.

• Gateway layer (FCMPusherGateway, PusherGateway)

  • Abstracts the underlying delivery provider:
    • FCM is typically used for browser push notifications and offline delivery.
    • Pusher/WebSocket may be used for faster in-app delivery where available.
  • Keeps provider authentication, payload formatting quirks, retries, and response handling out of the business logic.

Typical Runtime Flow

1. A business event occurs (e.g. organisation report becomes ready).
2. The system instantiates the relevant notification type class (e.g. OrgReportReady(lab_notification)).
3. The notification class:
   • Calls prepare_payload()
   • Calls get_recipients()
4. send() persists notification records and delegates delivery to:
   • FCMPusherGateway.send_notification(...) (push), and/or
   • PusherGateway.send_notification(...) (in-app)
5. Delivery outcomes are recorded and later user actions update read/unread activity.

Where This Fits

• For persisted entities and relationships, see Data Model.
• For the client-facing endpoints that interact with this layer, see API Reference.