Wikimedia Product Infrastructure team/Push Notifications Infrastructure/Design Decisions

High-level components
This project will provide two new software components:
 * a service for managing push notification subscriptions and processing notification requests, and
 * a MediaWiki extension (Extension:PushNotifications) for associating MediaWiki global user IDs with push subscriptions and forwarding Echo events to the push service.

MW extension

 * Maintain a database of device push subscriptions based on provider tokens
 * Provide an API for users to register, renew, and unregister push subscriptions
 * Maintain a database table mapping global user accounts to push subscriptions
 * Provide an API for wiki users to associate their global user accounts with device push subscriptions
 * Provide an Echo notifier type to allow handling notifications with push
 * Provide a handler implementation for formatting notification requests and forwarding them to the push notification service

Push notification service

 * Provide an API for accepting notification requests
 * Forward notification requests to providers (Apple Push Notification Service, Firebase Cloud Messaging, etc.)

Draft DB schema
User:MHolloway (WMF)/Drafts/Push DB Schema

Client to call MW API for notification message details

 * Status: proposed
 * Decision: The Push Service provides some sort of notification type, which is the cue for the app client to invoke a known MW API query.
 * Pros:
 * No personal data transmitted
 * No need for I18N in push infrastructure and needed tracking of what locale a given notification should be sent to. A client could just use existing mechanisms to specify the locale in the MW API request (accept-language header, etc.).
 * Some clients cannot subscribe to push notifications (e.g. app on an Android device without Google Play Services). They may need to know about these queries, too, so they can poll instead.
 * Cons:
 * One more request for clients to make
 * Client needs to know about the notification type to handle it (client discards unknown types)
 * Question: Should client log notifications received with unknown types using event logging?
 * Date: 2020-04-21

Write push specific MW code directly in Echo extension

 * Status: accepted
 * Reason: 1. There's little reason to write a new extension that's so tightly coupled with Echo. 2. It takes too long to get a new extension approved.
 * Date: 2020-05-05

Manage only user-push subscription ID mappings

 * Status: rejected
 * Decision: Manage push subscriptions primarily in the external service. Manage mappings between wiki user accounts and push subscriptions in MediaWiki.
 * Reason for proposal: Push credentials are specific to a web browser or native app installation and not to a wiki user. Handling them separately allows for cleanly supporting anons and multi-user devices.
 * Reason for rejection: To simplify the architecture and client interaction patterns given the lack of present need to support anon subscriptions.
 * Date: 2020-05-13

Manage all subscription data

 * Status: accepted
 * Decision: Have Echo manage full push subscription data in MySQL.
 * Reason: To simplify the architecture, given the lack of a product need to support anon push subscriptions.
 * Date: 2020-05-13

Manage subscription data in Echo extension

 * Decision: subscription tokens will be associated with MediaWiki sessions and for that reason, it will be managed by the Echo extension, Echo will not be responsible for the broker communication logic which will be handled by the service.
 * Reasons: Anons and multi-user devices are not scoped for v1 and might bring unnecessary complexity to the system before we decide to support it; Authentication and session management are more reliable in MediaWiki and there is no necessity to add this logic layer to the service; Validating the subscription sessions in the Echo extension before firing the notification event will avoid overhead in the JobQueue of no-op events when users are not subscribed.
 * Date: 2020-05-08

Clients query Echo for notifications content

 * Status: proposed
 * Reason: Considering that [ https://phabricator.wikimedia.org/T251436  Echo handles SUL], clients don't need to perform requests for each wiki project, this reduces complexity for clients to phone-home to get appropriate data.
 * Date: 2020-05-12

Use Airship rather than a service built in-house

 * Status: investigating
 * Reason: It might be better (and cheaper) to pay someone to do this rather than building, operating, and maintaining custom software for it in-house.
 * Date: 2020-05-13

Write a new from scratch

 * Status: accepted
 * Decision: Write from scratch but incorporate non-intuitive bits (if any) from existing projects.
 * Reason: The FOSS projects we found were stale and unmaintained. The last commit to the front-runner project was 5 years ago.

Write the push service in Node.js

 * Status: accepted
 * Alternatives: Go, Python, Java, ...
 * Reason: More experience in the Foundation running services in Node.js than the others.
 * Date: 2020-04-20

Try using TypeScript

 * Status: accepted
 * Reason: Added type safety
 * Date: 2020-04-20

Use service-runner

 * Status: accepted
 * Reason: service-runner provides health metrics reporting required by SRE + logging
 * Date: 2020-04-20

Base project on service-template-node

 * Status: accepted
 * Reason: Provides a code structure that is consistent with other Node.js services running in WMF production
 * Date: 2020-04-20

Use Gerrit for code review

 * Status: accepted
 * Reason: Deployment pipeline is not ready for Github
 * Date: 2020-04-21

Store primary subscription data but not user IDs

 * Status: rejected 2020-05-08
 * Decision: Manage push subscriptions primarily in the service. Manage mappings between wiki user accounts and push subscriptions in MediaWiki.
 * Reason for proposal: Push credentials are specific to a web browser or native app installation and not to a wiki user. Handling them separately allows for cleanly supporting anons and multi-user devices.
 * Reason for rejection: It makes the architecture more complicated than necessary given that anon support is not (yet) required.
 * Date: 2020-04-28

Housekeeping
Some ideas on what to include in decision records. Pretty much everything here is optional for now.

Template

 * Status: [proposed | rejected | accepted | deprecated]
 * Decision:
 * Reason:
 * Date: [YYYY-MM-DD when the decision was last updated]