Managing HTTP/2 Connections

[00:00:00]
>> The one thing I'm sparing you from doing, I think we mentioned before, is that I'm not making you write the post logic here because literally, nothing changed, right? This is exactly what you wrote in the last one. So this is already posting to the server, we just gotta make the server accepted.

[00:00:21]
So we have kind of two things that we need to do here. One, we need to accept the data. But there's another fun thing that we need to do if I have ten people all connected to the server. As soon as someone posts to the API, I wanna immediately inform all of them.

[00:00:34]
It's like, hey, I got a new chat message, right? So that if Mark post something that I can see it and vice versa. So we have to inform all those streams. So up here, you'll see that I have this connections API for you. And that's what we're going to do with that, we're just gonna keep track of all the streams that are currently connected.

[00:00:55]
So whenever a user connects down here, underneath the right here on line 53, I'm just gonna say connections.push stream. And now, this connections is gonna have all of my active connections in it. Then on stream.close, I'm just gonna say, connections is a sign and then I'm just gonna filter out.

[00:01:17]
I'm sure there's a more efficient way of doing this, but I'm just gonna say connections.filter. And I'm just gonna say I called it S here, S is not equal to stream. If you're not familiar with functional programming kind of things, but basically what we're saying is. I want you to go and remove whatever stream is from connections and then make that the new connections.

[00:01:48]
So it's just a fast way of getting stuff out of there. So if users, 79 here quits, it's gonna go find connection 79 and remove that from the active streams and we'll do that on close. Okay, and now, I'm kinda guaranteed whatever is in connections is definitely going to be all of the active streams.

[00:02:09]
Yeah, question.
>> My assumption here was that stream was an object and we're doing triple quality checks, comparing objects. Or am I completely mistaken here?
>> Yeah, so the question is this, streams is gonna be a bunch of objects which is a correct assumption. What triple equals is asking is, is this literally the same object?

[00:02:31]
Which will return true, right? Cuz they both pointed the exact same object in memory. It's asking us, are these the same pointers? And they are the same pointer. That answer your question? It's a good question. Yeah, thanks for clarifying, I'm sure that was confusing to other people too.

[00:02:54]
Yeah, typically, You're doing numbers or stream comparisons, right? Which that's normally you're gonna use triple equals for, but occasionally it is actually useful to say. Am I literally pointing at the same object here, which is what this actually does. Okay, so inside here where it says some code goes here, under request, now we have to handle these posts.

[00:03:21]
So the first thing we're gonna do is we're gonna say, msg .push user, text, time, date.now. Down here, we're gonna say res.end, right? Cuz we're gonna say, hey, user, I got all the information from you everything's all good. I mean, you could send back a status, okay here, but really, we're not sending any information back to the user.

[00:03:52]
We're just acknowledging, okay, A-okay, I got your posts. And then we're gonna say connections .forEach or you can do a for loop here however you wanna do it. I'm gonna say stream And then we're just gonna say stream.write JSON.stringify getMessages. I mean it's literally the same line as this, right?

[00:04:31]
The exact same thing that we write to them the first time we're just gonna say, cool, I got a new message. Here's the new batch of them and we're just gonna write that out to all the connected users at the moment. Now, again, it might be useful to have a front end and a back end that were a little bit smarter rather than just dumping out all of the current messages.

[00:04:51]
We could say, all right, here's the new ones that you haven't seen yet, right, and we can make those packets smaller. But for simplicity's sake, this is a good way of doing it. Okay, so Refresh So there's that and again, https, and I think this one's on 8080 instead of 3000.

[00:05:20]
The reason why I changed to those ports on you is cuz I wanted you to make sure that you're on https cuz I know it's gonna confuse someone. So now I have two clients here open, And this one's gonna say marc And hit submit and then I'm gonna go over here and you can see here it is immediately reflected.

[00:05:46]
And then we can probably even just split these up so you can see them. And you can see here, we're immediately getting in on both sides, right? I think it's pretty cool stuff, right? So this is HTTP/2 and it's really not any more complicated than that. We do kinda have to hack around it a little bit, cuz again, it's not particularly made with this use case in mind.

[00:06:26]
But just so you know at LinkedIn, we use this quite a bit in terms of just opening a long running connection with people and sending them information. Yeah, they use it quite heavily at LinkedIn. So if you wanna go see how a company does it, just go poke around LinkedIn.com.

[00:06:41]
And you can see they do it everywhere, or at least they did when I was there, might be changed after some years of not being there, probably. All right, any questions about HTTP/2? This is the end of this section, we're gonna get into WebSockets after this. Yeah, go ahead.

[00:07:05]
>> This might be a very trivial syntax type a question, but I noticed that we were using colon for some of the methods on the header, or headers object. Is that symbols also in JavaScript, or is that just syntax?
>> It is where is it, somewhere in here, right?

[00:07:25]
Like this one, right? So the question is why are using colons there? And the answer is cuz that's what they give it back to you as. I think they're just special characters, also there's special headers, right? They're actually not technically in the header, right? The method is not part of the headers per se, right?

[00:07:50]
But in any case, it's just what node calls it. They're not symbols to answer your question, so that would be like a new symbol, Right, it's not one of these, right? Which is a totally separate concept. This is just a magic stream that if you want the path back and 99% of the time express is handling this for you.

[00:08:16]
So you don't have to actually know that this is what this is called but if you're actually directly using HTTP/2, or there's another one here that's called http as well. It's the same thing just for 1.1, that's what they call it. So, to answer your question fully, just because, this is really just the answer to that.

[00:08:35]
Good question, other questions?
>> Will chunk be valid JSON when it streaming?
>> Will chunk be valid JSON when it's streaming? So let's see if I can find I think it's this part here that we're getting back from or really is this the reader response? Kind of an open question, that's why I put a try catch here.

[00:09:03]
I really didn't try the border cases of this. What happens if chunk is actually so big. Let's say you're sending huge amounts of JSON. It, might break that up across multiple chunks and that I don't know I actually did not try. In which case you would just kinda have to have a little bit more logic around.

[00:09:24]
Give me everything until I have valid JSON and then parse it. We're definitely gonna run into that in WebSockets, I know that's a problem. So that's always the question here and that's always why I put it anytime I do JSON.parse from API. Just put it in a try catch, cuz there's always a good chance that something gets messed up somewhere.

[00:09:49]
But this is not guaranteed to be valid JSON, right? Which is why we're gonna be kind of defensive about it here.