Polling with setTimeout

[00:00:00]
>> Let's try pulling the set timeout first and we're done. By the way with the back end, this is totally it for the polling back end. So now everything that we're gonna do from here on out for the polling part of the course is gonna be doing a variety of different client strategies of dealing with this.

[00:00:18]
Okay, so get new messages, this one here. Let's write a function that's going to use set timeout to go ahead and pull this endpoint. So first thing to notice here, this is an a sync function if you're not familiar with a sync await, there's lots of good JavaScript courses.

[00:00:40]
Yeah, re rethinking a sync, yep, good course devilish ticket. But if you're already familiar with it cool, let's move on with that but basically allows us to use the await keyword here and we'll kind of talk through that when we do it. So first thing here's we're gonna say let Jason and then we're gonna do a try.

[00:01:01]
And we're gonna say const.rez equals await, fetch/poll. And that's what this a sync does allows us to say, hey, we're gonna just pause our entire function execution here until this completes. Fetch poll here just returns a promise and all wait does it say wait for the promise to finish, that's it.

[00:01:28]
We're putting in a try catch because that's how you handle errors with a sync await. And here you're gonna say Jason equals await less.Jason, which will take this and jason will end up being a object of what came back from the API, we'll put our catch here. And we'll just say, here you drag your back off code, if you were gonna do that, well we are gonna do that here in a little bit, console.error polling error e.

[00:02:12]
Okay, so when you're doing a sync await code, you typically are gonna wanna wrap that in a try catch. It's just kind of the safe thing to do you'll get some better error messaging that way. Okay here I'm gonna say All Chat = json.msg. I'm gonna call render to reflect those to the DOM and then I'm gonna say set timeout get new messages at interval.

[00:02:47]
I can make this smaller so you can actually see what's going on here. Okay, and this, yeah, and again notice that for the first time getting the messages is called just directly down here. So to kinda kick it off, and then what's gonna happen here is now get messages is just going to call itself at the end, right?

[00:03:13]
So it continually does this, but what's better than this about then set interval. Set interval would run that this function every three seconds, no matter what. Come hell or high water, it's gonna pause execution, and it's gonna run that. What's nice about this is it's gonna do all of this first and then the last thing that it does is called set timeout.

[00:03:34]
So if this part takes 20 minutes, it's gonna do first of all it would timeout, but let's pretend for a second that it did take 20 minutes, right? It would wait the 20 minutes here before we call this set timeout. So it would take 20 minutes in 3 seconds before it would call again.

[00:03:52]
Okay, so in theory we should be able to come back over to our page here, refresh it, and you can see here now it's actually is populating, I don't know why. I'm going to look at Brian's done for the rest of course. [LAUGH] But there you go, you can see it's actually pulling this down from the server and if we look down here in our network tab.

[00:04:09]
Make sure that it's just we'll look at just XHR, you can see here this is getting called every three seconds. This is like the most simple real time thing that you can do is just call it a lot, right. Call it every three seconds and see what what's coming back with because we have no other clients connected to our chat.

[00:04:35]
Obviously nothing is coming back but we would be able to see that here. He would update automatically, so let's go do the post new message part of this, so we're here under the post new message. Again, this is just a normal HTTP POST, there's nothing special here, I promise I'm only making read this once today.

[00:05:01]
So we're going to say const data equals user and text, if you're not familiar with this feature, notice we have something called user and something called text. We're gonna call this user user and text text, right, but with JavaScript new feature, you can just call it user and text and that is implied.

[00:05:27]
So now we have a object called data that we can send back to the API, here we're gonna say const, options =, It's a POST. The body is JSON.stringify data, and the headers will let it know that it's aptly application type JSON, so Content- Type: application/json. This is probably stuff you've all written a million times I have and then down here, we're gonna say constra equals await fetch sorry, not a weight fetch/ poll options and then const JSON equals await rez.Jason like that, so you'll get this object back.

[00:06:33]
I don't know if you were sending anything back with your response mind just as status okay here which in reality, we don't really need that much, right? We don't really care what response comes back as long as it succeeds. So if you wanted to, you could actually just get rid of this line altogether.

