Node Perspective

[00:00:00]
>> 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:18]
Because if you think about node as, it's just server side JavaScript, that sort of actually betrays its history. If you were to find the original node repo and go all the way back to the very beginning of the commits that Ryan was committing back in 2008 and 2009, you'd find that it wasn't even NodeJS at the time.

[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:01:27]
And so he began trying to build essentially an event loop for Ruby. And somewhere along his exploration, I don't know exactly how it happened. But somewhere along his exploration, he realized, why am I doing all that? JavaScript has it for free. And that's the fateful move. He rewrote everything to use JavaScript to get the event loop semantic built in for free.

[00:01:49]
That's why we have a Node JS today. It wasn't because he wanted to put JavaScript on the server. We certainly can use that as a justification now. But that's not what node was really built for. And I think somewhere deep in the guts of nodes, DNA still, is the fact that why node is so compelling is because it was, I think, the first time that we got a really strong compelling argument for how asyncronist communication, I/O bound tasks should be modeled.

[00:02:23]
And specifically, they should be modeled with JavaScript. When we talk about I/O bound tasks, we're talking about tasks that use the I/O subsystems of the computer. So for example, reading and writing from a disk, making network connections. That sorta thing. As opposed to CPU bound tasks, which are literally just in the CPU.

[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:03:28]
And I think it's one of the reasons. Without us realizing, it's one of the reasons why node ended up succeeding at all of those big companies. It is not the case that Netflix and Walmart and 5,000 other giant cooperation we wrote their entire part of their stuck just because they had so many people that loved JavaScript.

[00:03:49]
I'm sure there are JavaScript efficient in each of those companies but the reason they did that, but the reason they invested that much effort is not that they didn't have an existing working architecture. They rewrote and redesigned their architecture because there's some really compelling benefits when you think about modelling high throughput, low latency I/O communications the way node does it.

[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:04:49]
And I'm saying that as somebody who loves JavaScript, and I'm telling you, you shouldn't use it for that. But by the same token, if you're doing high throughput, low latency I/O tasks and you're not using Node JS, I think you're doing it wrong. Because anything that you build that isn't this, I just think it's not as compelling.

[00:05:08]
Now I know that's gonna be a very strong statement and some of you out there vehemently disagree with that. There's lots of great stacks out there, but notice a really compelling answer for that. And I think specifically know it's so compelling because JavaScript the language is so well-adapted to that kinda thing.

[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.