0:00 All right, so in this section, we're gonna start implementing 0:02 idempotency. 0:04 Now, idempotency in a back-end system idea that 0:08 an operation is doing some once 0:12 and only once. So essentially, an operation is idempotent when doing it 0:16 once and doing it N times leaves the system in the 0:20 same state. 0:22 Get, put, and delete HTTP methods are already 0:26 inherently idempotent by the HTTP spec, 0:30 while post is not. And this should make sense 0:34 inherently. A get request, you could execute as many times as you 0:37 want, 0:38 and the system should still be in the same state. 0:40 Same with a put or delete, but a post is a creation 0:44 or some sort of other functionality. 0:47 Like, for example, if you were to charge a credit card, 0:50 requests that 0:51 time out in the wire leave the client not knowing whether the charge might have 0:54 happened. So it doesn't really know if it can safely 0:58 retry or safely give up, and that's 1:01 exactly what we're gonna implement with idempotency, is essentially a 1:05 contract between the client and the server. 1:08 To do this, we're going to have the client attach a 1:11 unique token to each 1:12 request, a idempotency key. 1:16 The server promises that any request carrying 1:19 that token it already has seen 1:20 gets the original result rather than a second execution. 1:24 So this means a non-idempotent post is an idempotent one from the 1:28 caller's point of... as long as they're passing this 1:31 idempotency key, 1:32 and this is gonna be the key to getting this idempotency for 1:36 post routes as well. So I'm super excited to jump into seeing 1:40 how we 1:40 can implement idempotency within a NestJS 1:43 application out of the box in the best way possible. 1:47 All right, so our first step into implementing 1:49 idempotency is 1:51 implementing a way to actually store the 1:54 responses from our idempotent routes because, remember, a
The rest of the transcript is for members.
Sign in 