WorkerApplication Build Pipeline

[runspired]

You may want to read the ReadMe section on Terminology before reading this Spec.

Architecture

ember g worker <worker-name>

A worker is placed in a pod within /app/workers/. Running the generator produces a Worker and an Interface within the worker pod.

• /app/workers/<worker-name>/interface.js
• /app/workers/<worker-name>/worker.js

A built WorkerApplication will be placed at assets/workers/<worker-name>.js.

Ideally, a worker should be able to use ES imports to include any dependency it needs, but this is tricky as WebWorker's and their relatives do not have access to DOM. Our build tooling should eventually be setup to allow us to include and configure a simple-dom instance ala fastboot on node. At the beginning, it will be on the end user to ensure that what they import will run in a DOMless environment.

WebWorkers can be created via a blob mechanism or via a script url. Our pipeline intends to produce scripts for use via the url method, which means that the build pipeline must produce a standalone script
for each worker in /app/workers/. Additionally, worker.js and interface.js need to remain as modules for use within the application for situations in which the WebWorker API is not available.

Bundling

To create a WorkerApplication, we bundle together interface.js and worker.js along with their dependencies and ember-skyrocket/worker-application, and place the modules in assets/workers/<worker-name>.js. This file must also be responsible for instantiating the worker via some mechanism like the below.

require('ember-skyrocket/worker-application').create({
  name: <worker-name>,
  interface: require('<app-name>/workers/<worker-name>/interface'),
  worker: require('<app-name>/workers/<worker-name>/worker')
});

[runspired]

Ping @aquamme

[runspired]

Implemented by #10