A design overview
Read first: In-Application Sandboxing with Web Workers. It explains the rationale behind using Web Workers.
And: Communicating with Workers using HTTP. It explains the rationale for choosing HTTP for messaging.
The TL;DR:
- Web Workers behave as Web services in a local HTTP namespace
- The Workers are fetched and spawned on-demand when a first request is sent to them, then closed after response (unless kept alive by the host page)
- Worker sandboxes are used to run untrusted code, so users can freely share them as plugins
By hosting plugins in Workers, Web pages act as "environments" - like a mini-OS - which exchange requests with the Workers in order to drive program behavior. Behavior is interpretted from Worker responses (for instance, GETing HTML to populate a region of the DOM) and from Worker requests (for instance, receiving a PUT of HTML to populate a region of a DOM).
Through hypermedia indexes, the environment and workers discover available APIs and configure at runtime, allowing users to change how the app works and where it shares data. The plugins and config system offer a way to protect privacy, contain & permission access (as Workers can only act through the environment), and support user/community extensions. The architecture is aimed squarely at removing host dependence in Web applications.
Small "temporary workers" demo - note, every time "Hello, World" or "World, Hello" is clicked, the worker is reconstructed to generate the next response.
Talk: "Composition through REST" @ Austin JS (2013)
Available libraries
- Local.js, an Ajax library that implements a client-side variation of HTTP.
- Servware, a straight-forward server framework
- nQuery, a jQuery network interface
- A WebRTC relay service for hosting the Worker services to other users.