Skip to main content

Integration with Novu Push Notification System

Schema

Involved Parts:​

Krane-base-app​

This is the place where interactions with Novu are orchestrated. The mobile app is responsible for:

  • Registering the patient in Novu and keeping track of their mobile devices. It does not interact with Novu directly but uses Krane backend to do so.

Krane-gateway​

  • Acts as an intermediate point of flow. It only proxies the requests from mobile to user service.
  • Exposes the API to do so.

Krane-user-service​

  • The actual place where the system is dependent on Novu.
  • Stores the configuration required to interact with it.
  • Listens to the scheduler OpenTasks event to trigger the notification.

Krane Base App​

New Configuration Required:​

None

Implemented Flows:​

  • Registration: Each time the patient logs into the app, they are registered in Novu as a subscriber. From the point of view of Novu, registration of the subscriber multiple times has no impact on the system.
  • Identification: To identify patients in Novu, the full sub property is used. Sub is a string in format: auth0|<id of the user in auth0>. This is important because this value differs from patient _id. Any database queries that will connect Novu and Krane db should be done with that as a query param.
  • Device Token: The device FCM token is stored as a patient device. In case the patient is logging in from multiple devices, they all will receive notifications.
  • Online Status:
    • Patient isOnline status is set to true. This property is used to decide if to send the notification. That decision is done by Novu itself and is configured in the Novu dashboard.
    • Patient isOnline status set to false when the user actively logs out from the device.

The mobile app never interacts with Novu by itself. It always uses Krane-gateway as a proxy. The philosophy behind the flow is: having notifications is less important than using the app itself. So, in any case, if the flow fails (subscription as a new user, adding the device token, or setting up the patient online status), the patient flow is not disturbed. For the moment, all calls to the Krane backend are synchronous; in case of failures, they are stored in the logs of the Krane-user service.

Ideas for the Future

  • Logging and Exception Tracking:
    • Logs in krane-user-service may not be sufficient for efficiently tracking exceptions, especially if there is a delay in user support contact. Consider storing failures in a queue that would trigger an email notification to the development team.
  • Flow Reliability:
    • For unreliable flows, implementing retry mechanisms and circuit breakers could enhance robustness.
    • Implement asynchronous communication with retries, Dead Letter Queue (DLQ), and email notifications for improved reliability.

Krane-gateway

New Configuration Required:​

  • USER_SERVICE environment variable in chart definition, pointing to the internal address of krane-user-service.

Functionality:​

  • Acts as a proxy to krane-user-service.
  • Exposes 2 endpoints:
    • /novu/subscribe
    • /novu/onlineStatus

Krane-user-service

New Configuration Required:​

  • NOVU_API_KEY: Different per environment, used to identify our Novu instance and authenticate against it.
  • FCM_MESSAGE_WORKFLOW_NAME: Defined per environment, identifies the Novu workflow triggered by OpenTask events.

Recent Implementations:​

  • Listener to OpenTask Events:

    • Uses a shared subscription named UserService_Scheduled_Tasks.
    • Listens to krane-tenant/scheduling/<tenant name> topic.
    • Reacts to events named OpenSpartRecallTask and OpenTask. For both events:
      • Retrieves patient ID from event data.
      • Checks for patient notification configuration.
      • Triggers Novu with patient sub (the property linking backend and Novu).
      • Notification is triggered based on Novu's engine.

  • Flow to Interact with Novu (via REST API):

    • POST /setIsOnline: Body parameters include user sub and a boolean. Triggered during logout to set isOnline status to false in Novu.
    • POST /subscribeToNovu: Parameters are patient sub, email, and FCM token. Triggered during login, making 3 calls to Novu:
      • Registers the patient (multiple registrations are acceptable for Novu).
      • Sets the online status to true.
      • Updates the patient device FCM token.