Should a push hold data or make the receiver trigger an API call?

Question

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.

• Kasey Speakman: 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.
• Machado: As always, "it depends". Christophe's answer is a very good one. :)

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:

• reconnects (with SSE) and closed client applications
• network quality issues when transmitting large sets of data that would make postponing the transmission a more pleasant alternative (or take into account huge roaming costs when using a cell-phone abroad...)
• ignore obsolete results
• if server side constraints do not allow full-duplex or require to go over http

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

• sp00m: Excuse my ignorance, but what is SSE?
• Laiv: I think it's Server Sent Events
• Christophe: @sp00m Server Sent Events (W3C - Here a short tuto and another article
• Laiv: 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.