Near Real Time Alerts

Owned by Steve Mattingly (Unlicensed)
Last updated: Apr 06, 2022
2 min read

Status

☐ Draft    ☐ Proposed    ☑ Accepted    ☐ Rejected    ☐ Superseded

Context

LiteFarm is working on Notifications Centre features. We need to select an approach for the client software to become aware of new, server-generated notifications in near real time. See Jira ticket LF-2224 for more details.

The HTTP protocol is half-duplex communication initiated by the client. This means that data flows in one direction at a time, and that the server can only respond to a client request. Each request/response cycle is isolated from the rest, so the server can never initiate HTTP communications. 

Forces at play for this decision include:

  1. A desire to alert the user to new notifications as soon as possible.

  2. A desire to avoid wasted resources and/or high overhead costs.

  3. Ease of implementation.

  4. A desire for a flexible, extendable approach, in light of known future use cases and emerging requirements.

Alternatives

  1. Polling, long polling, and similar approaches where the client periodically requests new notifications from the server.

  2. Other client-driven approaches where selected page loads or navigation actions trigger the client to request new notifications from the server.

  3. Supplementing server responses to all API requests with any new notifications for the user.

  4. Using Websockets so that the server pushes new notifications to the client asynchronously (without the client making a request).

  5. Using server-sent events (SSE) so that the server pushes new notifications to the client asynchronously (without the client making a request).

The first three alternatives make no fundamental departures from the HTTP request/response model. The first two simply generate automatic client requests at certain events. The third extends every server response to include information that was not explicitly requested.

The last two alternatives supplement HTTP to create “publish-subscribe” communications models.

Websockets establishes an additional persistent full-duplex (simultaneous two-way) TCP connection between the server and client.

SSE creates a second half-duplex (non-simultaneous two-way) communication path that is initiated by the server.

Decision

We select the server-sent events approach as the best balance between competing forces 1 and 2. We accept that SSE cannot transmit binary data such as media and attachments because it is unlikely that we would want to push such data from the server. 

Websockets provides greater communications power (full-duplex), but at a higher price in terms of server resources and implementation effort. We foresee no need for LiteFarm to support full-duplex communication (e.g., chat).

We note that the first three alternatives have definite weaknesses for force 1, and possibly for forces 3 and 4. Alternative 3 carries the additional concern of violating HTTP expectations and deviating from typical API practices.