Real-Time Web with Node.js Node.js Observations
This course has been updated! We now recommend you take the Complete Intro to Real-Time course.
Transcript from the "Node.js Observations" Lesson
>> Kyle Simpson: All right. So that's it for our survey of HTML 5 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.
[00:00:24] 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. This is firmly in the realm of Kyle's own personal opinions and my own take. I in no way shape or form do I represent any official stance and moreover I'm not even very liked in the node standards community so they probably would disagree with me.
[00:02:26] It doesn't mean that that's where node sweet spot is. So, if it's not zero and it's not infinity, where is the middle ground? What does node do well? The first thing and this is the reason why we're spending most of our time today thinking about it from the perspective of communication technology.
[00:02:42] It's really super efficient at communication. It's really really good at doing highly efficient communication. So this concept of web sockets when we talk about signalling 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.
[00:03:04] I probably wouldn't write a CDN server that serves up giant video files based upon node. It's not so good at that. It's 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.
>> Kyle Simpson: [COUGH] Communications is a great sweet spot, any time you're going to think anything at all about web sockets or any of the kind of highly efficient communication that's necessary. Nodes should pop to the top of your head because it's going to be every bit as efficient.
[00:04:23] Remember I've been in this industry, have worked in lots of jobs I only recently in the last couple of years became a teacher. So I got 13 years of working in all the crappy, corporate jobs that all of you work in. And I know what it's like when you get really excited about something but the reality is that it doesn't fit with where you're working.
[00:08:38] PHP runs the completion, it sends out a response and it shuts itself down. There's no you know persistent memory mothership thing like there is in Java where it can manage stuff in memory. It's just, it's a per request sort of thing and I thought, well, then I probably need a Java Script engine that can be spun up per request.
[00:08:57] So when PHP comes in and sort of the CGI model, I could spin up the Java Script engine, run some code to generate a template, shutdown the Java Script engine and take the string and ship it back out to the browser. So I started exploring. What would that look like?
[00:10:07] 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 back end of their app.
[00:10:49] And then we of course we can't trust what comes to the browser so we write it again in our application layer. And then the database guys flip us off and say well I don't even trust the application layer so I'm gonna rewrite it in a stored procedure Inside of the database and then who knows what else?
[00:11:03] I mean there's all these multiple layers of people that feel like they need to do the task of data validation cuz I can't trust the other guy. So there's a maximum computer science for this that says anytime there's more than one copy of something one copy is always wrong.
[00:11:18] So the more times 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.
[00:11:37] These are things that I call middle end tasks. And they're usually embedded deeply within your back end and that means that your front end developers who are the ones that need to care the most about those things. We're are the ones that care the most about how information gets transferred back and forth through JSON.
[00:11:53] We're the ones that care the most about how things can be templated and presented in the front end. The backend guys don't care about that stuff that's why they write servlets to handle it cuz 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.
[00:12:16] And I think, that's an architectural problem that we need to solve. So the ideas of middle ender coud we surface, these middle end tasks into a middle end tier. These things like data validation and routing and templating and so forth, could we put them in a middle end tier?
[00:14:36] And then we'll run it inside in Node.js and we'll use the exact same code inside of the browser and now we have one location. A source of authority for our data validation rules. That to me seems like a somewhat more plausible conversation to have with a team. I don't know.
[00:14:51] You may work at a job where they'd still laugh at you but it seems like a little bit more plausible of a way to go about it and see you do that you prove it. You say let me prove it. Let's try it for six months and see if it works.
[00:15:00] 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?
[00:15:13] 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-end 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.