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.
GWicke updated the task description. (Show Details)
GWicke raised the priority of this task from to Needs Triage.
GWicke added a subscriber: GWicke.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 21 2015, 3:23 AM
GWicke triaged this task as High priority.Oct 21 2015, 3:24 AM
GWicke set Security to None.
GWicke edited subscribers, added: Jdlrobson, Jhernandez; removed: Aklapper.
GWicke updated the task description. (Show Details)Oct 21 2015, 3:54 AM
ori awarded a token.Oct 21 2015, 7:43 AM

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.

GWicke closed this task as Resolved.Oct 17 2016, 7:30 PM

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.