A developer writes TypeScript code in a NestJS project to create an in-memory idempotency store. The process includes implementing methods to begin, complete, and release requests, alongside a sweeper mechanism for clearing stale cache entries and lifecycle hooks for proper cleanup.
Length 8:46
Captions English (Generated), Spanish (Auto-translated), French (Auto-translated), Korean (Auto-translated), Portuguese (Auto-translated), Vietnamese (Auto-translated) #typescript #nestjs #idempotency #programming #coding #backend #software development #caching #data structures #software engineering
0:00 So now inside of the store, we are going to be expected to implement the 0:04 three 0:04 methods. We are firstly gonna store the underlying 0:08 data 0:10 that we are 0:12 storing from the completed responses. 0:14 So here is a simple map which has the idempotency 0:18 key as the key, so we can look that up by its idempotency key, 0:23 and that will have a corresponding record associated with it, which is our 0:26 custom type from above. And so again, this record will either 0:30 be the request that's currently in flight or the completed state with 0:34 the status and body ready to return back to the caller. 0:39 And so now at this point, we have the store fully wired in 0:42 and ready to now 0:42 implement the actual methods to offer the 0:46 idempotency state persistence in memory. 0:49 So let's go ahead and do this next. So to go ahead and get 0:53 started, let's begin with the begin method. 0:57 So as we know, if we actually just let the interface type 1:00 itself 1:01 out here, 1:02 this is gonna take in the key as well as the time to live for the 1:06 actual entry, and we're gonna return back 1:08 that begin result. 1:10 And so in this method, what we're going to do is actually 1:13 register the beginning of an idempotent 1:17 processing. So essentially, we would call this before we actually 1:21 begin an idempotent request, and so this is going to allow us to check 1:24 to 1:25 see if this request has already been executed by the 1:28 idempotency key. If it has, then we're gonna return back the saved 1:32 response instead of actually re-executing it. 1:36 And this will protect our idempotent routes like a post route from executing 1:40 more than once. But to the client, it will be completely opaque. 1:44 Now, the first thing we need to do is check to see if we already have
The rest of the transcript is for members.
Sign in 