I did my first ever TechMeetup talk yesterday in Aberdeen and my chosen subject, unsurprisingly, was The Real-Time Web. We started out discussing what real-time was, then what The Real-Time Web is and when receiving information in real-time mattered. I also went on to cover some of the key real-time web technologies including HTTP Streaming, PubSubHubbub and WebSockets and then on to real-time web services and platforms.

A big thanks to @aboynejames for suggesting I do the talk and Bruce Scharlau for inviting me along. I'd also like to thank everybody who attended and made me feel very welcome and certainly seemed interested.

Feedback

If you where there then please leave a comment letting me know what you thought or just to let me know who you are. If you'd rather email you can get me using [email protected].

Video

Here's a video of the first 10 minutes of the talk. Unfortunately the video recorder ran out of batteries.

Presentation and Notes

Unfortunately I can't find a way of showing my slide notes in the above embeded Google Presentation so here they are in pretty rough form.

What is Real-Time?

Respond or react within a predictable time after an event has occurred.

There may also be a maximum time constraint.

Because after that maximum time the information loses value and context.

Maybe we should really call it:
Right-Time

When does Real-Time matter?

When does NOW matter?

When do you think being informed of something the instant it occurs really matters?

• Critical systems.
• Live events where things lose context.
• Systems requiring synchronisation:
  The 2Screen experience e.g. TellyLinks.com
• Interactive/collaborative things e.g. chat, Google Wave, Google Docs (docs, spreadsheets, drawing)
• Sensor data e.g. Car ABS breaks
• Trading: You've got to be sure you are seeing the correct trade price in order to be able to make a decision on whether to trade or not.
• Betting: You want to make sure you bet at the right odds and you don't want clients to be able to bed when the odds have changed.

Evolution of the Web

From Pull to Push

Although I'm going to use the Web Browser as the example client the client could of course be anything. Another web server any desktop application, a mobile application, an embedded app on any device.

I'm also going to focus on HTTP but the mechanisms could be applied to standard TCP socket connections.

HTTP Pull (Request, Response)

Note: client. This can be a web browser but doesn't have to be.

1) Each request would result in a page reload.
2) Event occurs on server there's no way of the server telling the browser.
3) e.g. chat pages where you would need to click the "Refresh" button to see what other users are saying

HTTP Polling

A user hitting F5 or clicking the refresh button is one manual example.

1) REFRESH-META
2) Then frames
3) XMLHttpRequest -> Outlook web access (ActiveX object)

Check if the information has changed by polling.

The problem with this is you can easily waste requests and it can be resource intensive for both the client and the server.

A large amount of services still take this approach although the web, and the technologies, have evolved to allow for real-time push.

For quite some time I've said if a service uses HTTP Polling when push technology is available and a much better option that it's not real-time

HTTP Push

In this diagram you could replace the Client with Server. The initialization could be classed as a subscription or webhook.

Various techniques have been developed to hold a connection open to a web server from a browser.

Difficulties :

* Proxies/Firewall
* Connection reselience
* Browsers
* Messaging API