[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: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: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?