SocketIO and Node.js, with Guillermo Rauch

1. We are here at QCon San Francisco 2011 with Guillermo Rauch, to talk about SocketIO, Node.js, and JavaScript. Hi Guillermo, would you like to tell us a little bit about yourself?

Sure, I am the LearnBoost CTO and co-founder, the creator of a few popular open source projects, like SocketIO and Mongoose for the Node.js platform. Prior to that I’ve been involved with the web in different capacities, working as a contributor to the MooTools JavaScript framework, I’ve been doing frontend and backend for a few years, with strong focus on JavaScript.

2. Would you like to tell us what attracted you to Node.js and how you got involved in building SocketIO?

So the most interesting thing to me about Node.js was basically real-time, like I have been using different software to basically make a real-time communication possible, including modules for Nnginex that did publishe-subscribe, or Java or Python based solutions but I couldn’t find any APIs that gave me the flexibility and the ease of use that Node.js gave me. Node.js was always - their "Hello world" was always an HTTP server, so that set the foundation in my mind so I can build more complex HTTP servers on top of this that can do real time because of the non blocking evented IO. So I got interested immediately very soon after it was released because of this fact.

3. Would you like to give us a really short overview of how WebSockets work and what SocketIO is capable of with WebSockets?

Sure, so to establish a bi-directional real time communication between a client and a server there has been many different ways throughout the years, HTML5 is proposing WebSocket as the easiest and most direct way of doing this. It basically sends an HTTP handshake, it utilizes the upgrade header, it says "I’m going to make this connection a WebSocket connection" and then it uses a very lightweight frame in the mechanism for passing messages back and forth in order. And what SocketIO does is it gives you the API that looks like WebSocket and is really easy to use but if the browser or the network don’t support WebSocket, it will use other transports and this is seamless to the developer so SocketIO takes care of picking the best network transport mechanism for you while giving you the ease of use that HTML5 is proposing with the WebSocket.

4. What were the challenges you faced trying to implement WebSocket like interface across many platforms or browsers?

So, one of the focus of today’s presentation at QCon SF was precisely what the drawbacks of implementing WebSockets have been and some of them are related to existing network infrastructure that doesn’t support web sockets, like proxies, firewalls, even desktop antivirus software other issues have been related to the capabilities of browsers themselves and most of the market share of browsers doesn’t support WebSockets. So obviously we’ve been relying heavily on less optimal transports, not just in terms of latency I mean the speed at which data is sent back and forth, but also the model by which we can scale on the server. The way that we scale long poling or other transports that are not web socket on the server, are less optimal than web sockets. And what it presents is a challenge both in the client and the server we need to solve. And we’ve done that successfully so far.

5. What would you advise a team that is considering to start off on its first Node.js SocketIO project? What are the common pitfalls and problems they will be facing and how can they avoid it with best practices?

So mostly you want to focus on making your client side code really reliable and good like handling what happens if the network disconnects, and what happens in between that disconnection and re-connection, what happens if the user refreshes the browser quickly, those are issues that are not related to SocketIO but your application needs to consider for example if you are building a chat application and the user decides to open a new tab, how do you handle that? How do you make sure you sync state between tabs? And these are different challenges that depend on each application that have been explored now with SocketIO as the fundamental way of passing data back and forth. What I advise usually is look at what your application needs, look at the scaling model of your application and focus on that and not just in pre-made recipes.

6. For you JavaScript is the final language to work with what are the things that you especially like about it and what are the problems that you are having on your daily work?

The problems with JavaScript are very well known to the experienced JavaScript developer. So they don’t really affect me as much because the way I work, the way I approach a problem is already try to work around the problems that the language has, so I remember things I can’t do on IE6 and I remember what specific JavaScript features I need to use to make something run faster on all browsers for example a solution that would otherwise work to deal with functional arguments may be slower than alternatives, so you have to know all those things, so for me it’s not a problem, I can see that being a problem for people that are seeing how wonderful the world of Node.js is, but they are not super familiar with JavaScript.

And Node.js presents the opportunity to share code between the browser and the server and inevitably for many projects you get to know also what things are not supported by other virtual machines that are not the ones that Node.js runs, which is V8. Sometimes you need to know what happens with your code when it runs on a lower capable device. Some of these challenges are being addressed by harmony some of them are being addressed by languages that trans pile into JavaScript like CoffeeScript, personally I advice learning the language itself, because like I said there is many things that are useful to know if you write reliable and fast programs.

