splash image

October 24, 2024

Vision for Workers Assets bindings

Static site generators and hosting platforms like Cloudflare Pages are great for technical users, but they pose challenges for folks who might not be familiar with things like git repos and build configurations.

What if anyone could sign up and publish a website on Cloudflare - zero install, zero build, just pick a template and start writing.

It's time

Cloudflare has the infrastructure now to make this a reality.

What's missing?

Here are 3 assets-related gaps I encountered while working on Presskit.

1. CRUD for static Assets through an assets binding

The last mile of handling requests and serving assets efficiently is the most important for reliability, simplicity and performance.

Content editing tools should be able to render HTML from markdown and serve the output as static assets.

The goal is to host the editor on Cloudflare, together with the site.

R2 and KV are lower level storage services, probably forming the basis for the assets service, but a higher level abstraction is required to handle static asset routing and caching. Users should not have to deploy additional worker code to serve static assets.

More about this here.

2. Multiple assets bindings in one worker

As an example, it's common for themes to include their own assets. A single worker should be able to serve assets from the theme (read-only), and also serve the static HTML content generated by the editor.

This capability would also be super useful when developing a site locally. Accessing the file system in a local dev environment is quite hard to do from worker code. Assets bindings would provide a nice clean way to do this.

3. API to list assets

This is a smaller feature but essential for serving sites e.g. to list blog posts without maintaining a separate index.

The old workers sites exposed the manifest of static file paths as a JSON string via __STATIC_CONTENT_MANIFEST. Something equivalent on the new assets binding would be great.

Thank you 🙏

debug

user: anonymous

