Transcript from the "Node Perspective" Lesson
>> Kyle Simpson: So I wasn't really sure if node was gonna catch on for what I was thinking. And it wasn't until about a year or two later that I realized, why is node so important? Why is it so tremendously transformative? And it's the message that I wanna share with you to frame our discussion today.
[00:00:39] Ryan said out, as I've heard him say, I don't personally know him but as I've heard him say, Ryan set out to build high throughput, low latency socket servers, his idea what we might call like nano or microservices. Now he's idea of system architecture was that a system was comprised of a bunch of tiny little single purpose socket services that all communicated with each other through very efficient network communications.
[00:01:06] And he set out to build a thing called node and the language that he knew at the time was actually Ruby. So he was building node in Ruby. It was no.rb or no.Ruby, if you will, and very quickly realized that he needed this concept of an event loop, to make that kind of a synchrony work and Ruby didn't have that.
[00:02:42] I/O bound tasks are two to three to four orders of magnitudes lower. We're still talking about milliseconds, but there orders of magnitudes lower than what happens inside of the processor. And the prevailing thought for a long time was the way you do concurrency is with threads. Well, it turns out that threads are pretty good for modeling things that are CPU bound tasks where you can take a take advantage of massive parallelism across a bunch of cores.
[00:03:12] And it's not to say that you can't do I/O bound tasks with threading, but it turns out that they're not exactly the most efficient way to do it. And I think we have a very strong argument today that the asynchronous event loop is a much more compelling model for I/O bound tasks.
[00:04:13] And that's one of the things I want you to take away from our discussion today. Is that is, I think, still one of the sweet spots for node. If somebody asked me, could you do CPU bound tasks in node? Sure, you could probably do multi processing and we're gonna actually see that at the end of our workshop.
[00:04:34] Today, we're gonna see how to spin up a child processes and work with you can probably do that stuff. But if you were gonna do a lot of really significant CPU bound tasks, I think you'd be crazy to use something like node. And this is not the right system for that.
[00:05:26] So that's one takeaway, but the other takeaway that I want you get to get is back to the anecdotal story of the middle-end stuff. I still think today that node's best story at any company that doesn't already have it, is not, or we gonna rewrite our whole architecture.
[00:05:44] I still think it's best adoptions strategy is to be inserted essentially as a middle end proxy, whether you call it that or not. To be inserted as the touch point, between any front end and whatever your back end systems are, insert a node system. Makes much more sense to me than let me go rewrite my entire back end.
[00:06:06] Now, I know companies have done that and done it successfully, and that's fine, I'm not saying anything wrong with that. But if you're at a company that doesn't already use node, and you're thinking about how can I convince somebody to use something like node if this workshop sparks some curiosity, I think one of the ways you could do that, is to pitch an idea, what if we just had our front-end talking to a node system?
[00:06:29] And what if we have the node system responsible for communicating with our backend? And begin shifting those tasks that touch the front-end into essentially into a middle-end tasks. So those are just some thoughts about node. They frame where it is positioned. We're certainly gonna start with an even lower level perspective on node, which is just using it to run command line system level tasks.
[00:06:56] If you have ever done Pearl scripting or Bash scripting before and you've dealt with hundreds and hundreds of lines of these other languages that aren't your primary language, and every time you need to touch the script, you gotta go Google the syntax for it like I have. To this day, I can't even tell you how many times I have written an if statement in Bash and I still don't know the syntax.
[00:07:16] Every single time I need to write the if statement, I gotta go look it up on Google. It's like some square brackets with a semicolon somewhere, and I get it wrong every freaking time, because Bash is not my primary language. So it's not gonna be the one that I'm most fluent in expressing my ideas in, which is why I don't like to write Bash scripts anymore.