7. If you are coming from you mentioned Java and Python, I suppose also C if you have been doing things on Nginx, is it a bog problem to maintain a bog JavaScript code base?

I don’t think so. I think many of the things that come with the complexity of writing non-blocking code, also come with writing any large application, it comes with any other large application and any other stack. So for example something that helps tremendously with writing non-block in JavaScript in modularity and separation of concern and so all those best practices that you were already applying also applied in JavaScript and there are patterns that are emerging as well that the community is recognizing and tackling head on, for example error handling it is not as easy to do and easy to manage, as it would be with a thread per request if it should be server for example, however node has been tackling that problem since day one, and so has the community and so it doesn’t become a problem at all, but again even though we are dealing with JavaScript you also need to learn the ins and outs of what JavaScript means and that of course it’s a new thing for many people.

8. You talked about the challenges of writing asynchronous code, are you personally using some of those frameworks that assist you in writing, like asyncjs and others?

I personally don’t I am not especially against them, but the natural flow control of most applications that I write comes down to doing some tasks in parallel, and doing some tasks serially, and for both things it takes two lines of code, to keep a counter and iterate over functions. So I find that most async libraries would add boilerplate to me, but there are certain occasions where they can be really handy, for example an asynchronous map function over a collection and there are other use cases, however I don’t see the point sometimes in introducing an external dependency and sometimes an external almost DSL for projects when the alternative plain JavaScript solution is not that different in term like lines of code and even code clarity.

9. I watched that you were using VI today in your demo, what would be a typical tool stack for someone doing Node.js? I mean your editor; you use probably node-inspector, or something like that?

So, there is different tools for profiling, there is tools for debugging code, node-inspector is one of them, it’s really useful, personally I also, we deploy code in such a way that it gets reloaded, automatically, I think that’s really useful as well. Whenever you make a change to the server the code reloads, and like I said earlier many practices of development in general are very useful in node like for example Test Driven Development. Test Driven Development for us allows you to not having to deal with testing the serve so much, reloading and making small changes and reloading, because we basically run the tests, if they don’t pass, we don’t bother closing that particular module.

10. You made an announcement today would you also like to talk about SocketIO project roadmap?

Yes, so today I announced a project called Engine, so Engine is basically we are taking out part of the SocketIO core base and breaking it down into a simple abstraction. The socket API doesn’t change at all but what we are introducing is a more reliable way of establishing real time communication that starts with long poling first, and then it performs not just feature detection, like we have been doing to see if a particular browser has web socket or not, but we are also probing and testing those transports on the side, so we establish a connection that is always reliable, and always fast in the beginning, so if you are relying on like a connect call back, where you are trying to sync a state with a server, that happens immediately, and if the network is not capable of handling web sockets, or the browser, that’s not going to affect that initial connection time.

But if the browser is modern and the network is fine, then it’s going to upgrade to web socket as fast as it can, initially this happens immediately when there is no perception of slowness, there is no long connection time, there is no proxies blocking the traffic, and delaying the fallback, that’s what SocketIO does, so it improves reliability dramatically, it makes for maintanence of the project this way, so we are very excited about this.

11. How do you see the server side JavaScript trend evolving and especially with regards to Node.js?

So what I see happening in the next year or so is I think all these patterns that we have been doing when we create real-time applications or we create single-page apps, that don’t try to constantly refresh the browser, get all the assets again, or send HTTP requests, try to see if an asset has changed or not, so I think frameworks are going to emerge to solve fundamental problems like lazy dependency loading on the client, server side rendering of code, that also can be rendered progressively on the client, so if you go to a given page, a given URL, the server can produce a response, but if you go to that same page, by clicking somewhere it’s going to be more efficient than doing that.

So I think that’s one of the existing challenges that frameworks are going to start tackling, currently but don’t have any universal solution yet. And it might be the case that there is going to be a solution that is as popular as Rails was for Ruby, however those problems exist, and they need to be solved in a way that users don’t have to worry about the technical difficulties behind them or they don’t have to think about the difference between a website and a web app that sometimes try to be made where people say don’t render any state on the server because that’s a web app and you don’t care about SEO or other factors.

However in my experience that specific difference doesn’t really matter and there needs to be a framework that tackles this problem. Another problem of course is always writing applications that restore state so for example if you are writing a chat application what happens when you refresh the browser and you want to reload existing chat sessions? So all these problems that are tricky small things, that have a very big impact on user experience, need to be tackled by an ubiquitous framework.