Fetch Solution

[00:00:00]
>> Kyle Simpson: So we're gonna use the fetch command and we're gonna fetch from,
>> Kyle Simpson: /get-records, is the URL, and that's gonna give us a result. And if that result and comes back correctly and it’s okay. There’s a couple of different ways to do this. You could either say res.okay which just tells you whether or not it was successful or you could look at the specific status code if you wanted to.

[00:00:32]
I used to do the status code cuz I cared a little bit more specifically but now I kind of just tend to do res.okay. And if that was true, we still don't have the full response yet. This is something interesting about the way fetch works, cuz fetch first does a request, and then you have to wait for the body of the response.

[00:00:54]
And that allows you to basically do some streaming processing on a response body, if it were large. So we only care about a json response, so we're just simply gonna say, records = res, no, we're gonna await res.json(). That takes the body and parses it as json and gives us that json object back.

[00:01:17]
So if records and records.length is greater than 0, then what we wanna do is call renderRecords with it.
>> Kyle Simpson: We didn't change anything about our server, so I'll leave it running. Gonna come over here, and I'm gonna reload to get the new JavaScript. And then we'll cross our fingers and hope that when we run fetch records, it fetched the JSON, printed the results.

[00:02:01]
I'm gonna go back and make one last change to our server now that we're seeing results and they came back almost immediately. Let's simulate that the results might be coming back a little bit more slowly if we were talking to a really far away server. So in our results here I'm going to, if you see right here, I've already got, remember util.promisify, it makes a promise from a callback.

[00:02:30]
I'm just gonna artificially insert a delay of one second into our response from the database. So I'm gonna just say await delay(1000).
>> Kyle Simpson: We're only gonna delay on the API. We're not gonna delay on the static file serving.
>> Kyle Simpson: I'll kill the server and start it one last time.

[00:03:06]
>> Kyle Simpson: And refresh, and then we'll see that when I click the Fetch Records, it takes a full second before we get a response. Simulates a little bit more like what it would be on a real website.
>> Kyle Simpson: Okay, any questions about how we've handled setting up a basic HTTP server and doing static file serving from it, as well as handling a simple API endpoint?

[00:03:34]
Yeah.
>> Student: There was a question with, if you have a lot of data, is JSON.stringify okay or would you stream that or what would you?
>> Kyle Simpson: It depends on what we mean by a lot, so if it was upwards of five to ten megabytes of JSON, I would probably still stringify it.

[00:03:57]
If we were talking about hundreds of megabytes or gigabytes of data, then I would probably look for streaming. And it turns out there are actually streaming JSON serializers and parsers. They are, it's not perfect because the JSON format is not exactly designed for streaming. So there's some convention involved in how you search up and how you have to chunk things up.

[00:04:25]
But I would probably, if I was doing a really, really large chunk of JSON getting sent to the server, I mean to the browser, anything over say ten megabytes or something I will definitely probably start streaming that up.
>> Kyle Simpson: Otherwise, the chunking that the HTML protocol already has is probably good enough.

[00:04:51]
It's probably only for really, really large payloads that you would wanna step in and do your own sort of streaming. And maybe even would stream over something like a WebSocket protocol in that case since it might be open for a really long time. So I might open up a WebSocket protocol and keep that persistent for a while, or something like that.