The Future of Real-Time with Guillermo Rauch

GUILLERMO RAUCH: Thank you so much. My name is Guillermo Rauch, as I was introduced earlier today, the creator of Socket.IO I was involved very early on with the Node.js community working on everything from trying bring in the core APIs to a point where they were useful to us at our first startup all the way to creating new frameworks and supporting existing frameworks. We worked with some of the greatest Node.js people, like TJ Holowaychuk and Nate Rajlich, Marco Aurelio.

And today I'm going to talk about something more encompassing and something more generic then just Node.js, Specifically about real time web applications and how I look at real time web applications. When I was just thinking about the title of my talk earlier today, I started thinking about how we don't have a definition for it or how when we say real time, we'll

think maybe about different things. And some of you might think about websockets. Some of you might think about, for example, data that refreshes over time, maybe regardless of how we convey or move that data from different points. I'll start by talking about a definition that I've come to after working with lots of different web applications. All the way before Node.js existed through Comet and all the things that we

want to do with those technologies. The first conclusion that have come to is that when people think about real time and they think about actually just moving data really fast. They think about refreshing data with minimal latency. So it's all about the user thinking that the data's not stale, that what they're looking at on the screen is a representation of the latest and greatest that's available on the server, and that that's coming with minimal latency. It's coming really fast after it gets to the server.

So if you're chatting, someone sends a message, you want to get that message to someone else as fast as possible. And the other really important aspect is that that data to the user has update automatically and uniformly. So automatically means that they're not pressing the Refresh button, for example, or they're not keeping track themselves of updating that data. And the other aspect of it is that if a portion of the screen

that's representing some data on the server updates, and there's another reference to that data within the same application, both are synchronized. So the data updates everywhere. And that all comes down to you write a web application that does never require that the user presses F5, for example. And what I like about this definition is that it's actually pretty easy to summarize it in two things, despite all those long explanations. So your time application needs to be fast,

and it needs to be self-updating. So I'll go with this definition for the rest of this talk. And just to put it in context of an example of an application that you might write, I thought about a traditional real time application, which is a stock ticker showing the value of a stock in real time. And I'll start with some simple HTML, which has summary presentation on the user's screen. And then we add some naive JavaScript

to make sure that's up to date. Usually when we approach a problem like this, it's hard to decide on what timer we're going to set on the front end. This has been a long subject of debate. For example, when you implement long polling, is how long does the polling duration need to be, or how fast do we need to try to get more data from the server? So we'll just go with 15 seconds right now. And then we assume that the server at the start of this timeline thinks that the price is 500.