Service Worker Side Rendering #188

thepassle · 2022-05-02T11:33:02Z

thepassle
May 2, 2022
Collaborator

This weekend I worked on a bit of a crazy PoC to see if I can run Astro in a service worker, and it turns out that you totally can:

astro-sw.mov

This is huge, because:

Your Astro apps are now available offline, as well as installable as PWA's
This dramatically reduces the function invocations of the provider your app is deployed on
There currently is not a single framework that makes PWA-ifying MPA's as easy as this

This lead to a bunch of other thoughts on how to improve this, and try to see how far I can take this. Currently the implementation I hacked together for this is a bit hacky and lives here thepassle/astro-service-worker. It's currently implemented as an adapter. This is not ideal, because currently having only 1 adapter in your astro.config.mjs is supported.

Looking at Astro's source code, I realized perhaps a better fit would be an integration, that adds a vite/rollup plugin that creates a virtual mode to bundle the service worker code. I have some code put together in this gist to make this happen, but there are a few missing pieces of the puzzles, which I'll attempt to describe here.

Missing pieces/apis to make this happen

Ideally, this would be be an integration, used like so:

import { defineConfig } from 'astro/config';
import netlify from '@astrojs/netlify';

export default defineConfig({
  adapter: netlify(),
  integrations: [serviceWorker()]
});

There are a few things missing to make this happen though. In order to create the service worker bundle, I need to have access to the SSR Manifest, which currently is not available in any of the integration hooks or vite/rollup hooks. I've created an issue for this here.

Additionally, it'd be nice to be able to import the manifestReplace and pagesVirtualModuleId, but they are not available in astro/core's package export map. I've currently copied them from Astro's source code, and hardcoded them in my code, but this is fragile, because if Astro changes them, my code will break.

Ideally, I'd also have access to the pageData in my integration/vite plugin, which is in internals via eachPageData(internals), but internals is not exposed anywhere either. Having access to internals also gives greater control over which code should be server-only and service-worker-only.

Taking things to the next level: Streaming, offline-capable Astro apps

Then, I was reminded of this get-together by Jeff Posnick and Luke Edwards: https://cloudflare.tv/event/6ZJ5mEjrgcnCtBXBsUtyqV and Jeff's demos of streaming service workers.

Dreaming even further, it would be even more amazing to be able to stitch together stream responses in Astro components.

---
import Header from '../src/components/Header.astro';
import Sidemenu from '../src/components/Sidemenu.astro';
import Footer from '../src/components/Footer.astro';
import { streamable } from 'astro';
---
<html>
  <Header/>
  <Sidemenu/>
  {streamable(() => fetch('/content/foo.md').then(render))}
  <Footer/>
</html>

In a similar fashion to this Workbox example:

import { strategy } from 'workbox-streams';
import { registerRoute } from 'workbox-core';

const streamResponse = strategy([
  () => caches.match(HEADER_CACHE_KEY, {cacheName: CACHE_NAME}),
  () => `<nav>sidebar<ul><li><a href="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/about">about</a></li></ul></nav>`,
  ({event}) => apiStrategy.handle({
    event: event,
    request: new Request('/content/foo.md'),
  }),
  () => caches.match(FOOTER_CACHE_KEY, {cacheName: CACHE_NAME}),
]);

registerRoute('/foo', streamResponse);

As Alex Russell says:

This is awesome because it means that you can now get the document starting to request your (SW cached) CSS, JS, and other "header" resources in parallel with SW startup and the network fetch. None of the steps serialise until content comes back.

Given that the render function is a tagged template literal which returns an AstroComponent, it seems like something like this should not be completely impossible in the future, but likely requires some changes in Astro.

class AstroComponent {
  constructor(htmlParts, expressions) {
    this.htmlParts = htmlParts;
    this.expressions = expressions;
  }
  get [Symbol.toStringTag]() {
    return "AstroComponent";
  }
  *[Symbol.iterator]() {
    const { htmlParts, expressions } = this;
    for (let i = 0; i < htmlParts.length; i++) {
      const html = htmlParts[i];
      const expression = expressions[i];
      yield markHTMLString(html);
      yield _render(expression);
    }
  }
}

E.g.: if expression.type === 'streamable', execute the callback which returns the stream, and stream it along to the browser.

