October 3, 2024

Read-write Static Assets bindings for Cloudflare Workers

When Cloudflare announced their new static assets feature for workers last week, I was happy to see support for assets bindings

Bindings provide API access to other services from your worker. You can even call other workers. I recommend both blog posts by Kenton Varda about bindings and RPC.

Workers can already use the new assets binding to GET static assets which were uploaded as part of the worker deployment.

BUT what if workers could also create, update, or delete assets using the assets binding API? This would enable workers to render and serve static content directly.

What about KV or R2?

Workers can write to KV and R2, so why not use those services instead, particularly since R2 already supports large objects, CORS, and http headers?

The short answer is that KV and R2 feel like lower level storage services.

Serving static assets means supporting:

.html files for naked routes
index.html for directory routes
content-type headers
cache control headers
compression
trailing slashes
redirects
SPA support

Layering the static assets API on top of KV and R2 might make sense, perhaps with the use of a DO (Durable Object) for concurrency control.

KISS

Another benefit of serving static assets is that they work without running worker code. The features above are quite generic yet non-trivial to implement.

Static assets are simple and cheap and easy to operate reliably. And, the platform can handle caching, making them faster.

The Web FTW

Wouldn't it be awesome if consumers could self-host their own content creation tools, and self-publish on the Web?

Creating content for the Web is not just a developer activity.

The Web is for everyone 🚀🚀

debug

user: anonymous

{
  "path": "/blog/read-write-static-asset-bindings-for-cloudflare-workers",
  "attrs": {
    "title": "Read-write Static Assets bindings for Cloudflare Workers",
    "date": "2024-10-03",
    "splashimage": "/images/berries.webp",
    "layout": "BlogPostLayout"
  },
  "md": "# Read-write Static Assets bindings for Cloudflare Workers\n\nWhen Cloudflare announced their new [static assets](https://jldec.me/blog/building-a-static-site-with-cloudflare-workers) feature for workers last week, I was happy to see support for [assets bindings](https://developers.cloudflare.com/workers/static-assets/binding/#binding)\n\nBindings provide API access to other services from your worker. You can even call other workers. I recommend both blog posts by [Kenton Varda](https://x.com/kentonvarda) about [bindings](https://blog.cloudflare.com/workers-environment-live-object-bindings/) and [RPC](https://blog.cloudflare.com/javascript-native-rpc/).\n\nWorkers can already use the new `assets` binding to `GET` static assets which were uploaded as part of the worker deployment.\n\nBUT what if workers could also create, update, or delete assets using the assets binding API? This would enable workers to render and serve static content directly.\n\n### What about KV or R2?\n\nWorkers can write to [KV](https://developers.cloudflare.com/kv/) and [R2](https://developers.cloudflare.com/r2), so why not use those services instead, particularly since R2 already supports large objects, CORS, and http headers?\n\nThe short answer is that KV and R2 feel like lower level storage services.\n\nServing static assets means supporting:\n\n- .html files for naked routes\n- index.html for directory routes\n- content-type headers\n- cache control headers\n- compression\n- trailing slashes\n- redirects\n- SPA support\n\nLayering the static assets API _on top_ of KV and R2 might make sense, perhaps with the use of a DO (Durable Object) for concurrency control.\n\n### KISS\n\nAnother benefit of serving static assets is that they work without running worker code. The features above are quite generic yet [non-trivial](https://developers.cloudflare.com/workers/static-assets/routing/#alternate-configuration-options) to implement.\n\nStatic assets are simple and cheap and easy to operate reliably. And, the platform can handle caching, making them faster.\n\n### The Web FTW\n\nWouldn't it be awesome if consumers could self-host their own content creation tools, and self-publish on the Web?\n\nCreating content for the Web is not just a developer activity.\n\n> The Web is for everyone 🚀🚀",
  "html": "<h1>Read-write Static Assets bindings for Cloudflare Workers</h1>\n<p>When Cloudflare announced their new <a href=\"https://jldec.me/blog/building-a-static-site-with-cloudflare-workers\">static assets</a> feature for workers last week, I was happy to see support for <a href=\"https://developers.cloudflare.com/workers/static-assets/binding/#binding\">assets bindings</a></p>\n<p>Bindings provide API access to other services from your worker. You can even call other workers. I recommend both blog posts by <a href=\"https://x.com/kentonvarda\">Kenton Varda</a> about <a href=\"https://blog.cloudflare.com/workers-environment-live-object-bindings/\">bindings</a> and <a href=\"https://blog.cloudflare.com/javascript-native-rpc/\">RPC</a>.</p>\n<p>Workers can already use the new <code>assets</code> binding to <code>GET</code> static assets which were uploaded as part of the worker deployment.</p>\n<p>BUT what if workers could also create, update, or delete assets using the assets binding API? This would enable workers to render and serve static content directly.</p>\n<h3>What about KV or R2?</h3>\n<p>Workers can write to <a href=\"https://developers.cloudflare.com/kv/\">KV</a> and <a href=\"https://developers.cloudflare.com/r2\">R2</a>, so why not use those services instead, particularly since R2 already supports large objects, CORS, and http headers?</p>\n<p>The short answer is that KV and R2 feel like lower level storage services.</p>\n<p>Serving static assets means supporting:</p>\n<ul>\n<li>.html files for naked routes</li>\n<li>index.html for directory routes</li>\n<li>content-type headers</li>\n<li>cache control headers</li>\n<li>compression</li>\n<li>trailing slashes</li>\n<li>redirects</li>\n<li>SPA support</li>\n</ul>\n<p>Layering the static assets API <em>on top</em> of KV and R2 might make sense, perhaps with the use of a DO (Durable Object) for concurrency control.</p>\n<h3>KISS</h3>\n<p>Another benefit of serving static assets is that they work without running worker code. The features above are quite generic yet <a href=\"https://developers.cloudflare.com/workers/static-assets/routing/#alternate-configuration-options\">non-trivial</a> to implement.</p>\n<p>Static assets are simple and cheap and easy to operate reliably. And, the platform can handle caching, making them faster.</p>\n<h3>The Web FTW</h3>\n<p>Wouldn't it be awesome if consumers could self-host their own content creation tools, and self-publish on the Web?</p>\n<p>Creating content for the Web is not just a developer activity.</p>\n<blockquote>\n<p>The Web is for everyone 🚀🚀</p>\n</blockquote>\n"
}