| pcx_content_type | title | meta | ||
|---|---|---|---|---|
concept |
How Workers works |
|
Though Cloudflare Workers behave similarly to JavaScript in the browser or in Node.js, there are a few differences in how you have to think about your code. Under the hood, the Workers runtime uses the V8 engine — the same engine used by Chromium and Node.js. The Workers runtime also implements many of the standard APIs available in most modern browsers.
The differences between JavaScript written for the browser or Node.js happen at runtime. Rather than running on an individual's machine (for example, a browser application or on a centralized server), Workers functions run on Cloudflare's global network - a growing global network of thousands of machines distributed across hundreds of locations.
{{}}Each of these machines hosts an instance of the Workers runtime, and each of those runtimes is capable of running thousands of user-defined applications. This guide will review some of those differences.
For more information, refer to the Cloud Computing without Containers blog post.
The three largest differences are: Isolates, Compute per Request, and Distributed Execution.
V8 orchestrates isolates: lightweight contexts that provide your code with variables it can access and a safe environment to be executed within. You could even consider an isolate a sandbox for your function to run in.
{{}}
{{}}A given isolate has its own scope, but isolates are not necessarily long-lived. An isolate may be spun down and evicted for a number of reasons:
- Resource limitations on the machine.
- A suspicious script - anything seen as trying to break out of the isolate sandbox.
- Individual resource limits.
Because of this, it is generally advised that you not store mutable state in your global scope unless you have accounted for this contingency.
If you are interested in how Cloudflare handles security with the Workers runtime, you can read more about how Isolates relate to Security and Spectre Threat Mitigation.
{{}}
Isolates are resilient and continuously available for the duration of a request, but in rare instances isolates may be evicted. When a Worker hits official limits or when resources are exceptionally tight on the machine the request is running on, the runtime will selectively evict isolates after their events are properly resolved.
Like all other JavaScript platforms, a single Workers instance may handle multiple requests including concurrent requests in a single-threaded event loop. That means that other requests may (or may not) be processed during awaiting any async tasks (such as fetch) if other requests come in while processing a request.
Because there is no guarantee that any two user requests will be routed to the same or a different instance of your Worker, Cloudflare recommends you do not use or mutate global state.
fetch()handler - Review how incoming HTTP requests to a Worker are passed to thefetch()handler.- Request - Learn how incoming HTTP requests are passed to the
fetch()handler. - Workers limits - Learn about Workers limits including Worker size, startup time, and more.