Replace client polling with AWS SNS/SQS/MQ

Problem Statement

I have an application in which the data on the client side (frontend) needs to be updated in near-realtime.

The backend updates a field in the database. There is a GET endpoint which queries the db and sends the data on this db field in response. The client side keeps on polling this GET endpoint in every 2 sec interval due to which there is always a huge traffic on the servers.

I want to replace polling with AWS topics. The server will publish message on the topic and the client will subscribe to these topic and any update data should be shown on client side. I don't want to use the traditional long-polling or websocket approaches and want to solve this via AWS SNS/SQS topics mechanism

Issue

I am not able to understand how to implement this with AWS SNS. As of now, I have created a topic in SNS and want the client to subscribe to this topic for real time updates. To subscribe to SNS, I am thinking to use HTTP/S endpoint which will trigger when message is pushed to topic, but not sure on how client will be able to subscribe to this

• Do I need to create a dummy subscription endpoint on the server side and then client use it. What will be mechanism for client to consume this data ?

(or)

• Do I need to SQS in combination to SNS. SQS will subscribe to SNS topic and then the client will subscribe to SQS queue to get this data ?

Frameworks used if that matters :

• Backend/Server-side (Django)
• Frontend/Client-side (React js)

This is an ideal use case for websockets, but since you are avoiding that I'd like to propose another solution that may be less common: MQTT via AWS's IoT service.

MQTT is a lightweight protocol for sending messages from a server to many clients. IoT isn't just for home automation; 'thing' is a very generic term, after all.

It sounds intimidating but it's actually easy to implement using the IoT service and the provided SDKs. The infrastructure required in AWS can be fairly minimal, and the client provided by the SDK is simple and works in node and the browser.

You'll have to decide on a pattern (topic for each user? broadcast all changes to everyone?), and then subscribe your frontend to the appropriate topic(s).

Otherwise, I'd clarify that your web client would be subscribing to SNS to receive notifications (probably from within a web worker). I wasn't able to find any definite information as to whether SNS supports web browser clients yet, so your approach may not yet be possible.

SQS is something you would use inside your internal infrastructure, serverside, to coordinate messages between your internal services. It's not typically used to send notifications to clients, instead it's a simple message queue primitive. SQS doesn't really support the concept of subscribers; although you can create Lambda triggers, it's best to think of it as a dumb message queue and not a notification system

If you decide to pursue websockets (which is my recommendation), I suggest looking into AppSync. It uses websocketsockets internally and gives you an (opinionated) API to build your application around.