Mapping remote endpoints

[sinclairzx81]

Hi there,

Am just reviewing solutions for offline caching, and found your project, it looks great!!

I have a quick question with regards to being able to map local endpoints to remote endpoints with dsw.

For some background, our application needs to source large user assets from remote CDN stores, and was wondering if dsw provides a facility for mapping / caching assets hosted on remote domains. We have done some local testing here, and it seems technically feasible with Service Workers.

An example of what we are imagining would be..

https://local.com/bucket/video.mp4 # virtual local path

to be intercepted and rewritten as...

https://remote/bucket/video.mp4 # rewritten endpoint

where dsw would source the remote asset (via CDN) and cache the response against the virtual local path. Was looking for a configuration perhaps similar to the following.

mappings: {
   local: "/bucket",
  remote: "https://remote/bucket/"
}

Again, the DSW solution looks fantastic! Look forward to hearing back.

S

[felipenmoura]

Cool @sinclairzx81
We tried to address this with some different approaches.
If I'm not mistaken you can have a generic rule (in the end, to be used if no other rule has applied).
If that one uses cache (to automatically cache any request), it will try and cache requests from other domains too.

The downside is that, due to permissions and policies, this is an "opaque answer". That means we can store it in cache and use it, but we cannot check for its contents.
This means that, if the first time it failed, we have no way to know about it, and will store the failure in cache :/
Perhaps this can be fixed with some server side header policy allowing such requests.

I think we need to run some tests to ensure this exact situation works, but you can try this, so far:

"videos": { // the rule
    "match": { "path": "/bucket/(.*)" }, // match any file in that directory
    "strategy": "offline-first",
    "apply": {
        "redirect": "https://remote/bucket/video/$1" // will redirect to the CDN
        "cache": { // and will also cache it
            "name": "cached-videos",
            "version": "1"
        }
    }
}

Perhaps, an interesting thing to add too is a flag like large: true and then, for large files to be stored in cache, we could use the filesystem api instead of the cacheapi itself.