Show messages as soon as they're received

[kyratking]

Task Description

If I send a message to a Kinsend client, the message should appear on their dashboard on /messages route as soon as it is received and processed by the application.

Notes

There are currently two ways to approach this problem.

1. Webhooks
2. A loop that calls the message API in X number of seconds

From a technical perspective, webhooks are the way to go for this problem but they'd require significant back-end and front-end changes. But, the benefit and fault tolerance they'll provide us will be immense.

Task List

The following tasks will need to be carried out:

• [ ] Set the priority of this issue
• [ ] Decide what approach we need keeping all the constraints in mind
• [ ] Implement the solution for both front-end and back-end
• [ ] Test the solution locally
• [ ] Deploy it on a development branch
• [ ] Test the solution in a development environment

Incurred Costs

In the current state of the project, the webhook implementation could take anywhere around 2-4 weeks depending on code complexity. As for the looping approach, this would require significantly less amount of time.

Resources

• Socket.io

Useful Links

• The difference between both approaches, their pros and cons. Read here

Points of Contact

@alexbangiyev @azlanzar @kyratking

[steve-todorov]

@alexbangiyev this ticket "looks" good, but doesn't really say anything other than Show messages as soon as they're received.

The fault-tolerance terminology has been misused here. Fault tolerance means something completely different and is a term used in High Availability platforms to indicate the platform can continue to operate even in the case when N amount of servers out of Y servers are completely dead. You can also achieve software fault tolerance by doing retrys or attempting to contact a different datacenter (i.e. if you have 2 or 3 replicas). However simply stating that using "webhooks will improve fault tolerance" is not accurate.

Also, I am not entirely sure what is meant by webhooks here. The actual ways to achieve the objective are by using one of the following:

1. Ajax Polling (hitting an endpoint every X amount of time to check for updates)
2. Websocket (bi-directional client-server communication)
3. Server Sent Events (aka SSE, mono-directional - only server sends events)

Either one of these would work, but the most optimal would be to use SSE, because this would only keep a mono-directional connection open in which only the server sends events to the client.

Here's more info about the difference:

https://medium.com/geekculture/ajax-polling-vs-long-polling-vs-websockets-vs-server-sent-events-e0d65033c9ba

[alexbangiyev]

@steve-todorov Consideration for WebSocket:

We have to eventually provide robust analytics to our users since this is a marketing app after all. Real time deliverability data and also data like link click through rates would be a huge plus for our clients. We could show them this data without websockets if they refresh the page of course, but seeing the updates live would be really nice.