- Overview
- Usage
- Generating a Worker
- Creating the Worker
- Worker Primitives
- Using a Worker
- Implementation Details
- WorkerService
- Interface
- Inject Helper
- WorkerShell
- WorkerApp
- Worker
- Shared Worker
- Service Worker
- Build Tooling
Skyrocket is an attempt to eliminate the friction of building and using Workers, unlocking applications that consistently function at 60fps even in the most advanced use cases in hostile environments.
Skyrocket wants to help you separate your app's major concerns.
- data-threads for data requests and processing
- ui-threads for pre-rendering
- service-threads for long running tasks
- helper-threads for parallel computing
It additionally aims to utilize DOMless Ember and fastboot’s rehydration mechanisms to provide a simple interface for assisting in expensive render situations.
Links
- Introductory Blog Post
- Svelte Render Slides
- Pokedex (by Nolan Lawson)
- Pokedex Implementation Blog Post
ember g worker foo
/app/workers/foo/
interface.js
worker.js
ember g shared-worker foo
/app/workers/foo/
interface.js
worker.js
ember g service-worker
/app/service-worker/
interface.js
worker.js
Reach Goal: Eventually, additional worker blueprints may be created for workers devoted to specific types of behavioral needs, such as access to the data store, a SimpleDom instance, or an entire app-instance.
The Interface is like a Model for your Worker, it declares the various asynchronous primitives the worker and your app will be using to communicate, and is used to generate a Service-like object in your app through which to do so.
import { Interface, Primitives: p } from 'skyrocket';
export default Interface.extend({
foo: p.snapshot(),
bar: p.method(),
baz: p.event({ outbound: false }), // specify an inbound (to the main thread) only event
spam: p.event({ inbound: false }), // specify an outbound (to the worked) only event
eggs: p.stream(),
ham: p.observable()
});The Worker is the stand alone mini-application that will be created when an Interface is instantiated. It should implement the primitives that the Interface defines.
import { Worker } from 'skyrocket';
import interface from './interface';
export default Worker.extend({
interface: interface,
foo: 'hello world',
bar() {
// do something
},
onSpam: on('spam', function() {})
});Snapshot
Primitive.snapshot()is the last known value of a property within the worker.- Snapshots will update as quickly as possible, but they do not necessarily represent the current state of the value within the worker.
Method
Primitive.method()specifies a method on the worker you are capable of invoking from the main thread. You will always receive a promise that resolves with the final outcome returned by the method, or rejects with an error thrown by it.- Promises returned from the method in the worker which is invoked will be waited on their outcome is what will be returned to the main thread.
Event
Primitive.event()specifies an event that you can either trigger on the worker or listen for from the worker. By default, an event is allowed to go either way (a worker can trigger it or the app can trigger it), but you can restrict the direction by setting inbound/outbound to true/false as desired.- To send an event
- to a worker:
interface.trigger(‘<event-name>’, <event>) - from a worker:
this.trigger(‘<event-name>’, <event>)
- to a worker:
- To receive an event
on(‘<event-name>’, (event) => {})
- when you trigger an event, it triggers both in the app and in the worker and vice-versa
Observable
- https://egghead.io/lessons/javascript-introducing-the-observable
- https://github.com/Reactive-Extensions/RxJS
- http://reactivex.io/documentation/observable.html
- https://github.com/zenparsing/es-observable
Stream
Buffer?
- not all stream sources buffer the same way:
- pretty good tutorial on streaming/buffering
You use a worker much like you would use a service.
export default Component.extend({
geolocation: inject.worker('geolocation'),
latitude: computed.alias('geolocation.latitude'),
getSomeData() {
return this.get('geolocation')
.doFooThing()
.then((data) => {
// do something with data
});
}
});Except for your ServiceWorker, you can use more than one instance of a worker if needed.
inject.worker('foo') // uses foo:main
inject.worker('foo:main') // looks up an instance of worker 'foo' named 'main', instantiates if needed.
inject.worker('foo:bar') // looks up an instance of worker 'foo' named 'bar', instantiates if needed.Responsibilities
- Stores feature/API detection results
- Sets up backburner queues for when it’s necessary to execute worker modules on the main thread.
Responsibilities
- Models interaction between the worker and the main thread.
- Instantiates the worker / tears it down as necessary.
- Runs feature detection if needed
- Provides abstractions overtop of postMessage so that developers can interact with the worker via more typical asynchronous programming patterns.
Responsibilities
- lazily resolve an interface and instantiate it if necessary
- allow multiple workers of the same type to co-exist with separate names
Responsibilities
- fallback for when the Worker api is not available on a platform
- creates an isolated scope for the module with worker-like APIs
- executes worker tasks in backburner queues that occur after
afterRender.- potentially in the next tick
- should it run the worker in an iFrame (clean scope, separate memory context)?
Responsibilities
- instantiates the worker (within the worker context)
- performs feature detection work if necessary
Responsibilities
- Provides abstractions overtop of postMessage so that developers can interact between the worker and the main thread via more typical asynchronous programming patterns.
- Implements the worker end of the Interface
Responsibilities
- Extends Worker, uses SharedWorker base class if available, else falls back to worker + main thread polyfill.
- Do we want to do this? Can we channel between workers another way?
- Only One is allowed
- Extends SharedWorker, uses ServiceWorker base class if available, else falls back to SharedWorker (and beyond).
- Should the fallback do things like utilize AppCache?
Packaging
- You write a worker as any other ES6 module, but it has to be a single script when executed. We’ll use babel + broccoli + register a custom filter tree with ember-cli-packager to build 2 final output files, one for the main-thread fallback and one as the stand-alone worker script.
Engines
- We can probably load the main thread worker into the app via the engine mechanics if needed, else some simple ajax fetching / module resolution primitives will get the job done.