Tee-ing Cache.put()?

[lukewagner]

IIUC, a common pattern developers would write when lazily populating a Cache would be something like:

event.respondWith(fetch(url).then(response => {
  var responseClone = response.clone();
  cache.put(url, response);
  return responseClone;  
}));

With a new method teePut (placeholder name, better names welcome!) a developer could write:

event.respondWith(fetch(url).then(response => cache.teePut(url, response)));

where teePut returns a Response (or maybe Promise<Response>) that is semantically a clone of the Response given as argument.

In addition to being simpler to write, this might be more optimizable by the browser for two reasons:

• the constrained form of the tee, compared to a general clone(), may allow less internal copying between source and sink streams
• if the response clone flows into one of several content sinks that want to cache a processed form of the resource, the explicit tee operation provides a more-direct route from the content sink back to the Cache entry.

[lukewagner]

(As discussed with @domenic and @jakearchibald last week at TPAC.)

[asakusuma]

Also, this would better support scheduling the cache.put as a task associated with the worker, but not a task that should block the respondWith.

[asakusuma]

Given the current API, I believe you're supposed to schedule the cache.put using waitUntil. Not sure if this is actually necessary given the browser implementations, but probably best practice:

const fromNetwork = fetch(url);
event.waitUntil(fromNetwork.then((response) => {
  return cache.put(url, response);
}));
event.respondWith(fromNetwork.then(response => {
  return response.clone();
}));

Either way, seems like a common enough pattern to warrant some syntactic sugar.

[jakearchibald]

I tend to write it as:

event.respondWith(async function() {
  const response = await fetch(url);
  event.waitUntil(cache.put(url, response.clone()));
  return response;
}());

[annevk]

How is this kind of teeing more constrained than clone()? Naïvely, I'd think this could also be optimized by storing the knowledge that there's a clone floating around and not actually do much cloning until it starts mattering somehow.

[lukewagner]

Yes, with sufficient work on the HTTP+DOM caches, I think most (all?) of the optimizations I was imagining for teePut could be achieved for the common clone() patterns, so that's a fair point. teePut seems nice in being simpler to write for a common case while encouraging a fast path that could be achieved more readily in browsers today, but I don't know whether that makes it worth it as a new feature.