We also hit the API once to push out changes to the subscribed clients through the connection proxy. And the next poll has relatively minimal overhead (obviously not as small as 0) to be queued back up.
In the end, though, this obviously isn't an implementation aimed at extreme efficiency. If that were the goal we'd take a much different approach.
It is about simplicity and semantic elegance.
Does anyone know what the alternatives are? Can you avoid pooling and still speak HTTP?
HTTP by nature is request/response. To speak pure HTTP, there isn't a way around polling that I know of. Avoiding polling means implementing your own protocol over HTTP, or using WebSockets (see Comet or implementations in Socket.IO, Firebase, SignalR, etc).
It's quite easy to fall back to long polling in older browsers and it's a very simple and straight forward format.
The most interesting bit about this architecture for me is the 1:1 mapping with a pure HTTP resource. It's a bit like an implicit subscription to a pub-sub enabled resource. In this implementation we are simply calling our API like we normally would (except on the stream domain) and waiting for an update.
Websockets is a great transport protocol for bi-direction realtime persistent connections. And it's very easy to write your own application protocol or just use WAMP from http://wamp.ws.
In the early days of the realtime web, long-polling was used mostly as an underlying hack in the emulation of streams. However, RealCrowd's API isn't a hack. When clients make requests to the server, they are attempting to synchronize a resource. One could argue that this kind of interface is semantically closer to what the client is trying to accomplish than one based around pure message passing.
I'm not just being pedantic about it either. Just compare server performance of RPC over Websocket to RPC over HTTP at scale.
Long-polling with retries is not so bad though. Even with WebSockets you'd still want a periodic heartbeat. It's all the same amount of traffic really.
Even if you don't want to use a pub/sub and publish instant notifications when data is updated you could implement polling in a Node.js server and just have all the clients connect to it with Socket.io. Then when the Node.js server sees an update in the data it can push it out to all the clients.
This strategy also has the advantage that you don't have to change anything on the client if you decide to switch to a pub/sub in the future for more real time updates.
Our setup is a pub/sub system, where the "sub" happens implicitly with the request for a resource via the GRIP proxy and protocol and the "pub" happens when we update our models as well. The proxy acts a lot like node.js and Socket.IO would, but simply speaks pure HTTP on our RESTful resources instead of the Socket.IO protocol over their transports.