ReactJS消息服务

Question

Background:

I am building a reactJS application using AWS cognito, dynamo and S3. The application is based in the recruitment sector where employers and employees can post and view jobs respectively. When an employee applies for a job the employer can view the employees profile and decided whether or not to message them. Employees and employers converse via an on-site messaging service.

The Question:

What is the best method to facilitate user chat?

ie what is a nice & efficient way to store messages and notify users when they have a new message.

Our current approach is to have a setTimeout() on the site and check for new messages but this will be very inefficient so i'm looking for some guidance.

I would like to stay inside the amazon infrastructure as much as possible but I am open to all suggestions.

Answer 1

I'm currently building something similar for a startup I'm working at. Our React app is served by node.js server, while the API backend is provided by a django API with drf. As in your user chat case, we need to handle some real time data arriving in the frontend.

Our approach

The solution may be split up into inter server and server-browser realtime communication:

We use redis (aws elasticache to be exact) as a publish/ subscribe message queue to push incoming data from the API backend to the nodejs server. Specifically, whenever an instance of the model in question is created due to an HTTP POST call (ie in your case a message, which is send to the server), we publish JSON serialized information on a channel specific to the actors of concern.

On the node.js servers, we subscribe to channels of interest and receive information from the backend in real-time. We then use socket.io to provide a websocket connection to the frontend, which may be easily integrated with React.

Limitations of this approach

You cannot simply server your React app as a static website from S3 and have to rely on a node x React approach. react-boilerplat (by Max Stoiber I think) is a great way to start.

What's more, you can also use websockets end to end. We use this approach as our data source isn't a browser but a constrained device.

Hope that helps!