feat: add caching to service worker #92

2color · 2024-03-07T16:41:48Z

Description

This PR adds caching for responses using the Cache API.

Fixes #73

Notes & open questions

Do we want to also cache for the isRootRequestForContent case?: https://github.com/ipfs-shipyard/helia-service-worker-gateway/blob/3cc5b9882dbbf347a8c5fd51df311c8705dc6fc8/src/sw.ts#L94-L96
Right now the cache key is based on the event.request. This seems reasonable but maybe it's not optimal?
- Update: it's not possible to use the IPFS URL for cache. Hence the use of the request

TODO

Double check how the caching and invalidation works for IPNS paths

Change checklist

I have performed a self-review of my own code
I have made corresponding changes to the documentation if necessary (this includes comments as well)
I have added tests that prove my fix is effective or that my feature works

SgtPooki · 2024-03-08T01:07:07Z

Right now the cache key is based on the event.request. This seems reasonable but maybe it's not optimal?

We should probably use the verifiedFetchUrl you have in the other PR

2color · 2024-03-11T12:46:55Z

Right now the cache key is based on the event.request. This seems reasonable but maybe it's not optimal?

We should probably use the verifiedFetchUrl you have in the other PR

The Cache API does not support URLs with the ipfs:// protocol scheme:

src/sw.ts

