Requests & Responses

[00:00:00]
>> Why does this approach break down? Why not just go further with this? You heard me talk about a little bit. But yeah, so this is cool when you're building something trivial. And maybe it's even preferred, maybe if you're just building something small, maybe this is cool. There are some environments where you're limited on resources.

[00:00:22]
If you've ever built a serverless function on a CDN, your file can only be so big, so maybe the leaner, the better. So maybe there are times where this is fine. You don't mind doing the hard work cuz installing something is just not worth your time. Okay, that's fine.

[00:00:37]
But for the most, if you're gonna build something that's gonna be used by someone, you probably don't wanna do this. If you are gonna build something that's gonna be used by a team, you definitely don't wanna do this. Imagine working on a team with ten people with all different opinions on how a server should handle routing.

[00:00:54]
And because there isn't a framework, you could do whatever you want. You're gonna have ten different versions of routing. It's gonna be weird. And eventually, you're gonna sit down like, all right, we need to figure this out. How are we gonna do routing? Okay, now, you're building a framework.

[00:01:06]
So again, don't do the framework, just use the ones that are out there.
>> I don't know if you're gonna get into this, but there's a couple of questions around the request and response object and what you can do with them. How that gets passed to that callback.

[00:01:24]
>> That's a great question, let's do my favorite thing in the world, console.log. [LAUGH] Just to show you, cuz I honestly can't tell you all the things you can do because there's just so many. So I'm just gonna log the request object, and we'll log the response object, and then we'll take a look at it.

[00:01:42]
And you can kinda get an idea of what's there, and then I'll talk about how they get there. So let's do that. Okay, yeah, let me keep scrolling, here we go, not there yet, it's almost there. Okay, there we go. Okay, yeah, so when it comes to networking, there's so many [LAUGH] nuances and things that go into it from headers to authorization to just, I mean, it's just so much.

[00:02:16]
And then you tie into all the stuff that notice decorating this stuff with. So basically, what can you do with an incoming request? The answer is pretty much whatever you want. You have access to the IP address that's making the request. You have access to how big the request is, when it came, who is it?

[00:02:36]
You could pretty much do whatever it is you want with the requests, that doesn't mean you should. Response is typically only used for responding to the request. So it's definitely more limited than our incoming requests. Since request is meant to be read, you can change the request, you can modify, you can do whatever you want because it's only for the server.

[00:02:57]
And in fact, there's billion dollar companies whose jobs, whose products log requests and they do stuff for it. If you ever use any logging platform that monitors your APIs, yeah, they're just looking at your request, and do an introspection on it, and surfacing interesting things for you to look at on a chart, right?

[00:03:17]
So you can do some pretty cool stuff with a request. Response is just for sending things back. And then how do they get passed to the callback? Well, that is the job of this HTTP module. When it creates a server, it's basically saying, you can think of it as an event-driven architecture.

[00:03:34]
So when someone makes a request to a server, that's an event. Just like if you were to make a button.addEventListener, right, you would say I wanna add an event listener on this button. And the event that I'm gonna register for is called the click event. And when a click event happens, run this callback.

[00:03:49]
That's the same thing. The event in this case will be an incoming request. And we want to run this callback when the request comes in. And just like in an event in the front end, where you would get the event object that you can use inside the callback, we get a request, which is the thing that made the event, and then we get this ability to respond to it.

[00:04:11]
And we need this response because without this, how would you respond back? Your server's gonna get millions of request. How would you know which request to respond to? This response objects is scoped to the incoming request. So if this function runs a million times per second, this response object is guaranteed to be scoped to this instance of the request that's running.

[00:04:34]
If that makes sense.
>> Why didn't this request show in XHR under DevTools?
>> Yeah, this request didn't show in XHR in DevTools because we didn't make an XHR request. So XHR request is explicit. I mean, you would literally have to call XHR in JavaScript. Or maybe it shows and fetch when you do JavaScript, but this isn't a website that we made, in fact, this isn't a website at all.

[00:05:01]
It's just nothing. It's just Chrome saying I have nothing to show you because the server sent me nothing. So it's not an XHR request. No different if you went to any other website, like github.com and hit Enter, that's not an XHR request either. That's just the browser making a Git request to try to load up some HTML on the page.

[00:05:19]
We didn't send any HTML back. We sent nothing back. So the browser's like, well, I don't have anything to show you, so you're just gonna look at this white screen. We don't have any client side JavaScript making an API call. So therefore, it's not an XHR request. But if you do go to the Network tab, you will see that it was a request.

[00:05:38]
It'll be the only one there, most likely. Let's refresh this. Right here, you can see right here at localhost 200, type document. This is the request right here, but it's definitely not XHR cuz there's no JavaScript here. We didn't call it.