Painless Service-Workers with +page.sw.js and hooks.sw.js

[LorisSigrist]

The Pain-Point

Writing service-workers sucks, especially if your app talks to a server often.

Here what you need to do if you want your app to work offline or with a poor connection:

• Mock every API call and form submission, save stuff locally on the client so it can be sent to the server when there is a connection, respond with an optimistic update as if the server had processed the request immediately, reconcile the diff between the client and the server once there is an internet connection, and all that while keeping authentication and authorization in mind.
• The service-worker only provides you with a "fetch" event. You have to match all the routes, and detect the http-methods yourself.
• You don't get any tooling, as that would require your IDE to know what page / api / form the code you are writing is for.

In short: it's a pain and it does not scale.

How SvelteKit could help

Sveltekit could alleviate this pain by componentizing the service-worker. Instead of writing a single monolithic service-worker for your entire site, you instead define your service-worker logic on a per-page / per-endpoint level. This gets compiled into part of a monolithic service-worker.

Componentizing service-worker code to a single page is helpful in the following ways:

• Since we know which routes the service-worker code should work on, the framework can take over the route-matching. This would be more reliable and more maintainable than doing it manually.
• You could share types between the service-worker, the frontend, and the server, as the three would be strongly coupled.
• Service-Worker components do not grow to the same unmaintainable size as a monolithic service worker.

+page.sw.js and hook.sw.js are my attempt at creating a framework pattern that can reap these benefits.

My +page.sw.js and hooks.sw.js proposal

Alongside +page.svelte, you would be able to define a +page.sw.js. This would define the service-workers behavior for this page. It would mostly be used to mock +page.server.js. Like +page.server.js, +page.sw.js would implement load functions and form actions.

When the page makes a request to a server side method (like load, or an action), the page's service-worker component gets a chance to intercept it. The worker is responsible for deciding how to proceed with the request from there. It can choose to respond directly (with cached data for example), or to pass the request on to a +page.server.js, or really, it could implement any pattern the developer can dream of.

It would probably be helpful to study an actual example to see how this behavior would be helpful for creating service-workers.
Let's say you have a page with a list of products. This list is loaded in the server-load function. When offline, we want to display a locally cached list of products instead of just failing outright.

The +page.sw.js file would look something like this:

export async function load({request, respondWith}) {
    //try to load the list over the network, when 
    try {
          //Make network request to the server with a timeout of 3sec
          const signal = AbortController.timeout(3000);
          const response = await fetch(request, {signal}); //This would trigger +page.server.js
        
          //Create a clone of the response. Response bodies can only be read once
          const swResponse = response.clone();
          respondWith(response); //Send response to UI
          
          //Update the locally cached list of products
          const products = await swResponse.json();
          writeProductsToIndexedDB(products);
    }catch(e){
          //Network timeout / failure
          respondWith( getProductsFromIndexedDB() );
    }    
}

Let's extend the example by adding a form to the page that creates a new product. We can intercept the form submission, and optimistically update the UI, even if no network is present.

export async function load ...

export const actions = {
    default: async ({request, respondWith}) => {
        const data = await request.formData();
      
        const productName = data.get("productName");
        const productPrice  =  data.get("productPrice");

        if(!productName || !productPrice) {
             //Throwing invalid / error / redirect should be possible.
             throw invalid(400, {missingName: !!productName, missingPrice: !!productPrice }); 
        }
        
        addProductToIndexedDB({ name: productName, price: productPrice, sentToServer: false });
        
        try {
              const response = await fetch(request);
              if(!response.ok) throw "Network request failed";
              respondWith(response);
              
              // Update the indexedDB entry 
              markProductAsSentToServer(productName);
        }catch(e) {
             //Network request failed. Try again later
        }       
    }
}

It can't be assumed that service-workes are present. They are purely progressive enhancement. If a server-side load function, or form action that is not implemented by +page.sw.js is called, it just goes along to the server.

hooks.sw.js is the service-worker equivalent of hooks.server.js. It should follow the interface of hooks.server.js closely. It would have a handle, handleFetch and a handleError function.

• handle Prepares a Request for the downstream +page.sw.js handlers. This would be the opportunity to set event.locals, check authentication / authorisation, or to bypass the downstream handlers entirely.
• handleFetch would be an opportunity to deal with external requests, that could not be targeted with *.sw.* files.
• handleError Deal with any error events that might be thrown during *.sw.* handler execution.

How would this work with the existing service worker file?

Since this pattern only handles app-internal network interaction, and none of the other responsibilities of the service worker (like static-file caching or notifications), the regular service-worker.js file is still needed. We would need to come up with a way to inject the behaviour from the service-worker routes into the service-worker file.

Here is one idea:

Everything +page.sw.js and hook.sw.js can do can be handled inside the service-worker's fetch event. You could conceivably create a "magic import" that gives you a single function that implements all the behaviours the developers have defined in their *.sw.* files, as well as the route-matching done by sveltekit. This function would take the FetchEvent as an argument. It could then be used like so:

import { resolveFetchEvent } from '$service-worker'

self.addEventListener("fetch", event => {
    // developer can do other stuff with the event, if they choose to

    // Sveltekit resolves which handlers need to be run and runs them. 
    resolveFetchEvent(event);
})

Could this work for entire endpoints?

Probably. For any endpoint defined in a +server.js file, you could conceivably define a +sw.js that deals with the same methods. The implementation would be analogous to +page.sw.js

Is this usecase important for SvelteKit?

If designed and implemented well, such a pattern for creating service-workers would make SvelteKit the most accessible framework for building PWAs and complex Webapps. At the moment, there really isn't any full-stack framework that deals with service-workers well.

This feature is not urgent. Most developers do not write PWAs, so it won't be considered a "missing" feature if it doesn't get implemented. There is a lot of stuff that is more urgent than this.

(The *.sw.* pattern doesn't interfere with anything. It could be added without breaking changes)

[spudunk]

Your suggestion is a great idea and would make things much nicer. Any updates on this? Did you find any good alternatives?

[stolinski]

Agreed. I saw this while looking for a solution.

[ynohtna]

This sounds very good. Co-locating custom service worker logic with the affected routes will be a great benefit to development and diagnosis.

[DePasqualeOrg]

I ran into this problem when building a PWA with SvelteKit. I think something like this should be given serious consideration for SvelteKit 3. Perhaps it could also be expanded to include layouts. There should simply be a way to progressively provide an offline fallback for every dynamic part of the app.

[ConProgramming]

This is a beautiful idea. Would love to see what the team thinks of this.