Page MenuHomePhabricator

Provide server-side ServiceWorker interfaces
Closed, ResolvedPublic

Description

In order to run service-worker code on the server, we'll need to provide the interfaces available in the browser:

  • Registration to a scope. This introduces a very basic routing scope, but most finer-grained routing is likely to happen inside the service worker.
  • fetch, possibly via https://github.com/matthew-andrews/isomorphic-fetch
    • This also provides a basic Response implementation, wrapping the node HTTP response object.
  • Request wrapper for Node's IncomingMessage.
  • Cache. On the server, we might want to use this for in-process caching of frequently-used fragments.

Event Timeline

GWicke raised the priority of this task from to Needs Triage.
GWicke updated the task description. (Show Details)
GWicke subscribed.
GWicke set Security to None.
GWicke edited subscribers, added: Jdlrobson, Jhernandez; removed: Aklapper.

This doesn't make sense to me in current written form. Can you elaborate?

Why would we want to run service worker code on the server? The goal is unclear to me right now.

@Jdlrobson, T111588 describes the overall idea. Basically, clients without ServiceWorker support will get the same content pre-expanded on the server, using the same code running in nodejs instead of an actual ServiceWorker. This requires defining the same interfaces, which this task is about.

The first iteration of this is now complete, and has sufficient API support to run sw-toolbox based ServiceWorkers. Performance is looking very promising, supporting 1500+ render requests per second using a simple streaming ServiceWorker on a laptop.