Pregunta

With WebSockets, when clients should be notified that data changed, I've seen two approaches:

  1. the server pushes the data modifications directly within the push;
  2. or the server pushes no data, and the client, on receipt, triggers an API call to get the updated data.

Which one would you use, and in which case?

In my case, the server does quite a lot of computation before serving data through HTTP endpoints (i.e. it's not just "serialize this database table"), so I think I'll opt for the first approach, so that these computations don't need to be done client-side as well as server-side.

But I would be happy to have your opinions on this before proceeding.

¿Fue útil?

Solución

The following questions may influence your choice:

  • how long the server needs to compute its result ?
  • is the result for a unique request or is it broadcasted to several requesters ?
  • how large is the data (payload) to be pushed ?
  • are the clients always interested in all the results pushed ?
  • can some results be lost, or must data always be delivered ?
  • is it possible that clients loose connections or have connection quality issues ?

Based on these matters you may opt for a data push if:

  • the connections are reliable
  • or if the data is not too large
  • or if the client is always interested in the results
  • or if results need to be frequently updated
  • or if the results are needed as realtime as possible

You may be interested in a push notification or in Server-Sent-Events (SSE) in all the other cases, and for example to cope with:

Note however that SSE is not as well supported by browsers as websockets, certainly making the later the easier choice.

Licenciado bajo: CC-BY-SA con atribución
scroll top