Abstract:
We all know the benefits of adding realtime interactive functionality to our web apps, right? But with so many realtime web technologies available how do you know which ones to use in your new or existing web app? Phil will explain why adding realtime data and interactive functionality to your web app is beneficial (just in case you don't know). We'll then take a brief tour of the history of realtime web technologies in order to understand how we got where we are today before diving in to what realtime web solutions are available, and the key points you should consider, when building a web application on some of the most common technology stacks.
* This is FOWA organised by Future Insights
* In order to embrace the future we need to understand the past
* HTTP - Client-driven request response
* Applets - long-held connection; server -> client comms
* Push - server -> client comms with no plugins
* By 2000 we had the Realtime Web
* But it wasn't until recently that the term went mainstream
* Friendfeed
* In the past we'd wait for Google to index
* Some will argue that realtime web technologies aren't really realtime.
* The main thing is that the data related to an event is delivered so it still has context
* Realtime web technologies allow you to achieve and maintain context
* e.g. growl notifications
* Live stats
* Live blogs
* Also an example of 2nd screen
* And you can also see how this ties into betting scenarios
* Built by Aqueduct
* At face value this isn't the most interesting of slides
* It's taken me a while to work out why this is valuable - to understand why it's more then just a gimick
* It gives you the opportunity to see the result of doing something - instantly!
* It gives you the opportunity to react!
* From this UI you can start interacting with trade systems and traders
* This leads me to the one of the core concepts when using Realtime Web Technologies - Interaction
* Twitter
* Facebook
* Communiation platforms
* Polling at regular intervals can be inefficient
* Using a realtime web technology will be:
* Stable
* More efficient
* Require less code and less maintenance
## We still need the hacks
* WebSocket
* EventSource / Server-Sent Events
* HTTP Streaming
* HTTP Long-Polling
* HTTP Polling
**Managing this is hard!**
* It should be as simple as this
* Similar to PubSub, but fundamentally about changes to data structures
* Could be achieved with a PubSub solution, but you need to think about the data and structure changes
* Background
* Convinced realtime functionality is important
* How do you choose your tech stack?
* No!
* It's an option, but don't straight away assume it's the only one.
* So, that makes choosing much easier. Right?
* So, how do you filter this down?
* XSockets - Uffe Björklund and Magnus Thor
* Going back to the 4 data paradigms:
* Do you want a few simple streams of data - onMessage
* Are there multiple streams where the app chops and changes the information it wants - PubSub
* Do you need bi-directional communication?
* Are you effectively manipulating a share data structure - sync
* Or are you trying to provide access to server functionality in a more elegant way - RMI
* ITV News - PubSub
* Man City - PubSub
* Google Analytics: Realtime - Data Sync
* Cloud 9 - Data Sync
* FourSquare
* Caplin Trader - PubSub
* Chat - JabbR - Uses RMI - feels like it should be PubSub
* Google Docs - Data Sync
* Murally - Uses PubSub - feels like it should be Data Sync
* SockJS - focus on simple connections
* Some solutions offer PubSub and data sync
* Dropbox - offer simple DataStore API
* Only know a few RMI options
* New solutions: Meteor, DerbyJS, SailsJS - maybe a new category for these?
* Less initial overhead - quick Integration
* As project grows complexity increases
* Updating request/response cycle may impact realtime functionality and vise-versa
* Likely that the web server is handling load of both standard HTTP and realtime i.e. WebSocket, Server-Sent Events, HTTP fallbacks
* Generally agreed that a loosely coupled architecture is going to be easier to change and maintain
* Your DB may even be message-queue-capable e.g. Redis.
* So you simply need to hook your realtime server into that
* Web App for HTTP
* Realtime for realtime functionality
* Scale-out realtime server in the same way as web server
* Load-balancing connections
* Maintaining state of connections
* Synchronising data between nodes
* Mapping connections to users?
* Dedicated hosted service will offer :
* Make things easier and faster
* Reduce scaling complexities
* Natural loose coupling via an API
* Where is your value?
* Features v Infrastructure
* A Framework where you can self-host
* Or hosted service: a BaaS where your can focus mainly on front-end functionality
* In both cases: Realtime is baked in
* In some cases even HTML templating will be baked in
* and those templates will auto-updated when you update data structures
* Will "Realtime" simply become an expected piece of functionality in the same way we expect to be able to persist data?
* Realtime is used in some of the biggest and most successful apps right now
* It's easy for your to use it too - if you're not already
* Lots to consider when choosing a framework
* Hopefully this talk has given you a better understanding of the uses and considerations:
* From functionality to architecture, languages to platforms
* It's a really exciting time to be using this technology: we are in the future already!