Cordova: Sockets, PushNotifications, or repeatedly polling server?

Question

I have a Cordova/PhoneGap app.

I\'d like to have some semblance of real-time updates when the app is in the foreground.

What\'s the least resource-intensive

Answer 1

For a mobile device, you have a classic tradeoff between battery usage, network usage and timeliness of updates.

The push notification service built into a mobile OS is designed to try to give you the best of all these tradeoffs and it runs globally rather than per app (which is usually more efficient), though it gives you somewhat less control over implementation details.

When comparing socket.io vs. polling an API, socket.io (and more specifically webSockets) were designed to be a more efficient way of getting asynchronous notifications from a server.

In socket.io, you create a socket connection to the server. That connection stays open for the duration of your app (in the foreground) and, at any time, the server can just send you data and you will receive it immediately when it was sent. Because connections can be lost and the endpoints are not necessarily notified of that immediately, socket.io uses small heartbeat packets that are sent on a regular basis between client and server. If the heartbeat packets stop being responded to, then socket.io assumes the connection has died and will close the original socket and attempt to create a new connection. It does all this transparently and automatically for you. This heartbeat, however, has some undesirable ramifications for mobile. The data sent is tiny so it's not really an issue of bandwidth usage, but every transmission from the mobile device uses battery and that can be relevant if left to run for a long time. The heartbeat interval in socket.io is configurable. It can be turned off (not recommended) or the time interval can be set to a longer time.

Both the OS push service and socket.io are very efficient from the server-end of things because the server only does work when there is something to actually send to the client and does not have to field regular requests where there is nothing to do.

The only possible advantage of polling here would be if your desired update interval was long (e.g. once an hour) or it isn't usually on and is only used occasionally. Then, you could just send an Ajax call each hour or upon demand and the server wouldn't have to do anything except answer the occasional Ajax call. If the desired interval is shorter, then you're probably going to want to use one of the true push mechanisms (either the OS push or socket.io).

Answer 2

Use websockets.

A polling based approach introduces a minimum overhead of having to issue a request every X seconds to check for any new messages, which gives you a crappy trade-off: the lower the request rate, the less responsive your app is. xhr long polling reduces this cost somewhat by keeping an http request open for 30-60 seconds or so, allowing the server to send the response as soon as it can, but this still imposes a regular request interval to take place.

A websocket is a persistent connection, meaning a connection is kept open for each client. This means memory usage, but I wouldn't fret too much. You will bottleneck on actual message traffic before persisted connections

This is a really good read to give you an idea of what kind of scale is possible with websockets on node.js: http://www.jayway.com/2015/04/13/600k-concurrent-websocket-connections-on-aws-using-node-js/

There are lots of options out there, two I would recommend are socket.io and faye. They are both very easy to get up and running. Both will also handle things for you like defining message channels, connect/disconnect protocols, and they have the added advantage of selecting the right transport that both the client and server both support. Socket.io 1.0+ (using engine.io) for example will start with long polling and upgrade to websockets if both endpoints support it, which can speed things up. Faye is a nice lightweight pub/sub system whereas socket.io is somewhat more involved, session based offering. One or the other might be a good choice depending on your needs.

If minimizing your request load is your paramount concern, implementing websockets directly with the npm ws (which is what both socket.io and faye rely on) is also an option, but this is obviously more complex.