Before diving into code, Kyle shares his personal opinions about where Node.js sits in today's technology stack and where he sees it in the future. He sees Node.js as the "middle end."
(slow paced bass filled music) - All right so that's it for our survey of HTML5 technologies. The next thing that we're going to do is start to get our hands a little bit dirty with Node. Well we're going to move into some code there, but I wanted to take just a few more minutes to kind of the last of my lecturing, if you will, for the day before we get into our code. I want to just kind of talk to you about where Node really sits in the whole scheme of things that we're dealing with technology wise.
It's really really good at doing highly efficient communication. So this concept of WebSockets, when we talk about signaling for peer to peer, you'll see the same kind of concept. It's really really good at low latency, high throughput communications. Not so good at static serving of gigantic big files. I probably wouldn't write a CDN server that serves up giant video files based upon Node. It's not so good at that. Not that it can't do that, but that's just not its most efficient sweet spot. It's really good at lots and lots of tiny things happening all at the same time and taking advantage of the event loop, and things like that.
Communications is a great sweet spot. Anytime you're going to think anything at all about WebSockets or any of the kind of highly efficient communication that's necessary, Node should pop to the top of your head because it's going to be every bit as efficient. It really runs very comparably to the most highly optimized systems on NGINX and other things like that. It really can, and in some cases outperform them. There have been cases where people have been able to show that it outperforms natively compiled C code, and that's kind of a shocking thing to consider.
And so I came up with this idea of the middle end. I called it CVC, client view controller architecture, and this idea of the middle end is that I observe that in every one of those disparate stacks that we talk about, whether it's .NET or Java or whatever, there's a certain core set of tasks that always happens, and most of the time these core tasks are things that a front end developer needs to be aware of and needs to have control over, but equally likely those tasks are deeply embedded inside the guts of the backend of their app.
I mean there's all these multiple layers of people that feel like they need to do the task of data validation 'cause I can't trust the other guy. So there's a maxim in computer science for this that says any time there's more than one copy of something, one copy is always wrong. So the more time we repeat our data validation code, the more chances there are that something's out of sync. Something's not right and that's a source of untold amounts of problems. The same kinds of problems could be identified with templating, with URL writing, with data formatting, internationalization, all these things.
These are things that I call middle end tasks, and they're usually embedded deep within your backend, and that means that your front end developers who are the ones that need to care the most about those things. We're the ones that care the most about how information gets transferred back and forth through JSON. We're the ones that care the most about how things can be templated and presented in the front end. The back end guys don't care about that stuff. That's why they write servlets to handle it. 'Cause they're not interested in markup, but we are, as front end people. We're interested in that stuff, and yet this unfortunate paradox is that the stuff that we're most interested in is the stuff that's furthest away and most abstracted away from us in the stack.
That to me seems a somewhat more plausible conversation to have with a team. I don't know, you may work in a job where they'd still laugh at you, but it seems like a little bit more plausible way to go about it, and see you do that, you prove it, and you say let me prove it, let's try it for six months and see if it works, and then once you've proven that, then you can come back to him and say, okay why don't we talk about data formatting, and our internationalization rules? How about we put that in the middle end? And then how about we take all that templating crap that you've been doing, and we put that in the middle end? And then how about we talk about URL routing, and we put that in the middle end, and pretty soon you have a nice well formed architecture where the front and the back end don't have to worry about each other because the buffer zone, the middle end, is where all of that important stuff happens.
- HTML5 facades
- Using APIs
- File I/O
- The asynquence library
- Publishing npm modules
- Grunt and Gulp
- Node as a web server
- Simulating asynchronicity
- Making a socket connection
- User-triggered messaging
- Signaling and data channels