The Hard Parts of Servers & Node.js

Node Under the Hood Q&A

Will Sentance

Will Sentance

The Hard Parts of Servers & Node.js

Check out a free preview of the full The Hard Parts of Servers & Node.js course

The "Node Under the Hood Q&A" Lesson is part of the full, The Hard Parts of Servers & Node.js course featured in this preview video. Here's what you'd learn in this lesson:

Will fields questions about semicolon usage, port numbers, errors, the end function, and the timing of auto-running functions.


Transcript from the "Node Under the Hood Q&A" Lesson

>> Will Sentance: Let's start with, who was the first person I saw? Andrew, I'll start with you, Andrew.
>> Speaker 2: I'm noticing a lack of semicolons, are they implied, cuz it's slides, or is this an intentional, something special?
>> Will Sentance: No, darn, I almost forgot to mention that I put semicolons back on.

Andrew, rescind that question. Everybody online, semicolons matter. And actually, particularly in Node they do matter. They do matter because if you miss them off JavaScript strings constrain your code together, and lead to errors it can be quite hard to find. Ignore this very bad practice, semi-colons bad copying pasting into this presentation from the code editor.

Thank you to Andrew for actually a very helpful thing for everybody. Sara Rose, go ahead please ask me more about my body in JavaScript.
>> Speaker 3: I feel like I've seen rec resident error as a third parameter is that-
>> Will Sentance: Let's see how we handle errors in just a few slides.

No problem, great question to T out there, Rich you had a clarification? Charlie?
>> Speaker 2: Yeah, just to be clear the only code that note we'll ever have access to is what you provided in the create server function.
>> Will Sentance: Yeah, that's a good way of putting the only function code that can have an auto rock well.

On the same note as Sarah roses question. We actually are gonna see that if that request comes in very happily and successfully, cheerfully, great request, no errors. I'll give you a preview, it's actually gonna flash a little message down here saying request, which will also trigger this function.

Due on incoming but we can see that if another situation, may be an error, maybe the client sends a corrupted request it might not flash request down here. And therefore, it might not end up triggering due on incoming, but triggering something else. So we're gonna get more control than you think.

Mohammed, you're up next.
>> Speaker 2: Yeah, just clarifying the the second object is created.
>> Will Sentance: It's a weird one, right?
>> Speaker 2: Yeah, and we get to set that label.
>> Will Sentance: Weakens the label? I could call it, you know I could call it Mohammed's auto created object of function. No, not Mohammed's, Muhammad's favorite note auto created set of functions.

And as long as you then refer to it by the same label, when we want to access stuff on it. What do we try to access on it? What function are we trying to access on it, Mohamed?
>> Speaker 2: The sending back the-
>> Will Sentance: We just want name. What's the functions name?

Anyone got it?
>> Speaker 2: End.
>> Will Sentance: End, by the way, how do we know that? The Node homepage, the Node docks. It is literally got, that's where we spend most of our time. As long as we have this internal meta model that's the point of node. As long as you have this under the hood mental model, you just go to Node docs, and you go and look for.

What's the auto inserted data that when the background task finishes gets inserted? And therefore, how do I need to structure the function that I pass as the auto triggered by Node function, such that I know what I need to set parameters up. And then the order inserted objects full of in this case like multiple functions do like 20 functions.

I just get access to them by using the label I gave the second inserted input, auto inserted input, and then there's a whole bunch of function on here we just use in for now. There's other things that I write as a whole bunch of folks we can use to control specifically what we add to this message to get sent back, sounds good.

>> Speaker 2: So we'll end as take any parameter and then just send it along.
>> Will Sentance: Yeah, it's a simplifying, really it's job is to say you've finished editing the message down here, move on. Cuz typically what we do is we will use other functions in here to set on this not object, sorry, this HTTP text message.

