Question 243782 in Amazon Web Sevices Question posted in
The official Amazon Web Services documentation can be found here.

Amazon web services – 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)
Tags:

3

Answers


  1. 0

    What about to look into the SSE https://dev.to/cloudx/backend-to-frontend-communication-with-server-sent-events-56kf ?

    You still need to implement it on the Backend, so not sure if you really need to overcomplicate it with SNS or SQS because only your backend can communicate to them, not the Frontend.

    Hope it shows you one more possible solution for your problem.

    Login or Signup to reply.
  2. 0

    SNS realizes a pub-sub pattern. A publisher doesn’t have to know about any subscriber, but the mediator (SNS) must. You have to "tell" the SNS who is your subscriber and how to reach it. The SNS then notifies a subscriber with a new event.

    So, you need some client-side component that will listen for updates from SNS (subscriber). From a networking perspective, it’s an active server socket that can accept a connection.

    I would think of 2 possible approaches:

    1. There’s an AWS JavaScript SDK that you can use to listen to a topic directly from a browser.
    2. You can reconsider WebSocket. The API Gateway has an option to work in WebSocket mode and can serve as a server-side for sending data to your client-side. You can then redirect SNS notifications to client-side via API Gateway. It will require several additional components, like Lambda and DynamoDB for storing a connection. Additional resource on the topic.
    Login or Signup to reply.
  3. 0

    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.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search