> how would you implement this kind of cache in idiomatic, lock-free javascript?
The simplest way is to cache the Promise<data> instead of waiting until you have the data:
-async function fetchDataAndUpdateCache(key: string) {
+function fetchDataAndUpdateCache(key: string) {
const cachedData = getFromCache(key);
if (cachedData) {
return cachedData;
}
// Simulate fetching data from an external source
-const newData = await mockFetch(`https://example.com/data/${key}`); // Placeholder fetch
+const newData = mockFetch(`https://example.com/data/${key}`); // Placeholder fetch
updateCache(key, newData);
return newData;
}
From this the correct behavior flows naturally; the API of fetchDataAndUpdateCache() is exactly the same (it still returns a Promise<result>), but it’s not itself async so you can tell at a glance that its internal operation is atomic. (This does mildly change the behavior in that the expiry is now from the start of the request instead of the end; if this is critical to you you can put some code in `updateCache()` like `data.then(() => cache[key].timestamp = Date.now()).catch(() => delete cache[key])` or whatever the exact behavior you want is.)
I‘m not even sure what it would mean to “add a lock” to this code; I guess you could add another map of promises that you’ll resolve when the data is fetched and await on those before updating the cache, but unless you’re really exposing the guts of the cache to your callers that’d achieve exactly the same effect but with a lot more code.
Ok, that's pretty neat. Using Promises themselves in the cache instead of values to share the source of data itself.
While that approach has a limitation that you cannot read the data from inside the fetchDataAndUpdateCache (e.g. to perform caching by some property of the data), that goes beyond the scope of my example.
> I‘m not even sure what it would mean to “add a lock” to this code
It means the same as in any other language, just with a different implementation:
class Mutex {
locked = false
next = []
async lock() {
if (this.locked) {
await new Promise(resolve => this.next.push(resolve));
} else {
this.locked = true;
}
}
unlock() {
if (this.next.length > 0) {
this.next.shift()();
} else {
this.locked = false;
}
}
}
I'd have a separate map of keys-to-locks that I'd use to lock the whole fetchDataAndUpdateCache function on each particular key.
The simplest way is to cache the Promise<data> instead of waiting until you have the data:
From this the correct behavior flows naturally; the API of fetchDataAndUpdateCache() is exactly the same (it still returns a Promise<result>), but it’s not itself async so you can tell at a glance that its internal operation is atomic. (This does mildly change the behavior in that the expiry is now from the start of the request instead of the end; if this is critical to you you can put some code in `updateCache()` like `data.then(() => cache[key].timestamp = Date.now()).catch(() => delete cache[key])` or whatever the exact behavior you want is.)I‘m not even sure what it would mean to “add a lock” to this code; I guess you could add another map of promises that you’ll resolve when the data is fetched and await on those before updating the cache, but unless you’re really exposing the guts of the cache to your callers that’d achieve exactly the same effect but with a lot more code.