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.
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:
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.
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.
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 🚀🚀