{
  "path": "/blog/cloudflare-pages-level-up",
  "attrs": {
    "title": "Vision for Cloudflare Workers Assets bindings",
    "date": "2024-10-24",
    "layout": "BlogPostLayout",
    "splash": {
      "image": "/images/chimneys.webp"
    }
  },
  "md": "#  Vision for Workers Assets bindings\n\nStatic site generators and hosting platforms like Cloudflare Pages are great for technical users, but they pose challenges for folks who might not be familiar with things like git repos and build configurations.\n\n> What if anyone could sign up and publish a website on Cloudflare - zero install, zero build, just pick a template and start writing.\n\n### It's time\n\nCloudflare has the infrastructure now to make this a reality.\n\n- [Domains](https://developers.cloudflare.com/registrar/) and [DNS](https://developers.cloudflare.com/dns/) for naming.\n- [SSL](https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/) and [DDoS protection](https://developers.cloudflare.com/ddos-protection/) for security.\n- [Images](https://developers.cloudflare.com/images/) and [Stream](https://developers.cloudflare.com/stream/) for media.\n- [Workers](https://developers.cloudflare.com/workers/) and [Durable Objects](https://developers.cloudflare.com/durable-objects/) for stateless and stateful compute.\n- [D1](https://developers.cloudflare.com/d1/), [R2](https://developers.cloudflare.com/r2/), [KV](https://developers.cloudflare.com/kv/) for storing content.\n- [Queues](https://developers.cloudflare.com/queues/) and [Workflows](https://developers.cloudflare.com/workflows/) for reliable event handling.\n\n> What's missing?\n\nHere are 3 assets-related gaps I encountered while working on [Presskit](https://github.com/jldec/presskit/).\n\n### 1. CRUD for static Assets through an assets binding\n\nThe last mile of handling requests and serving assets efficiently is the most important for reliability, simplicity and performance.\n\nContent editing tools should be able to render HTML from markdown and serve the output as static assets.\n\n> The goal is to host the editor on Cloudflare, together with the site.\n\nR2 and KV are lower level storage services, probably forming the basis for the assets service, but a higher level abstraction is required to handle static asset routing and caching. Users should not have to deploy additional worker code to serve static assets.\n\nMore about this [here](https://jldec.me/blog/read-write-static-asset-bindings-for-cloudflare-workers).\n\n### 2. Multiple assets bindings in one worker\n\nAs an example, it's common for themes to include their own assets. A single worker should be able to serve assets from the theme (read-only), and also serve the static HTML content generated by the editor.\n\nThis capability would also be super useful when developing a site locally. Accessing the file system in a local dev environment is quite hard to do from worker code. Assets bindings would provide a nice clean way to do this.\n\n### 3. API to list assets\n\nThis is a smaller feature but essential for serving sites e.g. to list [blog posts](https://jldec.me/blog) without maintaining a separate index.\n\nThe old workers [sites](https://developers.cloudflare.com/workers/configuration/sites/start-from-worker/#getting-started) exposed the manifest of static file paths as a JSON string via `__STATIC_CONTENT_MANIFEST`. Something equivalent on the new assets binding would be great.\n\n> Thank you 🙏",
  "html": "<h1>Vision for Workers Assets bindings</h1>\n<p>Static site generators and hosting platforms like Cloudflare Pages are great for technical users, but they pose challenges for folks who might not be familiar with things like git repos and build configurations.</p>\n<blockquote>\n<p>What if anyone could sign up and publish a website on Cloudflare - zero install, zero build, just pick a template and start writing.</p>\n</blockquote>\n<h3>It's time</h3>\n<p>Cloudflare has the infrastructure now to make this a reality.</p>\n<ul>\n<li><a href=\"https://developers.cloudflare.com/registrar/\">Domains</a> and <a href=\"https://developers.cloudflare.com/dns/\">DNS</a> for naming.</li>\n<li><a href=\"https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/\">SSL</a> and <a href=\"https://developers.cloudflare.com/ddos-protection/\">DDoS protection</a> for security.</li>\n<li><a href=\"https://developers.cloudflare.com/images/\">Images</a> and <a href=\"https://developers.cloudflare.com/stream/\">Stream</a> for media.</li>\n<li><a href=\"https://developers.cloudflare.com/workers/\">Workers</a> and <a href=\"https://developers.cloudflare.com/durable-objects/\">Durable Objects</a> for stateless and stateful compute.</li>\n<li><a href=\"https://developers.cloudflare.com/d1/\">D1</a>, <a href=\"https://developers.cloudflare.com/r2/\">R2</a>, <a href=\"https://developers.cloudflare.com/kv/\">KV</a> for storing content.</li>\n<li><a href=\"https://developers.cloudflare.com/queues/\">Queues</a> and <a href=\"https://developers.cloudflare.com/workflows/\">Workflows</a> for reliable event handling.</li>\n</ul>\n<blockquote>\n<p>What's missing?</p>\n</blockquote>\n<p>Here are 3 assets-related gaps I encountered while working on <a href=\"https://github.com/jldec/presskit/\">Presskit</a>.</p>\n<h3>1. CRUD for static Assets through an assets binding</h3>\n<p>The last mile of handling requests and serving assets efficiently is the most important for reliability, simplicity and performance.</p>\n<p>Content editing tools should be able to render HTML from markdown and serve the output as static assets.</p>\n<blockquote>\n<p>The goal is to host the editor on Cloudflare, together with the site.</p>\n</blockquote>\n<p>R2 and KV are lower level storage services, probably forming the basis for the assets service, but a higher level abstraction is required to handle static asset routing and caching. Users should not have to deploy additional worker code to serve static assets.</p>\n<p>More about this <a href=\"https://jldec.me/blog/read-write-static-asset-bindings-for-cloudflare-workers\">here</a>.</p>\n<h3>2. Multiple assets bindings in one worker</h3>\n<p>As an example, it's common for themes to include their own assets. A single worker should be able to serve assets from the theme (read-only), and also serve the static HTML content generated by the editor.</p>\n<p>This capability would also be super useful when developing a site locally. Accessing the file system in a local dev environment is quite hard to do from worker code. Assets bindings would provide a nice clean way to do this.</p>\n<h3>3. API to list assets</h3>\n<p>This is a smaller feature but essential for serving sites e.g. to list <a href=\"https://jldec.me/blog\">blog posts</a> without maintaining a separate index.</p>\n<p>The old workers <a href=\"https://developers.cloudflare.com/workers/configuration/sites/start-from-worker/#getting-started\">sites</a> exposed the manifest of static file paths as a JSON string via <code>__STATIC_CONTENT_MANIFEST</code>. Something equivalent on the new assets binding would be great.</p>\n<blockquote>\n<p>Thank you 🙏</p>\n</blockquote>\n"
}