Receive push notification without opening the app

[sleidig]

As a user I want to get notified about new events automatically so that I know when to open the app without having to check for updates manually all the time.

For example: Receive a system (push) notification saying "There are new events in Aam Digital. Open the app now."

• This task includes the technical requirements to trigger a notification on a user device
  • service to trigger a notification logically (server-side or are there options client-side in the background? also see comments here)
  • infrastructure required to register and reach a device with notifications (does this require server services and/or external services like Firebase?)
  • testing on desktop and mobile devices
• Next tasks building on this (not part of this issue):
  • logic to trigger specific relevant notifications (for now, only use some mock trigger)
  • UI to display notification in app (--> View list of notifications in the app #2661), for now just use a simple placeholder text on the system notification

---

open questions:

• research can browser run in background to receive notification when browser is otherwise closed (or if the PWA is installed and run in background?) @Ayush8923
• research possible alternatives (open source) to Firebase @Ayush8923
• check data protection implications of using Firebase for Push Notifications #2695

[Ayush8923]

@sleidig Just to clarify, my understanding is that we need to send a notification to the user's device even when the app is completely closed (neither in the foreground nor the background). For instance, if the Aam Digital app isn't running at all, the user should still receive a notification such as: "There are new events in Aam Digital. Open the app now."
Is that correct?

Based on my observations of apps like Google Chat and Slack, notifications generally appear only when the app is running in the background or foreground. Enabling notifications while the app is entirely closed might require research. If this understanding is accurate, I’ll look into potential solutions to achieve this, and I believe Firebase Cloud Messaging Services might be helpful in resolving this.

[sleidig]

Yes, this is correct. It might also be acceptable for us to have system notifications (i.e. visible outside of the UI of the app) only while the app is running in the background. However, as we are running a PWA, not a native app, I am uncertain how reliable these would run. (This can be part of the related research maybe)
And in the long run we would want to extend the notification system to also allow email notifications, so a central, server-side triggering is probably required.

[Ayush8923]

Got it, thanks for clarifying. I'll look into this further to identify potential solutions. I'll also investigate whether Firebase Cloud Messaging Services is suitable for this use case.

[Ayush8923]

research can browser run in background to receive notification when browser is otherwise closed (or if the PWA is installed and run in background?)

1. If the browser is completely closed:

   1. Desktop Browsers: Most browsers, like Chrome, Firefox, and Edge, cannot receive notifications when they are completely closed. Service Workers, which handle notifications, require the browser process to be running (even in the background).
   2. Mobile Browsers: Similarly, on mobile devices, if the browser is closed, notifications will not be delivered.

2. If the PWA is installed:

   1. PWAs (Progressive Web Apps) can receive notifications when the browser is running in the background, even if the app is not actively open.
   2. However, if the browser process is entirely shut down, PWAs will also not receive notifications because they rely on the browser’s Service Worker infrastructure.
   3. On mobile, the behavior varies:
      1. Android: Installed PWAs behave more like native apps and can receive notifications as long as the device allows background services.
      2. iOS: PWAs on iOS have stricter limitations and may not reliably receive notifications in the background.

Reference: For an app to receive push messages, it has to have an active service worker.

https://developer.mozilla.org/en-US/docs/Web/API/Push_API#push_concepts_and_usage

In other words, this is my understanding of Push Notifications so far

• If a user has Chrome open in the background on their laptop, your PWA can deliver notifications.
• If the browser is closed completely, no notifications will come through until the browser is reopened.
• If the PWA is installed on Android, notifications will work more consistently, but on iOS, they might not work at all.

@sleidig @tomwwinter Please let me know if you have any thoughts/questions/directions I should research. Meanwhile, I am researching to answer the other open questions you have mentioned.

[Ayush8923]

Open-Source Alternatives to Firebase for Push Notifications

Name	Description	How It Differs from Firebase	Repository
Gotify	Self-hosted push notification server focused on simplicity and privacy.	Lightweight and easy to set up; does not provide advanced analytics or segmentation like Firebase.	GitHub: Gotify
Pushy	Lightweight and battery-efficient push notification service for web and mobile apps.	No dependency on Google Play Services; uses Pushy infrastructure for delivery; less customizable than Firebase.	GitHub: Pushy Node SDK
OneSignal	Freemium push notification service with an open-source SDK for web notifications.	Relies on OneSignal servers; offers additional analytics and segmentation tools; simpler integration than Firebase.	GitHub: OneSignal SDK
Web Push Protocol	Open standard for push notifications. Use web-push library for Node.js.	Requires self-hosting backend; manual handling of encryption (VAPID keys) and Web Push protocol; full data control.	GitHub: web-push

To me, Gotify and Pushy look like good option to try first due to:

1. Simplicity of using it
2. Completely open (unlike OneSignal)
3. Well maintained (based on the commits)

@sleidig @tomwwinter Let me know what you think/suggest?

[sleidig]

Thanks for the good overview, @Ayush8923.

Do the clients (i.e. our PWA) use the same standard receiving push notifications from either of these services? Or is the client implementation very different for Firebase and each of these options?

What are the limitations regarding "segmentation" and "customizable" for Gotify and Pushy? Do you think it will be similarly possible/easy to implement our notifications requirement, including a per-user configuration which types of notifications a user wants to receive? (I am not completely sure yet whether this per-user configuration would/could be stored by Firebase/etc. or by our own service that will call Firebase to trigger notifications).

With regards to the limitations on closed app/browser, I think the restrictions are probably acceptable. We can later on, once it's implemented, test and review how to best help users with keeping browser active in the background.

[Ayush8923]

Do the clients (i.e. our PWA) use the same standard for receiving push notifications from either of these services? Or is the client implementation very different for Firebase and each option?

Client Implementation Differences (Firebase vs. Gotify/Pushy)

1. Firebase: Yes. Firebase uses the standard Web Push API, making it compatible with PWAs. Even when the app is closed, it works well, using service workers to handle notifications.
2. Gotify: No, Gotify uses WebSockets instead of the Web Push API. This means the client needs to stay connected to receive notifications, which can be tricky for PWAs since service workers cannot keep WebSockets open.
3. Pushy: Mostly yes. Pushy supports the Web Push API, similar to Firebase, but also offers its protocol. For PWAs, it works like Firebase, though it might not be as flexible.

---

What are the limitations regarding "segmentation" and "customizable" for Gotify and Pushy?

Segmentation and Customization (Gotify/Pushy)

Gotify:

• Segmentation: Limited. We can only send messages to specific users, but it doesn't support advanced grouping.
• Customization: More work is needed. We need to manage user preferences entirely on the backend and send notifications based on those.

Pushy:

• Segmentation: Better. We can target individual devices, making it easier to control who gets which notifications.
• Customization: Similar to Firebase(less customizable than Firebase). We can store user preferences and target users based on tokens, making it more flexible.

---

Do you think it will be similarly possible/easy to implement our notifications requirement, including a per-user configuration for which types of notifications a user wants to receive?

• Firebase and Pushy are more suited for implementing per-user configurations. Both allow targeting users based on tokens.
• Gotify would require handling segmentation and customization entirely within our service, adding complexity.

@sleidig I have tried to answer your question based on my research. Please let me know if you have any questions/thoughts regarding this.

[Ayush8923]

@sleidig @tomwwinter, Did you get the chance to look into these alternative approaches? Which push notification implementation are we moving forward with?

[sleidig]

--> joint decision: We will implement this using Firebase for now.

[Ayush8923]

@tomwwinter I have a few questions and need to discuss a few things related to the push notification backend implementation:

1. We are using the /api/v1/notification/device API to save the FCM (Firebase Cloud Messaging) token in the backend. So, should we also use the same API to get the Firebase access token for authentication, where we will receive the Firebase access token from the backend? Also, just checking, is this API live in the testing environment?
2. Can we discuss how notifications will be triggered from the server side and whether we might need the implementation of firebase-admin in the backend to handle which users should receive the notification? For example, if an entity is updated, the corresponding user should receive a notification that the entity has been updated. Can we discuss this as well, how will we implement this in the backend?