It's a text message, set other bits of information on it. We can set the headers, we can set the body, we usually run end, or with nothing in it as the input. Cuz its only Java is to say hey node, I finished editing stuff on this message, you can send it back now, but you can also path to it.

And then want to keep it as simple as possible to start, you can also pause to it a string, and that stream will be the message that gets them back, but that's not typically how we use it. Typically, we add content to this message to send back using things like the right function here, or we can set headers on this message to get send back.

But in the end if you do pass something to it will be implicitly the data that gets sent back. It's a shorthand just of our very, very first Node server, and it is a full server that we have at least we minimize the number of new things are introducing.

We typically wouldn't use end for this, but it goes a very, very light weight of setting the data on the response message, a chippy message back. Great question Sam. We want to come back to it, Seth we have a question?
>> Speaker 2: Yeah, sure, just a curiosity, what happen if we open don't listen to the create server doing comming.

>> Will Sentance: No problem, and most people would do that. Most people would say, because what is this obvious returns an object which has got a bunch of functions on it that give us edit access over the background here. We use one of the functions, which one was it, is that?

>> Speaker 2: Don't listen.
>> Will Sentance: Listen.
>> Speaker 2: Yeah.
>> Will Sentance: But JavaScript in evaluated language, which means, this here when it returns on the object it actually gets rid of that, and turns it into this object. Meaning, you can then put dot listen on the end of it there, and you're just going to grab the listen function from that object and run it.

Jobs as an evaluate language means any statement must be eventually turned into its actual underlying value which in this case is this object. And so we can grab the missing function of it in the same line, yeah?
>> Speaker 2: So, to follow up on that question, right? You're not doing it, just because you think they're like JavaScript, it's single threaded, so it has to do different instructions.

>> Will Sentance: No, I'm doing ti for clarity, to show you that we get an object out that will allow us for the rest of time in this JavaScript thread to be able to continue to have edit access over this background feature via the label server which gives us access to the object that came out.

Yeah, I'm just doing it for pedagogical purposes. Here you go, Michael, go ahead man.
>> Speaker 2: How does the sender computer know which port to get? I know they were setting-
>> Will Sentance: I should said, I made that really, really clear it defaults to it, every browser sends our message, defaults to 80.

We don't even need to write it, we don't need to say, enter at port 80, it defaults to 80.
>> Speaker 2: So sometimes you're able to set your Node port to a different port?
>> Will Sentance: Why would we even do that? We'll see in a moment, but when we're developing we may want to change it.

Plus there are other slightly marginally different protocols, like HTTPS that there is a secure connection from our computer browser through to the web server. That would not allow others to interfere with that message being sent, sort of man in the middle they call it or person in the middle attack.

It'll block that from happening, which doesn't default to entering at 80, it defaults to entering at a different entry point. Okay, great question, yeah. Andrew, go ahead, you had a follow-up I think.
>> Speaker 2: So are we essentially saying JavaScript says to Node, Here's a bunch of functionality, hold this and do this at the right time.

>> Will Sentance: Yes.
>> Speaker 2: And then, does Node run that in the same execution context as Java Script, or is that kind of off running its own thing?
>> Will Sentance: It is coming right back into JavaScript, but then you might be saying, holy goddamn, that's an automatic inserted function back into JavaScript to execute.

In our main thread, or in our thread, in our single thread from outside of JavaScript? When the hell is that function allowed back in? What if there's 30 all want to go back at the same time? Well, they're all gonna run at the same time, right? It's single threaded, one thing at a time.

Which order do they get run in? Before the end of today we will have a full map of exactly when any auto-run function from Node is allowed to auto run back in JavaScript. Any function which we saved to Node using things like Create Service, Save the Oncoming Function in Node.

When is it allowed back in to have the purple pen, the Node pen execute its code, when? Because what if I've got a bunch of other code running here? Does it just say, hold on, stop? I'm coming back in now, I'm ready to run. Or do we need a set of strict rules for when this function is allowed back in?

And it's gonna turn out, we do.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now