JavaScript on the Server

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Douglas: That's where the stuff came from and because the beginners were writing in HyperCard we know it's easy for beginners to use event based systems and to do asynchronous programming. JavaScript is now moving to the server after having conquered the browser it's now moving to the server and it's conquering there too, which is great because it means all of the skill that we've developed and doing stuff on the browser side we can now bring those skills back to the server side it means you only need to be really competent in one language and that can help save some time.

[00:00:38]
Unfortunately what servers do is quite different than what browsers do. In fact it's so different that you need a fairly different programming model. We're doing server stuff now in node. Node implements a web server in a JavaScript event loop. It's just a high performance event pump. It's very efficient, very fast, can do a tremendous amount of work.

[00:01:00]
It does File I/O correctly for the first time. Going all the way back to Fortran and COBOL, File I/O has always been blocking, and in node we finally get non blocking File I/O. We do it asynchronously so when you wanna read a file, you pass in a filename and a callback function, and when the file is read, it'll call your callback function and you get the data, and it's great.

[00:01:24]
And so the programs don't block on doing File I/O because blocking would violate the law of turns and we'd never violate the law of turns. We note everything is or can be should be non blocking. Unfortunately, like everything that has anything to do with JavaScript, node doesn't get everything right.

[00:01:43]
A couple of things that I'm really unhappy about with node, is that node has a number of synchronous functions baked into the API. And these synchronous functions block everything. And so you go from having a very fast high performance system to a very slow low performance system instantly because you're blocking.

[00:02:04]
Nothing else gets to happen until the synchronous calls are done. I would like to outlaw those synchronous functions. Unfortunately, what we've seen in the JavaScript community is if you put something really stupid into an API, there are web developers that say, I have a right to use it and there are these synchronous functions in node which should never be used but because they're in node there are people using them and they violate the law of turns.

[00:02:34]
Then I don't like the requires thing because it is also blocking. The very first version of it on node was asynchronous, which is the correct way to do it and there were complaints that it's too hard, it's inside out and we only start things up in the morning when we turn the servers on and so once they get warmed up then it doesn't matter.

[00:02:57]
That's not true and then we're bringing servers up and down all the time. Anything which blocks is a bad thing. Fortunately in ES 6 we're getting a new module system which obsoletes that, so that will be better. But what we're doing, servers are significantly different than browsers. In a server we're not dealing with events we're dealing with messages.

[00:03:21]
Now message comes in from the network. We'll do something, we'll send another message out. It's all about messaging. A node server is actor like and that it's a thing which receives messages and sends messages but the simple events model that we use on the browser doesn't really fit the workflows that we do on a server.

[00:03:40]
For example, we may have things which take several sequential steps like a request comes in, we take that request, we have to send something to a database, get something back, we can take that information, we use that to go to another database and get stuff back. Each of these things depends on the previous thing.

[00:03:58]
How do you do that? If you don't know how to do it, the naive approach is to write deeply nested event handlers. In the event handler of one thing, you make a request of the next service and in it's event handler you make the request of the next one that leads to code which is extremely brittle, extremely hard to maintain, low performance, it's all bad stuff.

[00:04:21]
Then we have the opportunity to do things in parallel. It might be a request comes in and we can go to several systems at the same time because the requests are not dependent on each other so they're independent requests and by going in parallel, we get to change the performance of the thing significantly because instead of waiting for each to finish sequentially, instead of taking that much time, we only have to wait for the slowest of those things, which is usually a much shorter time.

[00:04:51]
We can significantly improve our response processing. Unfortunately, each of these requests maybe coming back at unexpected times and an unexpected orders and how do you deal with that? How do you and some might not come back at all and how do you deal with that? And so that's hard.

[00:05:10]
If you don't know how to manage that naive thing is to not do it in parallel. Instead, do it sequentially with deeply nested event handlers, which is, again, quite awful. Then in addition to that, you may have to deal with limited time. You may have SLAs or other policies which say we have to get a response within so many milliseconds and if we don't, we have to go to plan B.

[00:05:35]
We can't just keep the request hanging for some amount of time. And then we have to deal with cancellation. If we go to plan B, we want to stop all of the work which is no longer necessary. How do you do all of those things in deeply nested event handlers?