REST API with active push notifications from server to client

Question

Problem description

I am working on a Xamarin application that consumes a REST API written in Python Flask.

The Xamarin application offers virtual shopping lists where user can collaborate on buying stuff they have on a shared list.

To improve the user experience, I want to be able to actively notify the user about finished items on the list.

Possible solutions:

Synchronous API polling from client side

Notifications are stored by the API in a relational database and have a flag indicating if the user received the notification already.

The API has an endpoint GET /users/:user_id/notifications/ that queries the database for notifications and returns a JSON response with those.

Advantages

• Fairly simple to implement

Problems

• Synchronous polling creates a huge amount of HTTP requests

• API service remains stateless, making a horizontal scaling with a loadbalancer easier

Websocket endpoint on the API

The API has an endpoint POST /users/:user_id/notifications/register which creates a websocket connection between client and API.

The connection is stored to a global array in which each entry maps a client id to a websocket connection.

When a new notification is created, the endpoint makes a lookup in the connection dictionary by comparing the owner id of the notification with the dictionary entries. The notification is sent to appropriate user through the websocket.

Notifications are stored in the database like in the first approach.

When a user calls the endpoint, a new websocket connection will be established first and upon success the API sends all unseen notifications from the database to the user.

Advantages

• API can push notifications to clients asynchronously

Problems

• When a user terminates the websocket connection his dictionary entry will persist
• Retaining one websocket connection per user permanently adds additional overhead to the API
• Horizontal scalability of the API is more difficult because the service is not stateless any more (Websocket connection information saved in

RabbitMQ

The API uses a RabbitMQ service to send notifications to the client. Every client uses subscribes to his own notification queue to prevent the broadcasting of messages.

Advantages

• API remains stateless

Problems

• Notifications needs to be resend to the exchange when a user is offline

• Amount of queues grows drastically

• Additional costs for RabbitMQ service

• High temporary load on the RabbitMQ service when many users come online in the same time

Final words

It would be interesting to hear the opinion of others.

I believe the active distribution of notifications from backend services to clients I a very common use-case.

Answer 1

I would use RabbitMQ and consume events forwarding them as push notifications. This will work while the user is not actively connected to the website and enhance the engagement with each user experience that will return to the website when notified for more information see How to setup basic web push notification functionality using a Flask backend or How to send push notifications to a browser in ASP.NET Core or Sending Notifications with Spring Boot, Angular, and Firebase Cloud Messaging this way the RabbitMQ will not wait until the user is back online. If the user is online you can forward the notification directly to the Xamarin application via WebSockets and a load balancer like NGINX that can handle many WebSockets in an optimized way. Synchronous API polling from the client-side is the less preferred way since it overloads the webserver with requests while nothing was changed.