Add local SSR/CSR to Service Workers.

[Mooshua]

Describe the problem

Currently, it is difficult to do “offline first” in SvelteKit. If you want to bring a page from the cache instead of going over the web (especially in cases where the web is unavailable), you can only provide responses for when the server was pinged, with the server’s SSR instead of your own. With Kit’s client-side routing, it is unknown if a site will even be loaded at all.

Using Workbox would help, but that still doesn’t solve the problem of serving dynamic svelte content to users from a service worker.

Describe the proposed solution

The proposed solution would be to export new functionality to the service workers, such as “render_page”, which will look up the corresponding URL in an internal dictionary and perform SSR rendering with required props.

Another solution to this issue would be to expose more metadata, and a CSR html template, to the service worker. It’d have the same effect while being smaller and more flexible, and probably much easier to implement. This would be a great solution as well, as it’s probably faster do to CSR once than to do SSR and then hydrate it.

This would enable offline-first usage at high scale. A good example would be a storefront—it’s much more efficient to cache some JSON data of all products than to store all of the HTML for a single product.

Alternatives considered

Initially, I considered doing some voodoo magic to create an HTML template which would work to perform CSR upon loading in an offline situation, but this proved to be extraordinarily difficult, as it is hard to tell which Vite bundles are needed per-page with the information provided (not that you can’t find a way to do it…)

I’ve also tried caching the SSR pages, but again, it is a lot of content, and wouldn’t be readable eg. For a storefront or blog.

Importance

nice to have

Additional Information

No response

[thomasfosterau]

I know it’s been almost three years... but I’m going to resurrect this because I’ve got a project where this would be a very valuable feature and it might be worth my while to draw the rest of the proverbial owl.

Essentially, I’m working on a SvelteKit app which has a lot of dynamic routes, most of which have data which can be stored/cached in IndexedDB (or an alternative storage solution). Currently, I can access IndexedDB in +page.ts, but that’s only available if the user has already visited the page. As a fallback, the service worker can serve a cached page, but that’s only possible if the user has previously visited the page. There would be some enormous user experience wins if the service worker could sensibly respond to any request.

The sort of API for this that would address the use cases I have would be:

• The $service-worker module should export a respond function, which takes a FetchEvent and returns a Promise<Response>. The respond function would mostly work like the Server#respond method made available to adapters.
• Any module available on the client would be made available in a service worker, such as $app/environment. This could be a separate issue, I don’t see what the problem would be with this besides needing sensible defaults.
• $app/environment could provide a serviceWorker export, analogous to browser.
• In a service worker, +layout.ts and +page.ts would run, but +layout.server.ts and +page.server.ts would not be run. Instead, there would be a +layout.worker.ts and +page.worker.ts files instead. +{layout,page}.worker.ts would be given a server() function, similar to how parent() works, and would get the properties available on FetchEvent instead of platform.
• In a service worker, a +worker.ts file would substitute for +server.ts. Again, +worker.ts would be able to call sever() to run the +server.ts endpoint.

The SvelteKit codebase seems to have changed a bit since I last attempted a PR which added this functionality so I wouldn’t mind some guidance as to what a ‘mergeable' implementation would look like. In particular, I think there’s a trade-off to be made between flexibility and maintainability when it comes to how much code can realistically be shared between the server and service worker implementations — would an internal sui generis adapter for service workers be an option?