This is great. Love the node server with no framework, and the UI with code snippets during demo. Learned two new things (headers arrive before body + how simple streaming responses can be) in 6 minutes. Really nice job here, thank you!
This actually opens way to a super cool optimization. If the status code is not 2XX, there's a chance some APIs return an entire web page (like Microsoft Azure with 503 errors) waiting to retrieve that entire self-sufficient HTML document is such a waste of time. Rather, you can then flush it out and carry on with your other tasks
tldw the first await just waits for headers, then the second waits for the body, because its parsing a response stream (bytes come in incrementally) not the entire payload at once
Really like videos like this, going into detail on specific, small things in web development. So many other videos out there are general overview courses, but for us junior devs these type of videos are gold to expand are knowledge
Thank you very much this video, learned a lot, I was constantly being disturbed by the thought that why do I have to do the await two time, but now I know. Thanks to you
I dont use javascript but I was using one rust library that has basically the same structure of awaiting twice. I did not understand why it did that, I could only think that they made the decoding asynchronous but that would be so weird. Now I think I know why they did the same thing.
...just finished watching Lost, cool to see John Locke is coding now! Seriously though, good explanation, I never gave thought to why I had to await the `.json()` call, just figured it was some backwards-compatibility quirk..
I'm not gonna watch this video, but it's probably because one await is to see if/when the endpoint responds and the other await is for the response to finish.
While your video is correct in all the technical aspects it does not in anyway answer the question proposed. Maybe your point was to discuss other subjects tangent to the original question and that's valid. But the real reason it's split into two awaits is because it allows you to split up the work or ignore the body if it's not needed this gives more flexibility and possible optimizations it has direct connection with the size of the body or the headers.
I mean he does answer the question though. What you are answering is why the functions were potentially designed the way that they were. The answer to "why do we need to await response.json()" is simply because it converts the body to json, and the body of the http request may not be ready yet when the promise from fetch() resolves. The answer to "why were the apis designed this way" is what you said, as it gives more flexibility and possibility for optimizations.
@@thesquee1838 his question is why are they two. To answer that you need to look into what are the differences between having one or two awaits. A short header and longer body can absolutely be handled in one await and it is in plenty of implementation so his answer does not in any way answer the original question even though it's an excellent look at long response times.
Learned something. I always thought the first fetch was resolved as soon as the connection is established. Didn't now it resolves when the headers have arrived
How does JS know when the async for loop is finished? Does it check whether the "body" property is bound to a promise? Or maybe the "body" property is a Promise type and it gets converted into a blob type (or whatever JS type that is) only after it has been awaited so that typeof(response.body) is a promise and typeof(await response.body) is the actual body?
... which begs the question, what if all you want is the Header information? Can you then send a cancellation token after getting the response so that the server can dispense with continuing its response of the body?
This is also why the fetch request usually needs to be wrapped in a try/catch. If the server responds with a 4XX instead of a 2XX code, there will be no json for the .json() method to parse on the response and your app will crash.
it's the design choice to make decisions based on the returned status code or header content immediately, sometimes you might wanna use that info before deciding to json() it
One of the obvious reasons is that the body could be a file larger than your entire RAM, so it wants you to get the headers (including Content-Length) and make a decision: do you want to download it in one go, using one of the "easy" functions like .bytes() or .json(), or would you rather download it piece by piece, using a ReadableStream object.
Doesn't that make response read unatomic? You're supposed to read the whole response as a whole thing or not read at all, but here it seems that there is a possibility of reading the headers and failing to read the rest of the body.
I think it was not correct in my opinion First await (await fetch()): You get a Response object with: Headers: Accessible via res1.headers. Status Code: Accessible via res1.status. Body (in raw form): Not yet directly accessible. Second await (await res1.json()): You parse the body (which is likely in JSON format). This returns the actual data (in the form of a JavaScript object or array). So, with Axios: One await (or .then()) is enough to access both the headers and the parsed body (JSON data). You don’t need a second await or additional parsing step like res.json().
But I wonder why doesn't fetch, like fetch the whole response along with data and everything, and still why does json need await, does fetch like return headers and then on sync function collect data and json promise resolves once data is done?
Fetch does fetch the response, just not eager loading/ instantiate the object right away. Deserializing need compute time. Also, failing to get the response and failing to deserialize it should be handled separately
Ok, I was checking out that chat GPT uses post request instead of a web socket but I was wondering that how they are able to send the data character by character. I think this explains how.
I’m guessing fetch continues to get the body whether json has been called or not? Or does it wait for a call to json to get the body? It strikes me waiting would be risky since the connection could be lost, and also inefficient.
is not up to fetch really, the operative system is the one handling the tcp connection, if the user app stops reading from the socket, the os will stop acking the other end, but some amount will be buffered whether you like it or not (is its a small request, most likely all of it)
@@tomontheinternet That's probably because most of us are playing our music and this mixes with the one you put on. Also there's a lot of people who dislike instrumental music. I personally like it.
dude is doing the lords work fighting against JS-Terminators
Before you attack this man, please, AWAIT...he is a good man
I can tell he's a good man almost right away, but I needed to await to see what his content looks like.
.then(() => "I agree")
@@theyayaa nah, I had to Text decode his stream
not just once but twice, AWAIT... AWAIT...
Do you Promise?
This is great. Love the node server with no framework, and the UI with code snippets during demo. Learned two new things (headers arrive before body + how simple streaming responses can be) in 6 minutes. Really nice job here, thank you!
Glad you like that. I really enjoy how much you can do without pulling in libraries, especially for demonstration apps.
@@tomontheinternetI agree! And we can do a lot with vanilla js in the frontend without frameworks :)
I love this kind of DETAILED explanation ❤
Dang, what an illustrative demo.
Bro went deep but explained everything crystal clearly. Hope you make more videos like this. Hats off.
This actually opens way to a super cool optimization. If the status code is not 2XX, there's a chance some APIs return an entire web page (like Microsoft Azure with 503 errors) waiting to retrieve that entire self-sufficient HTML document is such a waste of time. Rather, you can then flush it out and carry on with your other tasks
Very cool explanation, thank you! I am also getting attacked by killer robots when I code
Glad I’m not alone
This is great we need more depp knowledge like this. It's a request form you sir.
'텀' wasn't just a designed logo, it was intended Hangul.. That's lovely.
And this video was helpful for me. Thanks 텀.
tldw the first await just waits for headers, then the second waits for the body, because its parsing a response stream (bytes come in incrementally) not the entire payload at once
That’s right Ligma Schlong!
❤❤
Thanks, Ligma Shlong. It's what I suspected, but the HTTP hint at the start threw me off
Thank you Ligma Shlong!
Ligma Shlong da real MVP
Definitely didn't know this before watching this video, I just accepted that awaiting JSON is what you had to do. Nice video!
You're an amazing teacher; thanks for the great explanation and focusing on the "why" behind things.
simple and to the point, thank you :)
Already knew that, but the way this video explained was so entertaining! Really great work!
Wow, I had no idea and I've been using Node for 5 years. Great video!
Really like videos like this, going into detail on specific, small things in web development. So many other videos out there are general overview courses, but for us junior devs these type of videos are gold to expand are knowledge
Practical explanation is really amazing...
I didn't know xou could create a textdecoder and read the stream, very cool. I would have probably used SSE before this video
love these type of videos with showcasing practically. thanks for the video. great work
Thank you very much this video, learned a lot, I was constantly being disturbed by the thought that why do I have to do the await two time, but now I know. Thanks to you
waaaait a second! it's 텀! wow. I'm surprised as a Korean. I thought I saw illusion, so I had to rewind and play it again. LOL nice to meet you 텀
You explained very well. Nice. Long time ago i had hard time to understand this.
Short and to the point, great video.
I dont use javascript but I was using one rust library that has basically the same structure of awaiting twice. I did not understand why it did that, I could only think that they made the decoding asynchronous but that would be so weird. Now I think I know why they did the same thing.
I haven't thought about that. nice man simple clear crisp details 👌
...just finished watching Lost, cool to see John Locke is coding now! Seriously though, good explanation, I never gave thought to why I had to await the `.json()` call, just figured it was some backwards-compatibility quirk..
Thank you so much, I did not know you can listen into body stream.
Great video
This is beyond informative! Thank you!
XD the end of the video when it cuts exactly when is talking about the quality... makes me laught as fk
Perfect explanation, Thanks a lot!
So why there is not second await on axios? (maybe both are combined?)
Axios doesn’t use fetch internally, it predates fetch even existing by a few year, it is based on XMLHttpRequest
Thank you so much for sharing this learned something new.
thank you kind sir for this byte sized knowledge stream
realy nice content, very good example for something that i just had a concept about, now i'm a subscriber
I'm not gonna watch this video, but it's probably because one await is to see if/when the endpoint responds and the other await is for the response to finish.
Great explanation, thank you
What is this theme of your terminal? I really like it) Is this something like OhMyPosh or Neovim theme?
Really great video but the last 5 seconds got me subscribed
Your Neovim setup looks gorgeous, could you share your dot files?
github.com/tom-on-the-internet/dotfiles
Enjoy!
While your video is correct in all the technical aspects it does not in anyway answer the question proposed. Maybe your point was to discuss other subjects tangent to the original question and that's valid.
But the real reason it's split into two awaits is because it allows you to split up the work or ignore the body if it's not needed this gives more flexibility and possible optimizations it has direct connection with the size of the body or the headers.
I mean he does answer the question though. What you are answering is why the functions were potentially designed the way that they were. The answer to "why do we need to await response.json()" is simply because it converts the body to json, and the body of the http request may not be ready yet when the promise from fetch() resolves. The answer to "why were the apis designed this way" is what you said, as it gives more flexibility and possibility for optimizations.
@@thesquee1838 his question is why are they two. To answer that you need to look into what are the differences between having one or two awaits. A short header and longer body can absolutely be handled in one await and it is in plenty of implementation so his answer does not in any way answer the original question even though it's an excellent look at long response times.
Wow You gained a new subscriber
That was very informative, thank you
Learned something. I always thought the first fetch was resolved as soon as the connection is established. Didn't now it resolves when the headers have arrived
Quality video, thanks :)
How does JS know when the async for loop is finished? Does it check whether the "body" property is bound to a promise? Or maybe the "body" property is a Promise type and it gets converted into a blob type (or whatever JS type that is) only after it has been awaited so that typeof(response.body) is a promise and typeof(await response.body) is the actual body?
I actually liked the music tbh
Keep posting more such stuff
... which begs the question, what if all you want is the Header information? Can you then send a cancellation token after getting the response so that the server can dispense with continuing its response of the body?
Use the HEAD method instead of GET
I get it now. Great explanation
Interesting video, thanks!
really dig ur nvim conifg
This is also why the fetch request usually needs to be wrapped in a try/catch. If the server responds with a 4XX instead of a 2XX code, there will be no json for the .json() method to parse on the response and your app will crash.
This video is awesome. I'm learning new things. One more subscribe for you.
thanks for the lesson!
So well explained
I learned stuff today!
But why doesn't fetch wait for body? What does it accomplish with this way
It’s in the video my programmer
it's the design choice to make decisions based on the returned status code or header content immediately, sometimes you might wanna use that info before deciding to json() it
One of the obvious reasons is that the body could be a file larger than your entire RAM, so it wants you to get the headers (including Content-Length) and make a decision: do you want to download it in one go, using one of the "easy" functions like .bytes() or .json(), or would you rather download it piece by piece, using a ReadableStream object.
@@СергейМакеев-ж2н it's JS, i think we already know the answer
What do you use for recording? Quite cool that you can drag the webcam window during recording.
I’m using Cleanshot X on Mac. It’s a great program.
Doesn't that make response read unatomic? You're supposed to read the whole response as a whole thing or not read at all, but here it seems that there is a possibility of reading the headers and failing to read the rest of the body.
Then my next question is why does the fetch returns with headers and not just wait until the response is ready?
If I could guess I wouldn't be watching this video 👁👄👁
i was literally thinking about this today 🤣
Is there a chance that server sends 200 first but something happened while sending body and server error or bad request occurs
Never knew for await is a thing in JS
I think it was not correct in my opinion
First await (await fetch()):
You get a Response object with:
Headers: Accessible via res1.headers.
Status Code: Accessible via res1.status.
Body (in raw form): Not yet directly accessible.
Second await (await res1.json()):
You parse the body (which is likely in JSON format).
This returns the actual data (in the form of a JavaScript object or array).
So, with Axios:
One await (or .then()) is enough to access both the headers and the parsed body (JSON data).
You don’t need a second await or additional parsing step like res.json().
Pretty Neat. Good one. 🎉
Great video!
Always wondered why there is no asynchronous JSON.parse. If we need to parse a very large JSON, our application will hang
I think the parsing has to take place on the main thread. I’m sure there are optimizations the browser could do though
Video cut off right at the end during the call to action.
Other than that great vid!
what terminal are you using. it looks super cool
great video, subscribed
Worth a sub!
Always wondered how that worked.
But I wonder why doesn't fetch, like fetch the whole response along with data and everything, and still why does json need await, does fetch like return headers and then on sync function collect data and json promise resolves once data is done?
Fetch does fetch the response, just not eager loading/ instantiate the object right away. Deserializing need compute time. Also, failing to get the response and failing to deserialize it should be handled separately
Ok, I was checking out that chat GPT uses post request instead of a web socket but I was wondering that how they are able to send the data character by character.
I think this explains how.
nice insight
Very interesting! 👍
Great vid man
what font is that in your editor?
IBM plex mono
what happens if the response is cancelled before completing? would it still be a 200?
yes, but the promise for json/blob/text would be rejected with some error
Let him end his sentence.. please 😭😭
I’m guessing fetch continues to get the body whether json has been called or not? Or does it wait for a call to json to get the body? It strikes me waiting would be risky since the connection could be lost, and also inefficient.
is not up to fetch really, the operative system is the one handling the tcp connection, if the user app stops reading from the socket, the os will stop acking the other end, but some amount will be buffered whether you like it or not (is its a small request, most likely all of it)
Can we use this ?
await fetch("/json").then(res=>res.json())
Yes, functionally that is the same thing
Those are kinda two awaits with only one await keyword, same-same
very cool!
Thanks
second approach is like SWIFT doing a async api call. and streaming data is nice, like a real chat app
I dont get it, so why would you want to do it the stream way? What's the pro?
nice content, ty
You earned a subscriber ❤️
Great video, put please get rid of this annoying background music!!
Yeah, maybe the music is annoying.
People reading this comment, please let me know.
Should I have music?
Why?
Thanks!
@@tomontheinternet Honestly I like the music
@@tomontheinternet Which music we are talking about ? 😅 I was so focused on content that I didn't hear it.
@@tomontheinternet I realized that there was music when I read the comment
@@tomontheinternet That's probably because most of us are playing our music and this mixes with the one you put on. Also there's a lot of people who dislike instrumental music. I personally like it.
Love it
love the video
background music is so nice
first time here
❤️🔥❤️🔥
Why was the ending so abrupt, hahaha
Useful info. However your video ended mid-sentence
the ending!! LOLLLLL
Can I find this theme for VSCode?
What is the name of the font you use sir ?