5:00 - 6:30 - Not a clue what Andrew just explained here, just seems like waffling... Can someone explain?

Hey James, So, basically the way I understood it was that a your incoming message depends on what side of the connect you are in. If you are on the client side your incoming message is the response from the server. If you are on the server side, your incoming message is the request (since the request is asking for something). So, the relationship is the same: something is asking something from you and its incoming. The context of what that something is depends on if you are the server or the client.

Looking at the docs, http.incomingMessage is an object created by the http.Server or http.ClientRequest which gives your a context of who is doing the asking. The docs says that the object implements a readable stream interface, so it shares the methods that are common to that as well as additional methods listed below in the docs. Within this interface, the data event is something that you can listen to. Understanding how readable stream interface clears things up.

Looking at the docs for the readable stream interface (https://nodejs.org/dist/latest-v7.x/docs/api/stream.html#stream_class_stream_readable)

">>>The 'data' event is emitted whenever the stream is relinquishing ownership of a chunk of data to a consumer.<<<

This may occur whenever the stream is switched in flowing mode by calling readable.pipe(), readable.resume(), or by attaching a listener callback to the 'data' event. The 'data' event will also be emitted whenever the readable.read() method is called and a chunk of data is available to be returned."

The data event is emitted when the stream finishes getting that piece or chunk of information for the user. Think of it as a bunch of guys working on a dock unloading boxes of cargo (each box is a piece of information from the whole shipment request also know as a buffer). All the boxes are not going to be unloaded at the same time. It is non blocking, so because the first guy getting the box is taking his time, doesn't mean that the other guys will stop working until first dude delivers his box. When one package is off loaded and placed where it needs to go the who does that screams or emits a message saying "got one box" ("or data") to alert the other guys who are receiving the box.

The box then is processed with the notes with the instructions on how to process the shipment when it gets there, aka the callback. Its basically a note saying "Hey Vinny, do this when you get the entire shipment of boxes, do x. Either unpack them, put them together, change their names and put them all together in a new box with a new label (such as a string) and send them here."

Hope this helps.

This portion of the video seems to compare "request" and "response" data events.

He does seem to be struggling a bit with the documentation, but the basic point I got from it was that the data events generated by an incoming message on a Readable Stream are handled similarly whether they come from client requests or server responses.