2

My app is built in Angular (2+) and NodeJS. One of the pages is basically a dashboard that shows current tasks of a company, where this dashboard is shown all day on a TV to the companies staff.

  • Rarely is it refreshed or reloaded manually.
  • Tasks are updated every 5-10 mins by a staff member from another computer.
  • Tasks on dashboard need to be updated asap after any task is updated.
  • App should limit data transfer when updating dashboard, after task update.

I initially tried websockets but had a problem with connection reliability as sometimes the board would never get updated because the websocket would lose its connection. I could never figure this problem out and read that websockets can be unreliable.

Currently I'm just running an http call every 15 seconds to retrieve a new set of data from the backend. But this can be costly with data transfer as the app scales.

I've just recently heard about SSE but know nothing about it.

At the moment my next plan is to set up a "last updated" status check where I still run an http call every 15 seconds, passing a "last updated" time from the frontend and comparing that to the backends "last updated" time (which is updated whenever a task is changed) and only returning data if the frontend's time is outdated, to reduce data transfer.

Does that sounds like a good idea, or should I try websockets again, or SSE?

Scot
  • 165
  • 2
  • 14
  • Why do you state that web socket can be unreliable? – Janith Sep 18 '18 at 04:05
  • You could send a ping from the web app to the server via WS, say every minute, and if that does not get a reply within a few seconds, just reconnect to the WS server, or refresh the whole page to force an app re-init. – halfer Sep 18 '18 at 08:29
  • If you want a simple gateway that keeps your dashboard updated over WebSockets, handling lost connection (and missed events), and scales, take a look at this [blog post](https://nats.io/blog/resgate_nats/). It has some node.js example how it is done. Shameless suggestion :) – ANisus Sep 18 '18 at 12:04
  • Possible duplicate of [WebSockets vs. Server-Sent events/EventSource](https://stackoverflow.com/questions/5195452/websockets-vs-server-sent-events-eventsource) – Elias Zamaria May 03 '19 at 00:13

2 Answers2

2

I initially tried websockets but had a problem with connection reliability as sometimes the board would never get updated because the websocket would lose its connection.

Handle the event for when the connection is lost and reconnect it.

I could never figure this problem out and read that websockets can be unreliable.

Don't let some random nonsense you read on the internet keep you from owning the problem and figuring it out. Web Sockets are reliable as anything else. And, like anything else, they can get disconnected. And, like many of the newer APIs, they leave re-connection logic up to you... the app developer. If you simply don't want to deal with it, there are many packages on NPM for auto-reconnecting Web Sockets which do exactly I suggested. They handle the events for disconnection, and immediately reconnect.

Currently I'm just running an http call every 15 seconds to retrieve a new set of data from the backend. But this can be costly with data transfer as the app scales.

It can be, yes.

I've just recently heard about SSE but know nothing about it.

From what little we know about your problem, SSE sounds like the right way to go. SSE is best for:

  • Evented data
  • Data that can be somehow serialized to text (JSON is fine, but don't base64 encode large binary streams as you'll make them too big)
  • Unidirectional messages, from server to client

Most implementations will reconnect for you, and it even supports a method of picking up where it left off, if a disconnection actually occurs.

Brad
  • 159,648
  • 54
  • 349
  • 530
  • Do you know if any SSE implementations can recover from events that are lost while connection is down? I've suggested using [Resgate](https://github.com/jirenius/resgate) that does, and still haven't found any other realtime web solution that handles it out of the box. – ANisus Sep 18 '18 at 12:11
  • 1
    @ANisus The browser does it for you. When it reconnects, it will send over the last ID it received, in the `Last-Event-ID` request header. The server can either ignore this or pick up where it left off. – Brad Sep 18 '18 at 13:40
  • Better handling of lost connections seems to work for me now. I just needed to understand that a little more. – Scot May 07 '19 at 15:43
-1

If you need to push only data from the server to the client, it may worth having a look at Server-Sent Events.

You can have a look at this article (https://streamdata.io/blog/push-sse-vs-websockets/) and this video (https://www.youtube.com/watch?v=NDDp7BiSad4) to get an insight about this technology and whether it could fit your needs. They summarize pros & cons of both SSE and WebSockets.

ctranxuan
  • 785
  • 5
  • 9