* origin/main: feat: allow loading config page from subdomain after sw registration (#96) chore!: dist files optimizations (sw asset name changes) (#97) Update src/components/CidRenderer.tsx chore: remove in-page rendering

SgtPooki · 2024-03-12T19:23:58Z

The Cache API does not support URLs with the ipfs:// protocol scheme:

you're right.. I forgot service worker cache requires inputs to be a request object

SgtPooki

looks mostly good, we need to figure out ipfs/helia-verified-fetch#17 tho

src/sw.ts

2color · 2024-03-13T11:11:28Z

we need to figure out ipfs/helia-verified-fetch#17 tho

Yeah.

That can be done in parallel, i.e. no need to block this PR, since the Cache API takes precedence over the browser HTTP cache..

also make sure that we actually store reponse in cache when fetching it in the background

2color · 2024-03-13T16:39:46Z

Pretty obvious but worth noting here that depending on whether the origin has ipns or ipfs, every resource handled by the service worker will either be mutable or immutable.

For example, when opening vitalik-eth.ipns.inbrowser.link all of the resources requested as a path on the origin are considered mutable.

On the other hand, all resources bafybeiawq7pbt4krnopfmcvymvp2uz4ohibd5p7ugskkybvdmwa2v7evpy.ipfs.inbrowser.link are immutable.

2color · 2024-03-13T16:50:19Z

src/sw.ts

+function setExpiresHeader (response: Response, ttlSeconds: number = 3600): void {
+  const expirationTime = new Date(Date.now() + ttlSeconds * 1000)
+
+  response.headers.set('Expires', expirationTime.toUTCString())


It may be sensible to make this cache header explicitly SW specific (originally suggested in https://phyks.me/2019/01/manage-expiration-of-cached-assets-with-service-worker-caching.html)

Suggested change

response.headers.set('Expires', expirationTime.toUTCString())

response.headers.set('sw-cache-expires', expirationTime.toUTCString())

that makes sense

Long term, if we can avoid inventing things specific to service worker, and reuse HTTP semantics, that is better for verified-fetch being useful in more contexts, and easier to test (if these are set upstream, places like https://github.com/ipfs/helia-http-gateway get these headers for free, and we also increase surface of things that can be tested there).

My initial thought here was that if we reuse semantically meaningful Expires and set it only if not set yet, in the future it can be set inside verified-fetch, and not only we don't need to invent special header here, but also improve the upstream library and the code here will be smaller.

But fine to go with custom header here for now.

@lidel Because the SW Cache API always takes precedence over browser HTTP cache and and verified-fetch will be returning the Cache-Control header, the Expires header would be: no-op.

Even if we were to use the Expires header, by respecting it when there's a Cache-Control header, we'd be breaking from HTTP semantics. This is why I think it makes sense to make it clear that this header is purely for SW purposes.

SgtPooki · 2024-03-13T17:08:07Z

For example, when opening vitalik-eth.ipns.inbrowser.link all of the resources requested as a path on the origin are considered mutable.

Yea, it would be nice if we could map the ipns name to a CID and re-route requests to ipfs://cid so that they're cached.

SgtPooki

leaving some comments.. im going to check the code out locally and play with it

src/sw.ts

SgtPooki · 2024-03-13T17:14:49Z

src/sw.ts

+ * Note that this ignores the Cache-Control header since the expires header is set by us
+ */
+function hasExpired (response: Response): boolean {
+  const expiresHeader = response.headers.get('Expires')


Suggested change

const expiresHeader = response.headers.get('Expires')

const expiresHeader = response.headers.get('sw-cache-expires')

resolved in #109

SgtPooki · 2024-03-13T22:34:55Z

src/sw.ts

+function setExpiresHeader (response: Response, ttlSeconds: number = 3600): void {
+  const expirationTime = new Date(Date.now() + ttlSeconds * 1000)
+
+  response.headers.set('Expires', expirationTime.toUTCString())


that makes sense

src/sw.ts

SgtPooki · 2024-03-13T23:01:39Z

src/sw.ts

+    trace('helia-ws: setting expires header on response key %s before storing in cache', cacheKey)
+    // 👇 Set expires header to an hour from now for mutable (ipns://) resources
+    // Note that this technically breaks HTTP semantics, whereby the cache-control max-age takes precendence
+    // Seting this header is only used by the service worker asd a mechanism similar to stale-while-revalidate


Suggested change

// Seting this header is only used by the service worker asd a mechanism similar to stale-while-revalidate

// Setting this header is only used by the service worker using a mechanism similar to stale-while-revalidate

resolved in #109

src/sw.ts

SgtPooki · 2024-03-13T23:05:26Z

src/sw.ts

+  }
+
+  log('helia-ws: storing cache key %s in cache', cacheKey)
+  void cache.put(cacheKey, respToCache)


Suggested change

void cache.put(cacheKey, respToCache)

await cache.put(cacheKey, respToCache)

control flow should be done in higher level fetchHandler or getResponseFromCacheOrFetch

resolved in #109

SgtPooki · 2024-03-13T23:06:09Z

src/sw.ts

+  // If there is an entry in the cache for event.request,
+  // then response will be defined and we can just return it.


spacing here seems off

Suggested change

// If there is an entry in the cache for event.request,

// then response will be defined and we can just return it.

// If there is an entry in the cache for event.request,

// then response will be defined and we can just return it.

resolved in #109

SgtPooki · 2024-03-13T23:06:57Z

src/sw.ts

+    fetchHandler({ path: url.pathname, request: event.request })
+      .then(async response => storeReponseInCache({ response, isMutable, cache, cacheKey }))
+      .catch(err => {
+        err('helia-ws: failed updating response in cache for %s in the background', cacheKey, err)
+      })
+
+    return cachedResponse
+  }
+
+  // 👇 fetch because no cached response was found
+  const response = await fetchHandler({ path: url.pathname, request: event.request })
+
+  void storeReponseInCache({ response, isMutable, cache, cacheKey }).catch(err => {
+    err('helia-ws: failed storing response in cache for %s', cacheKey, err)
+  })
+
+  return response


I feel like we could combine these so we don't have two potential places where cache storing happens and could fail

looking at the code more locally, we don't need to fetch from the network at all on cache-hit. Since we're currently fighting rate limits from the trustless gateway, we could just not do network requests. The likelihood of something updating on IPFS is very low, whereas stale-while-revalidate is good for frequently updated content that you want a quick response for.

resolved in #109

SgtPooki · 2024-03-13T23:34:50Z

src/sw.ts

+    fetchHandler({ path: url.pathname, request: event.request })
+      .then(async response => storeReponseInCache({ response, isMutable, cache, cacheKey }))
+      .catch(err => {
+        err('helia-ws: failed updating response in cache for %s in the background', cacheKey, err)
+      })


do we need to call fetchHandler and update the cache if we already have a cached response?

resolved in #109. stale-while-revalidate only for ipns cache HIT

SgtPooki · 2024-03-13T23:43:50Z

src/sw.ts

+    fetchHandler({ path: url.pathname, request: event.request })
+      .then(async response => storeReponseInCache({ response, isMutable, cache, cacheKey }))
+      .catch(err => {
+        err('helia-ws: failed updating response in cache for %s in the background', cacheKey, err)


Suggested change

err('helia-ws: failed updating response in cache for %s in the background', cacheKey, err)

error('helia-ws: failed updating response in cache for %s in the background', cacheKey, err)

resolved in #109

feat: some updates to #92

feat: naive cache implmentation

6756630

2color force-pushed the add-cache branch from 0e74571 to 6756630 Compare March 11, 2024 12:18

fix: only cache successful responses

3cc5b98

2color marked this pull request as ready for review March 11, 2024 13:15

lidel requested changes Mar 11, 2024

View reviewed changes

src/sw.ts Outdated Show resolved Hide resolved

src/sw.ts Outdated Show resolved Hide resolved

src/sw.ts Outdated Show resolved Hide resolved

2color added 2 commits March 12, 2024 12:34

Merge remote-tracking branch 'origin/main' into add-cache

1e9a30a

* origin/main: feat: allow loading config page from subdomain after sw registration (#96) chore!: dist files optimizations (sw asset name changes) (#97) Update src/components/CidRenderer.tsx chore: remove in-page rendering

feat: improve cache mechanism

34a396b

2color force-pushed the add-cache branch from 68e378b to 34a396b Compare March 12, 2024 16:16

Merge branch 'main' into add-cache

7a08d10

SgtPooki reviewed Mar 12, 2024

View reviewed changes

src/sw.ts Outdated Show resolved Hide resolved

src/sw.ts Outdated Show resolved Hide resolved

src/sw.ts Outdated Show resolved Hide resolved

2color added 4 commits March 13, 2024 12:50

fix: linting errors

9ff7314

refactor: move caching logic to separate functions

f56d25e

also make sure that we actually store reponse in cache when fetching it in the background

fix: small optimisation

0095181

chore: change log to trace

555fbcc

2color commented Mar 13, 2024

View reviewed changes

SgtPooki reviewed Mar 13, 2024

View reviewed changes

Merge branch 'main' into add-cache

30dd440

SgtPooki reviewed Mar 13, 2024

View reviewed changes

SgtPooki added 5 commits March 13, 2024 16:46

chore: PR comments and minor improvements

6a0d416

fix: use sw-cache-expires

69f4d4c

chore: cleanup hasExpired return

fdbeb97

chore: log on cache miss

a0c8dcb

chore: wait for response so we can cache it

4714ab1

SgtPooki added 3 commits March 13, 2024 17:22

chore: minor cleanup

0bc73ed

chore: minor cleanup

3e003ae

fix: stale-while-revalidate for ipns

511c64f

SgtPooki mentioned this pull request Mar 14, 2024

feat: some updates to #92 #109

Merged

SgtPooki approved these changes Mar 14, 2024

View reviewed changes

2color and others added 2 commits March 14, 2024 12:55

Merge pull request #109 from ipfs-shipyard/feat/add-cache-patch

c08c467

feat: some updates to #92

chore: move magic number to constant

e8a41ea

SgtPooki approved these changes Mar 14, 2024

View reviewed changes

SgtPooki merged commit 4674dd0 into main Mar 14, 2024
21 checks passed

SgtPooki deleted the add-cache branch March 14, 2024 20:39

lidel mentioned this pull request Mar 15, 2024

chore(main): release 1.0.0 #120

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: add caching to service worker #92

feat: add caching to service worker #92

2color commented Mar 7, 2024 •

edited

Loading

SgtPooki commented Mar 8, 2024

2color commented Mar 11, 2024

SgtPooki commented Mar 12, 2024

SgtPooki left a comment

2color commented Mar 13, 2024

2color commented Mar 13, 2024

2color Mar 13, 2024

SgtPooki Mar 13, 2024

lidel Mar 14, 2024 •

edited

Loading

2color Mar 14, 2024

SgtPooki commented Mar 13, 2024

SgtPooki left a comment

SgtPooki Mar 13, 2024

SgtPooki Mar 14, 2024

SgtPooki Mar 13, 2024

SgtPooki Mar 13, 2024

SgtPooki Mar 14, 2024

SgtPooki Mar 13, 2024

SgtPooki Mar 14, 2024

SgtPooki Mar 13, 2024

SgtPooki Mar 14, 2024

SgtPooki Mar 13, 2024 •

edited

Loading

SgtPooki Mar 14, 2024 •

edited

Loading

SgtPooki Mar 14, 2024

SgtPooki Mar 13, 2024

SgtPooki Mar 14, 2024

SgtPooki Mar 13, 2024

SgtPooki Mar 14, 2024

	response.headers.set('Expires', expirationTime.toUTCString())
	response.headers.set('sw-cache-expires', expirationTime.toUTCString())

	const expiresHeader = response.headers.get('Expires')
	const expiresHeader = response.headers.get('sw-cache-expires')

	// Seting this header is only used by the service worker asd a mechanism similar to stale-while-revalidate
	// Setting this header is only used by the service worker using a mechanism similar to stale-while-revalidate

	void cache.put(cacheKey, respToCache)
	await cache.put(cacheKey, respToCache)

		// If there is an entry in the cache for event.request,
		// then response will be defined and we can just return it.

	err('helia-ws: failed updating response in cache for %s in the background', cacheKey, err)
	error('helia-ws: failed updating response in cache for %s in the background', cacheKey, err)

feat: add caching to service worker #92

feat: add caching to service worker #92

Conversation

2color commented Mar 7, 2024 • edited Loading

Description

Notes & open questions

TODO

Change checklist

SgtPooki commented Mar 8, 2024

2color commented Mar 11, 2024

SgtPooki commented Mar 12, 2024

SgtPooki left a comment

Choose a reason for hiding this comment

2color commented Mar 13, 2024

2color commented Mar 13, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lidel Mar 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SgtPooki commented Mar 13, 2024

SgtPooki left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SgtPooki Mar 13, 2024 • edited Loading

Choose a reason for hiding this comment

SgtPooki Mar 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

2color commented Mar 7, 2024 •

edited

Loading

lidel Mar 14, 2024 •

edited

Loading

SgtPooki Mar 13, 2024 •

edited

Loading

SgtPooki Mar 14, 2024 •

edited

Loading