Encapsulating SSR Rendering (Isolation Mode)

[thescientist13]

Overview

The role of Workers and threads has had a bit of history in the Greenwood project. As part of the move to ESM, it was necessary to use this for cache busting ESM for SSR pages in development as there is currently no good way to do this in NodeJS like there was for CommonJS. The same was needed for API routes too.

This became the foundation of the Renderer plugin as well.

However, per #1088, the Worker implementation was refactored out of SSR builds to ship purely ESM files with no Worker overhead. The Renderer plugin was also refactored to not have to know anything about the runtime rendering context, be it in a Worker thread or not.

Thoughts

Aside from still being used to throttle SSR builds and for development time cache busting, should Workers still be considered for the project in any capacity where they are not explicitly? One of the initial thoughts aside from cache busting was that this could also be a good way to encapsulate rendering to avoid leaking DOM shim code into the global runtime, however for a lot of these cases serverless and edge function deployments I think would mostly mitigate this?

Currently Greenwood doesn't support multiple renderer plugins as once so probably no real chance of collisions, but I suppose i could see the case being made to still opt-in if desired?

[thescientist13]

So what are the options?

Outcomes

Well from an (long term) outcomes perspective I would like something that:

1. Provides Isolation (obviously) - At least for local server rendering (serverless is naturally immune to this problem), we want to make sure we aren't being an impediment to projects that faithfully representing web standards
   • https://github.com/lit/lit/blob/1b00c07a58707f45ad066809cd79f878fc3590d2/packages/labs/ssr-dom-shim/src/index.ts#L145
   • CustomElementsRegistry Spec Implementation alignment wcc#145
   • duplicate loads of the DOM shim leads to an infinite rendering issue wcc#147
   • demo/restore products page and upgrade to Lit v3 thescientist13/greenwood-lit-ssr#9
2. Is Web Standards (at least WinterCG) compatible - A critical criteria item will be if it is considered common to JavaScript and not any particular runtime. In other words, not just NodeJS
3. Server Only (Opt-In by default?) - Since serverless is immune to this (at least based on testing the same steps on Vercel / Netlify as when running greenwood serve locally), this only needs to happen when running greenwood serve

Worker Threads (Recommended - Short Term)

We already use a worker thread pool for pre-rendering and have used Workers in the past for SSR, so I think this is probably the most ideal solution for right now, unless the other two cases reveal themselves to be more compelling that it warrants even refactoring the pre-rendering pipeline. Essentially it would be reverting our earlier work but making sure to honor point 3 above.

Thoughts / Questions

1. Are worker threads "standard"? (e.g. WinterCG compatible)
   • I think this is NodeJS only? Should check with Deno and Bun as part of Agnostic Runtime #953

VM Modules

As recommended in the Lit docs, VM modules are an experimental feature in NodeJS, and related to v8

Lit SSR provides two different ways of rendering custom elements server-side: rendering in the global scope or via VM modules. VM modules utilizes Node's vm.Module API, which enables running code within V8 Virtual Machine contexts. The two methods differ primarily in how global state, such as the custom elements registry, are shared.

This requires a flag for Node (--experimental-vm-modules), and usage / implementation would look like this, which I think means we would have to contrive an entry point for.

// render-template.js
import {render} from '@lit-labs/ssr';
import {myTemplate} from './my-template.js';

export const renderTemplate = (someData) => {
  return render(myTemplate(someData));
};

// server.js
import {ModuleLoader} from '@lit-labs/ssr/lib/module-loader.js';
import {RenderResultReadable} from '@lit-labs/ssr/lib/render-result-readable.js';

// ...

// within a Koa middleware, for example
app.use(async (ctx) => {
  const moduleLoader = new ModuleLoader();
  const importResult = await moduleLoader.importModule(
    './render-template.js',  // Module to load in VM context
    import.meta.url          // Referrer URL for module
  );
  const {renderTemplate} = importResult.module.namespace;
  const ssrResult = await renderTemplate({some: "data"});
  ctx.type = 'text/html';
  ctx.body = new RenderResultReadable(ssrResult);
});

Its arguable I suppose if this is more or less ergonomic than a worker.

Thoughts / Questions

1. Are VM Modules "standard"? (e.g. WinterCG compatible)
   • I think this is a runtime specific implementation right now, but maybe its adopted by other runtimes? Should check with Deno and Bun as part of Agnostic Runtime #953
2. Is this more or less overhead than a Worker thread?

AsyncLocalStorage (Recommended - Long Term?)

So this is a newer API to NodeJS that to my understanding is purpose built for this sort of thing, allowing functions to own their context, by being wrapped in an Async hook

const http = require('node:http');
const { AsyncLocalStorage } = require('node:async_hooks');

const asyncLocalStorage = new AsyncLocalStorage();

function logWithId(msg) {
  const id = asyncLocalStorage.getStore();
  console.log(`${id !== undefined ? id : '-'}:`, msg);
}

let idSeq = 0;
http.createServer((req, res) => {
  asyncLocalStorage.run(idSeq++, () => {
    logWithId('start');
    // Imagine any chain of async operations here
    setImmediate(() => {
      logWithId('finish');
      res.end();
    });
  });
}).listen(8080);

http.get('http://localhost:8080');
http.get('http://localhost:8080');
// Prints:
//   0: start
//   1: start
//   0: finish
//   1: finish

So I guess it just comes down to understanding if we still support something like this

class Document {
  /* DOM Shim goes here */
}

globalThis.document = new Document()

Thoughts / Questions

1. Are worker threads "standard"? (e.g. WinterCG compatible)
   • Should check with Deno and Bun as part of Agnostic Runtime #953
2. Does this mean we wouldn't have to do any of that annoying request / response serialization and deserialization over the worker thread boundary with this?

---

I think Worker's is probably the best solution for right now for 1.x given we already / have used it and that assuming AsyncLocalStorage can support a "global" DOM context (e.g. globalThis.document) that seems like the more preferable long term solution for 2.x.