Coding Backoff & Retry

[00:00:00]
>> Let's go code this ourselves. I'm gonna fix this, okay. So here in pulling chat. What we're gonna do here. We're gonna say, if res.status. Is greater than or equal to 400, which basically means something went wrong, right? If you're not familiar with HTTP verbs, just go look at the Wikipedia page.

[00:00:44]
I look at it all the time cuz I can never remember anything outside of like what 404 and 200 are. But basically if this number is greater than or equal to 400, something went wrong. Then what I'm gonna do here is I'm gonna just say throw new error.

[00:01:02]
Requests did not succeed. Plus res.status. Okay, I'm gonna move this stuff actually up into my try catch as well. Okay, and then I'm gonna call render here as well. Okay, and then we're also gonna make a, we haven't written it yet but we're gonna create a variable called failed tries.

[00:01:43]
Failed tries equals zero, right? Cuz if we get down here that means it succeeded which means we have no failed tries. Okay, and then down here in the cache, we'll put a polling error here so you can see if something happened, right? And then I'm gonna say failedTries++, right?

[00:02:04]
Because if we get down into this block down here, that means something bad happened, we should try again. Okay, so I'm gonna do what we did here, if the status comes back as bad they really go into our cache statement, that's all this stands here. Okay, then down here, at ref timer, we're going to add a couple more variables here.

[00:02:39]
We're gonna make one called back off const back off, equals 5000, so we're gonna do kind of a linear back off strategy. So we're gonna add five seconds to our retry every single time. And then we're gonna say let failed tries equals zero, cuz initially there will be no failed tries.

[00:03:04]
Okay, and then down here, all we need to do is make this time the next request, time plus interval. Plus failed tries times back off. And that's really it. The only thing that we're really manipulating here is when are we gonna make our next request, right? So for the most part, if it's pulling successfully and we have no problems, this is gonna be 0 and 0 times 5000, always still gonna be 0.

[00:03:44]
So this doesn't add anything to it. But if we have one failed try right then there'll be 5000 added to this 10 failed tries, so on and so forth, right? So I mean, if you wanted to do exponential back off that would be like failed tries. Times a 1000, so, if we're doing seconds, right and then I think that is exponents times.

[00:04:26]
Actually wanting me to be 2000 or 1000, 2000. Anyway, you would just do the math here to, I can't think of it off the top my head but this is where you would do that as well. But we're just going to do a pretty simple linear one here, which is going to be this.

[00:04:45]
And then you can mess with back off here is like, well, I wanna do every ten seconds now or two seconds, up to you. We'll do 5000 for right now. Okay, so we should be able to just go back to our app and it's not gonna have any failed stuff.

[00:05:04]
So this is just gonna keep on chugging to be great, but here if we come back and say .status500 like that. Now notice this is gonna take significantly longer between poles. So got another 500, so this should take, what 13 seconds before requests again. Yep, so failed again, 18 seconds, so on and so forth.

[00:05:48]
Now let's go back here and say we'll make it only fail some of the time math.random is greater than 0.5 and if it is we'll make it 200, if not, we'll make it 500. This is just a ternary math.random gives you back a number between 1 or 0 and 1.

[00:06:19]
So in theory about half the time this will be true or false, right? If it's true, make it 200, if it's false, make it 500. And so this will fail sometimes and it won't fail other times, so you can see here it failed the first time. Failed again, so it's gonna back off further but in theory, if it gets a 200 it should reset itself and be it'll have that smaller back off period.

[00:06:52]
So you can see here it should pull again quickly and it did, right? So now it's back to pulling normally, and then it got to 500, so it's gonna back off again. Cool I don't wanna leave that in, this is not good programming don't ship that to production.

[00:07:20]
Pro tip. So, a couple of notes here. The try cache here might be strange to you. Let's talk about why I did it this way, I can actually just show you. If you go into offline mode here, this will actually cause a fetch will throw an error. So in the code here, instead of this coming back with like a 400 or 500 or something like that, this will actually just throw an error, which would cause us to go into a cache statement.

[00:08:03]
So rather than trying bifurcate my logic here and handle that here and handle that here, I just threw an error here. And then I can put all of my error handling logic in the same place. So that's why I chose to do the throw a new error here.

[00:08:18]
As well as that so that I can have all of my error handling done in one place. So yeah, this throws a error if the network won't connect but it will not throw an error if it gets a 500. That's what I meant to say. Yeah, this is just one way of doing the math, but the idea here is you manipulate when you make your next request.

[00:08:48]
And if you were doing this with set timeout instead of requestAnimationFrame, right? Let's just look at that polling chat from no pause, the number that you have manipulate would be this one, this interval number here, right? You would have the same logic here, if you're gonna do that with set timeout instead of requestAnimationFrame.

[00:09:19]
My general kind of just product advice for you is for retry and back off, if a user's request fails, immediately try again, and then wait a short time and then try again. And if those two requests both fail, so you'll have three requests fail in a row, then you wanna back off pretty aggressively.

[00:09:42]
Between those three requests you should catch most things like I change networks or I had a blip from my ISP or something like that and. If they don't succeed after three, they're probably not gonna succeed in the next minute. So at that point I try and back off pretty aggressively.

[00:10:04]
That's just kind of my general thinking about what my strategy is there. Yeah, at that point I'm worried that my servers are overwhelmed and I wanna just shed as much load as possible, right? So that I can bring them back. In general, I don't really write this logic myself.

[00:10:25]
What we just showed here, lots and lots and lots of libraries will do this for you like Axio has built in retry and back off. Axio is a great library, which does a felt like requests for you. But I wanted to show you what's happening underneath the hood so that you know one cuz you'll probably you will likely get asked this interview at some point.

[00:10:46]
And two it's just it's good to know, it's good product sense to have. Cool. So the completed code here is in back off and retry which I'll show you. Which is here, back off and retry