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.

  • 2
    You would use the latter for "chatty" communication. Notify the client that something happened and maybe the type of thing it is. Then let the client decide when to call back to the API. Sep 19, 2017 at 14:27
  • As always, "it depends". Christophe's answer is a very good one. :)
    – Machado
    Sep 19, 2017 at 19:48

1 Answer 1


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.

  • 1
    Excuse my ignorance, but what is SSE?
    – sp00m
    Sep 19, 2017 at 18:31
  • 1
    I think it's Server Sent Events
    – Laiv
    Sep 19, 2017 at 18:41
  • @sp00m Server Sent Events (W3C - Here a short tuto and another article
    – Christophe
    Sep 19, 2017 at 18:41
  • 5
    Just one consideration. If you go #2 (API calls after the notification), be sure that your server-side can handle a wave of requests as large as the number of targets of the message. I have seen waves of +30K concurrent requests, doing acknowledge of receipt, knocking down the server.
    – Laiv
    Sep 19, 2017 at 18:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.