INSIGHT | Making the existing web real time - Guillermo Rauch (Socket.io & Cloudup)

all right uh thanks a lot for uh being here guys I understand this is the last Talk of the day um we just witnessed the repr provisioning in real time of a new projector so that was pretty cool that held us back for a little bit but no more so what I'm going to talk about today is essentially some of the fundamental realizations that I've made about real time systems after working on them for a long time um and some of the things that I've noticed that can help bu guys turn existing Legacy systems

that are not real time uh into more modern faster self-updating systems so um You probably usually hear uh real time being thrown around a lot and it's usually conflated with the technologies that we use for implementing that so you think of socket AO and you think oh it's a real-time framework and then you think of uh maybe a restful API and you think oh maybe that's not not real time so I I think

it's hard to debate the merits of a real-time system or how to implement them without specifically that just turned blue uh without specifically talking about what it is uh and and what are the defining characteristics of that system so I've come to the conclusion uh that it has to do with two fundamental things so one is uh showing data updates to the user with minimal latency this has to do with the network networks that are in place and the communication

channel that is established between a user and the server so the user has to think that the application is alive that the data that they're looking at is not stale uh sometimes you might be chatting with someone in the same room um it happens a lot of at offices these days where everyone is in a system like slack or or IRC and as soon as you are done typing you're expecting that that information will be conveyed to someone else with minimal latency um the second aspect of a real-time system is that you will

usually find is that not only is it fast at retrieving data in the sense that if you take a specific message and you measure how long it takes to get delivered it's not enough to look at just the delivery of that message and measure its latency you also need to take into account that the system that presents the information has to get the data on behalf of the user so if I'm just looking at uh the data source if I'm just looking at your web application

it should be able to absorb data updates without the user being involved so this basically means the elimination of things like pull to refresh so if I'm looking at a news feed I shouldn't be I shouldn't have to press a refresh button I shouldn't even have to think about whether there is a synchronization problem uh between my data set and that of the server so once these two conditions are um satisfied we can think of a realtime system is something that's fast and self- updating so this is a

very good guideline to go by when you're designing your own systems even when it comes to designing your UI it doesn't matter if you're uh working the network architecture or the topologies if you or if you're thinking about what the application looks like or how it behaves um it's useful to go by these two premises it has to be fast and self-updating an example that I'd like to give uh in terms of how this reflect

in a day-to-day programming task it would be implementing a very simple stock ticker uh the most naive implementation that we can think of um is starting with some basic markup that would uh represent a widget and then we create a JavaScript function that is in charge of getting the data from some restful API and it'll do this by basically setting a timer to get the data every 15 seconds um and on the right hand side I'm going to present a log of what would