0:00 All right, so the first thing I wanna do before 0:02 actually building out 0:04 our new retry mechanism into our Axios factory 0:08 is to actually configure some options in our 0:12 HTTP module. So remember, this comes from our HTTP types, 0:16 where we've already specified some options we can set for keep alive. 0:20 Let's do the same thing for retries so that we can actually freely configure 0:24 this HTTP module for use depending on our use 0:28 case, because we might wanna tune it differently 0:31 depending on 0:32 our application's needs. And so we'll 0:36 export interface retry options where we'll 0:39 define, importantly, retries. This is gonna be the 0:43 maximum number of retries we want to support. 0:46 Now, by default, the library uses three, 0:50 so it'll retry up to three times. So we'll allow this to be configured 0:54 further. 0:55 We also have a minDelay milliseconds value. 0:58 Now, by default, the library, if we take a look, has 1:02 this option called retryDelay, which is a function that we can 1:06 pass to the library to tell it how long we should wait in 1:10 between failed requests. Now, by default, the library 1:14 has no delay between retries, so as soon as the first failure hits, 1:19 it's gonna retry immediately. However, we might wanna implement a 1:22 different strategy like exponential backoff or linear 1:26 delay. Now, both of these are ways for us to essentially 1:30 wait to call the server again and try it again. 1:33 Now, exponential backoff is a very popular pattern which 1:37 follows the growth of an exponential curve, where the 1:41 first time we retry, it's very quick, but then we 1:45 wait a bit longer for the next retry, and then 1:48 after that one, we wait even longer. 1:51 So it's essentially giving us more time for the server to 1:54 recover in between each retry. Or we can make it
The rest of the transcript is for members.
Sign in 