layout | logo | description | buttons |
---|---|---|---|
landing |
<picture>
<source srcset="assets/img/logo_d.svg" media="(prefers-color-scheme: dark)">
<img src="assets/img/logo_l.svg" alt="Logo" width="172" height="172">
</picture>
|
Worker Environments are the **new standard** for writing **HTTP servers** in JavaScript.
|
[Learn More](#state-of-worker-environments){:.btn.btn-primary} [Contribute](#contributing){:.btn.btn-default style="font-weight:normal"}
|
- Table of Contents {:toc .large-only}
Worker Environments are an adaptation of the Service Workers API, which is a browser standard for offline web applications. To give web developers more freedom over offline experiences, the specification includes a (minimal) HTTP server. Since it was published, other vendors have implemented this API for servers that run in the cloud — or on the edge in the case of Cloudflare Workers.
Typically, they also implement other browser APIs such as Fetch, Streams, and Web Cryptography, making their global scope similar to that of a Service Worker. We call them Worker Environments or Worker Contexts.
To see which vendors and APIs are available, check out the State of Worker Environments{:.heading} below. See the example below for a minimal HTTP server:
self.addEventListener('fetch', event => {
event.respondWith(new Response('Hello World'));
});
{:.larger}
Minimal example of a server written in a Worker Environment. {:.figcaption}
Worker Environments fulfill the original promise of NodeJS: To use one language and share code between client and server. In practice, this never came to be. Instead the worlds of node and browsers have diverged1. Worker Environments are bringing them back together.
This is good news for Frontend Developers in particular: The knowledge ac- and required for building offline web applications can now be applied to writing HTTP servers --- and so can the tools.
There is currently 1 (one) fully-featured Worker Environment and 1 (one) alternative being implemented. There are 3 (three) offline testing and development implementations. {:.note title="Summary"}
Cloudflare Workers is the most complete Worker Environment. It is currently the only one implementing the global fetch
event, bringing it on par with Service Workers. However, Deno is expected to follow shortly.
{:.fl style="max-width:22.5rem;margin-top: 1rem"}{:.no-mark title="Cloudflare Workers"} {:.fl style="max-height:8rem"}{:.no-mark title="Deno CLI"} {:.fl style="max-height:6.5rem;margin:.75rem"}{:.no-mark title="Deno Deploy"} {:.fl style="max-height:6rem; margin:1rem"}{:.no-mark title="cfworker/dev"} {:.fl style="max-height:8rem"}{:.no-mark title="Cloudworker"} {:.break-layout}
{:.clearfix}
Service Workers | Cloudflare Workers | Deno CLI | Deno Deploy | cfworker/dev | Cloudworker | cloudflare- worker-local |
|
---|---|---|---|---|---|---|---|
Domain | Browser | Edge | Server | Edge | Testing, Dev | Testing, Dev | Testing, Dev |
Open Source | ✅ | 🚫 | ✅ | ✅ | ✅ | ✅ | ✅ |
1.0 | ✅ | ✅ | ✅ | 🚫 | ✅ | 💀 | ✅ |
✅ : Supported
ℹ️ : Partial support / attention required
🔜 : Implementation in progress
👨💻 : Supported via 3rd party library / polyfill
❓ : Support to be determined
🚫 : Not supported {:.legend}
The center piece of any Worker Environment is an implementation of the global fetch
event.
Implementations of other browser APIs are necessary for bridging the gap between different worker environments.
API | Service Workers | Cloudflare Workers | Deno CLI | Deno Deploy | cfworker/dev | Cloudworker | cloudflare- worker-local |
---|---|---|---|---|---|---|---|
fetch event |
✅ | ✅ | 👨💻 | ✅ | ✅ | ✅ | ✅ |
install event |
✅ | 🚫 | ❓ | ❓ | 🚫 | 🚫 | 🚫 |
activate event |
✅ | 🚫 | ❓ | ❓ | 🚫 | 🚫 | 🚫 |
URL API | ✅ | ℹ️ | ✅ | ✅ | ✅ | ✅ | ✅ |
Fetch API | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Abort Controller | ✅ | 👨💻 | ✅ | ✅ | 👨💻 | 👨💻 | 👨💻 |
Encoding API | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Streams API | ℹ️ | ℹ️ | ✅ | ✅ | ✅ | ℹ️ | 🚫 |
Encoding Streams | ℹ️ | 🚫 | 🚫 | 🚫 | 🚫 | 🚫 | 🚫 |
Web Cryptography API | ✅ | ✅ | 🔜 | 🔜 | ✅ | ✅ | ✅ |
Cache API | ✅ | ℹ️ | ❓ | ❓ | ✅ | ℹ️ | ℹ️ |
WebSockets | ✅ | 🚫 | ✅ | ✅ | 🚫 | 🚫 | 🚫 |
Location API | ✅ | 👨💻️ | ✅ | ✅ | 👨💻 | 👨💻 | 👨💻 |
Timers | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
IndexedDB | ✅ | 🚫 | ❓ | ❓ | 🚫 | 🚫 | 🚫 |
The APIs below are either abandoned or do not have buy-in from major browser vendors. However, they can still be reasonable targets for 3rd party libraries, such as KV stores or cookie middleware.
API | Service Workers | Cloudflare Workers | Deno CLI | Deno Deploy | cfworker/dev | Cloudworker | cloudflare- worker-local |
---|---|---|---|---|---|---|---|
KV Storage API | 👨💻 | 👨💻 | 👨💻 | 👨💻 | 👨💻 | 👨💻 | 👨💻 |
Cookie Store API | ℹ️ | 👨💻 | 👨💻 | 👨💻 | 👨💻 | 👨💻 | 👨💻 |
These are useful APIs provided by one or more Worker Environment that aren't on any standards track (including abandoned).
API | Service Workers | Cloudflare Workers | Deno CLI | Deno Deploy | cfworker/dev | Cloudworker | cloudflare- worker-local |
---|---|---|---|---|---|---|---|
scheduled event |
🚫 | ✅ | 🚫 | 🚫 | 🚫 | 🚫 | 🚫 |
HTMLRewriter | 👨💻 | ✅ | 👨💻 | 👨💻 | ✅ | 👨💻 | 👨💻 |
KV | 🚫 | ✅ | 🚫 | 🚫 | ✅ | ℹ️ | ℹ️ |
Durable Objects | 🚫 | 🔜 | 🚫 | 🚫 | 🚫 | 🚫 | 🚫 |
No HTTP Server is complete without a Web Framework for common tasks such as routing, sessions, authentication, and more. Unfortunately, Worker Environments do not have a framework at the level of polish that is common in Node.js, yet.
However, you can try cfworker/web which is a Web framework inspired by Koa and fastify.
You can also check out worker-tools{:.external}, a collection of tools and libraries that achieve many of the same goals as a web framework, built by yours truly.
For more tools and libraries that work on Cloudflare Workers, check out Works on Workers.
Are you aware of any other Worker Environments available or in development? Did you find any inaccuracies in the tables above? Open a PR in the workers.js.org repository!
Worker Environments are not meant to provide everything traditional web servers did. They are better understood as the "glue" between browser clients and various API backends that have taken over much of their functionality. Consider the difference between traditional web architecture and the "API Economy":
How web services used to be written.
{:.figcaption}
The model for the next decade: Edge Workers sit between Service Workers and 3rd Party APIs.
{:.figcaption}
Taking this model to its logical conclusion, backends shrink to the size of API brokers. Scriptable Worker Environments are more than capable of playing that role.
<style> dl.legend { display: grid; grid-template-columns: repeat(auto-fill, 36px minmax(min(300px, 100%), 1fr)); grid-gap: 0.5rem; }
dl.legend dd { margin: 0; } table th:first-of-type { width: 220px; } table th:not(:first-of-type) { width: 180px; } table a::after { content: none!important; } </style>
Footnotes
-
Node and the browser have diverged due to a lack of browser APIs for many crucial components, including HTTP, streams, file access, and more more. A lot has changed since then. Standards have been written for all of these and more, often informed by the experience of using the node-equivalent. ↩