Nice! As someone who's been getting by using only the bare necessities in Chrome DevTools, I've been on the lookout for something like this to help me get more out of it. Thanks, Paul.
I've been reading "JavaScript Web Applications" by Alex MacCaw and it provides a great introduction to MVC and a number of popular client-side frameworks. It also contains a ton of best practice advice for general JavaScript development. Definitely worth checking out.
Nice suggestions. I'll have to give Pusher a try one of these days. I've actually worked with the homegrown approach before, having my client connect to websocket endpoints that subscribe them to a redis channel where real-time updates are published as events occur within the system.
One thing that's often bothered me about that approach is how I've handled both websocket and RESTful HTTP endpoints from a single server. The solution mentioned by OP could go some way to allowing me to move the websocket/push handlers off to a dedicated server.
This 'push server' might consume the REST API exposed by my HTTP server to set up webhooks. It could then forward information coming in on the hooks to the client, using some push mechanism, be that websockets, Pusher, whatever.
Enjoyed your post. First-time posting here on HN so pardon any noobish remarks that follow ... I definitely like the idea of exposing webhook/subscriptions via REST in this way. Do you have any thoughts on how rich client-side apps (e.g. a Backbone app) could get the real-time benefits of such an API? It's my understanding that real-time updates will be POST-ed to a user-defined hook URL, presumably hosted on a server that is maintained by the API consumer. Maybe I've got it all wrong?