[00:06:47]
And then we could actually get rid of this Raz right there and just saved fetch. You could probably even get rid of the await technically if you wanted to. Actually, you could even say return that actually be the most correct thing to do. Anyway, it does not matter what you do, right as long as you call fetch here, it doesn't matter, we're gonna we're just gonna leave it at a wait.

[00:07:13]
Okay, so come back over here again, make sure you're refreshing the page, yeah.
>> What about handling long requests? Like if the server takes time to respond?
>> Sure, good question, so the question is, what happens if the server takes a really long time to respond? The nice thing is that's kind of like a built in assumption of our code here.

[00:07:37]
In particular with a set timeout that it won't, queue itself to run until this previous request has finished right. So at most we will only ever have one of these running, because the only way that this runs again is if it calls itself right down here. So if it takes a long time to respond, that's fine, it's gonna be just fine.

[00:07:59]
Now, the problem that we do have here with Des code is if there is an error, then we have another problem, right? Actually, you know what, that's not even true, cuz I don't return here. So even if there's an error, you'll get a bunch of stuff in your console yelling at you that this is impossible.

[00:08:13]
But it'll actually we'll schedule itself again because we do our try catch here. So it'll work, I think is the answer to that person's question is yeah, it should work just fine. Okay, so let's go test our post here, so if I say Brian here and I click Submit, actually I have to refresh the page.

[00:08:36]
So make sure every time that you change the front end, make sure you got to refresh the page. So I should be able to hit Submit here and you'll see here, it does pop up here. Pretty cool, right? And you can change the name here to be Mark and you can say, I also think Bryan has done And you can see that also shows up there.

[00:09:13]
So what's awesome here as well, let's say I opened another window here. So if I come over here and I say, I don't know. I should also says. Something like that, right? So that'll show up here but now if I go back to my other one notice that it's actually showing up here as well.

[00:09:50]
So it actually be broadcasting out to every single one of the endpoints, to the all the other clients that are listening. And this is the most Basic low level simplest implementation of real time that you could get to, right? We wrote an endpoint, we call it a lot and now all of our various different clients are listening, right?

[00:10:13]
But they're actually its a this technically isn't push, right, so it's not the server pushing data to the client, it's actually the server just asking a whole lot, right? It's just saying, hey, do you have new data yet and it's just gonna keep asking that until that's true.

[00:10:26]
>> So it'd be better if we called get new message every time whenever posts, new messages, call it but then we don't have to keep sending the request, but how could we do that?
>> Sure, I think the question being asked is basically, I'm sending a post message and then I'm just waiting for that message to come back to me, right?

[00:10:47]
So if you go look at the code here, when you call post new message, it just fires us off into the void. And then we have the assumption here, that later that message is gonna come back in the next round of get new messages, right? Which is a terrible user experience, right?

[00:11:02]
Imagine that someone's on like, 2g out in the middle of the, middle of nowhere. That round trip can be quite long, so this works for our very simple implementation, but if this was your production code, it wouldn't be great, the way that I would handle that is basically what I would do.

[00:11:22]
Is I would have every message have an ID probably generated, I don't know either from the client or from the server. I would then attach that ID to the message and then I would actually just add that message to my all chat here and call re render immediately.

[00:11:38]
Instead of post new messages and then it would immediately show the user their message that they just posted. And then when the next round of messages came back from the server, I would deduplicate make sure that whatever messages that I've posted since then don't show up twice, right?

[00:11:56]
That would be a really good way of doing it. Yeah, there's some intelligence that you could add here. Like a good thing that we could do, instead of just getting all the messages all the time, we could basically say give me all new messages since the last one that you sent me.

[00:12:12]
Right, and then we can actually just get a delta of like, instead of getting all 50 messages every single time, we could get only the last five messages and then we could kind of shrink that packet size as well. So there's a bunch of strategies here and the cool thing is like I'm just showing you like the transport layer of talking between the clients.

[00:12:31]
You can actually go back later and re-implement some of these more advanced strategies of making this a better user experience. Hopefully answer that person's question which is basically show them something now and then D duplicate later. So what you see now is what is inside the, no pause section here.

[00:12:57]
So if you got behind or if you just wanna start from the same place that we're all starting from or something like that, feel free to just hop on to no pause, right? It's all basically the same code.