matthewp · 2022-05-02T14:45:10Z

matthewp
May 2, 2022
Maintainer

Big +1 from me. Would want to talk about implementation details though. Want to avoid exposing a lot of internal code publicly that prevents us from making changes (don't want to accidentally break integrations).

Can you explain what it is you want to do with manifestReplace, pagesVirtualModuleId and internals?

Streaming seems like a separate issue to me. We are very close to having streaming work without needing any special user-code at all. Assuming that a service worker integration is creating an App instance like in SSR, that should just work once we finish off streaming.

20 replies

matthewp May 3, 2022
Maintainer

I get what you mean, that does seem like we probably want a separate bundle then. The same way that client / server get separate builds. So I think allowing an array of adapters is the answer here, where each one gets a separate build run on it, with some ability to control which routes are rendered like your suggestion here.

thepassle May 3, 2022
Collaborator Author

But even if you make it a separate bundle, you still need access to the pageData to construct the imports

thepassle May 3, 2022
Collaborator Author

Ah, sorry, I see what you're saying. Yeah, with multiple adapters that would be doable, but then you do need something like the pageFilter api I proposed above.

Looking into the code, it seems like allowing an array of adapters is a non-trivial change though

matthewp May 3, 2022
Maintainer

Based on the discussion in the API call, I think the next approach to take is to make your integration push in a top-level entrypoint. You can see where the SSR plugin does the same thing here: https://github.com/withastro/astro/blob/main/packages/astro/src/core/build/vite-plugin-ssr.ts#L29-L31

Then I think you will need the pageData object, like you said. We might need another new hook to provide that at the time when you need it.

gedw99 Oct 15, 2022

What I'm trying to achieve is having a way of having server-only route handlers. Like, for example maybe my app needs to access a database, it'd be great to have my database connection/endpoint code in the same codebase. However, that endpoint will likely use dependencies that wont work in the browser/service worker, so I'd need to exclude those from the service worker bundle.

But if you're goal is just to avoid calling API routes then I would think your SW code could handle that. When you call app.match(request) it returns a Route object which tells you if it's an API route. You can simple not call app.render(request) on those.

Yeah thats the implementation I have currently, but that would mean I'd have to deploy a separate app for doing server-only stuff.

Hey @thepassle

There is a quasi spec for exactly this problem that I use for running “apps” in browser or on servers.

https://github.com/deislabs/bindle/blob/main/docs/webassembly.md

I currently use this with Wazero and Spin and am working on using it in Service workers as well.

Woukd be curious what you think ??

thepassle · 2022-05-02T16:02:02Z

thepassle
May 2, 2022
Collaborator Author

Sidestepping the other thread a little bit for this discussion:

Streaming seems like a separate issue to me. We are very close to having streaming work without needing any special user-code at all. Assuming that a service worker integration is creating an App instance like in SSR, that should just work once we finish off streaming.

Is there anywhere I can see this in action/progress? This already sounds great, but I'd love to make sure we'd be able to do something similar to the workbox example:

import { strategy } from 'workbox-streams';
import { registerRoute } from 'workbox-core';

const streamResponse = strategy([
  () => caches.match(HEADER_CACHE_KEY, {cacheName: CACHE_NAME}),
  () => `<nav>sidebar<ul><li><a href="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/about">about</a></li></ul></nav>`,
  ({event}) => apiStrategy.handle({
    event: event,
    request: new Request('/content/foo.md'),
  }),
  () => caches.match(FOOTER_CACHE_KEY, {cacheName: CACHE_NAME}),
]);

registerRoute('/foo', streamResponse);

5 replies

matthewp May 2, 2022
Maintainer

The way streaming in Astro would work is that each component blocks only itself. So if you had a component that did an API request in frontmatter, that would block rendering the template. But any other components that come before would not. So for example:

---
---
<Nav />
<FooContent />

Nav would be sent right away but FooContent would wait on API requests/etc. Does that answer your concerns?

There's possibly a little bit of work to get streaming, but not a lot. We need to get it prioritized, probably via an RFC of its own.

thepassle May 3, 2022
Collaborator Author

What I'd really like to avoid is what Jake Archibald describes in this blog:

HTML renders as it downloads, whether it's served straight from a server or via a service worker. But I'm fetching the content from the page using JavaScript, then writing it to innerHTML, bypassing the streaming parser. Because of this, the content has to be fully downloaded before it can be displayed, and that's where the two second regression comes from. The more content you're downloading, the more the lack of streaming hurts performance, and unfortunately for me, Wikipedia articles are pretty big (the Google article is 100k).

I understand that it could be cases where <FooContent/> does a network request that it has to wait for to finish completely, but in some cases the response could be streamed as well. Considering fetch's response.body is a stream as well, it'd be amazing to be able to write the following as a first class citizen:

/blog/[id].astro:

---
import Header from '../src/components/Header.astro';
import Sidemenu from '../src/components/Sidemenu.astro';
import Footer from '../src/components/Footer.astro';
---
<html>
  <Header/>
  <Sidemenu/>
  {fetch(`/blog/${id}.html`).catch(() => {
    return caches?.match?.('/404.html') || fetch('/404.html');
  })}
  <Footer/>
</html>

Where <Header/> and <Sidemenu/> are completely static and can be streamed immediately, and then the result of the fetch can be streamed as well; as opposed for waiting for the fetch to completely finish downloading, and only then start streaming the result of the fetch. (The example that Jake Archibald gives in his article is: Wikipedia articles can be pretty large, itd be great to immediately start streaming the response, instead of waiting for the entire article to have downloaded and then start responding)

Or even something being able to do something like:

---
import Header from '../src/components/Header.astro';

function* renderLongList() {
  yield "item 1";
  yield "item 2";
}
---
<html>
  <Header/>
  {renderLongList()}
</html>

matthewp May 3, 2022
Maintainer

Right, I think you are asking for support for Promises and Iterables in the Astro expression syntax right? Makes sense to me to add that.

thepassle May 3, 2022
Collaborator Author

Awesome 🙂

thepassle May 16, 2022
Collaborator Author

Following up on this, I've been hacking on this a little bit more, and here's some results:

stream-astro.mov

Added some artificial delays for developing purposes. I am getting some double logs in my console, so it seems like I may be doing some unnecessary work (that I havent debugged yet), but for an exploration im not unhappy with the results.

It also supports inlining iterables and readable streams in astro expressions, e.g.:

<div>
{() => fetch('/blog.html').then(r => r.body)}
</div>

The only issue is that I'm currently completely omitting the headInjection. I think you could work around that by keeping some kind of buffer before streaming, and if the buffer includes </head>, do the headInjection there, and send that.

The approach I took is largely: yield all the things. I tweaked the renderPage, render, _render, renderComponent and renderSlot functions to yield instead, and then creating a new ReadableStream and sending that as the response. Supporting iterables and readable streams is largely the same as @natemoo-re 's approach in microstream here: https://github.com/natemoo-re/microstream/blob/main/lib/mod.ts#L186-L218

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Service Worker Side Rendering #188

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 2 comments 25 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

Select a reply

Service Worker Side Rendering #188

thepassle May 2, 2022 Collaborator

Missing pieces/apis to make this happen

Taking things to the next level: Streaming, offline-capable Astro apps

Replies: 2 comments · 25 replies

matthewp May 2, 2022 Maintainer

matthewp May 3, 2022 Maintainer

thepassle May 3, 2022 Collaborator Author

thepassle May 3, 2022 Collaborator Author

matthewp May 3, 2022 Maintainer

gedw99 Oct 15, 2022

thepassle May 2, 2022 Collaborator Author

matthewp May 2, 2022 Maintainer

thepassle May 3, 2022 Collaborator Author

matthewp May 3, 2022 Maintainer

thepassle May 3, 2022 Collaborator Author

thepassle May 16, 2022 Collaborator Author

thepassle
May 2, 2022
Collaborator

Replies: 2 comments 25 replies

matthewp
May 2, 2022
Maintainer

matthewp May 3, 2022
Maintainer

thepassle May 3, 2022
Collaborator Author

thepassle May 3, 2022
Collaborator Author

matthewp May 3, 2022
Maintainer

thepassle
May 2, 2022
Collaborator Author

matthewp May 2, 2022
Maintainer

thepassle May 3, 2022
Collaborator Author

matthewp May 3, 2022
Maintainer

thepassle May 3, 2022
Collaborator Author

thepassle May 16, 2022
Collaborator Author