RFC: Static Assets with Workers

This one is pretty straightforward. As a website developer, I would like to serve “static” assets on the internet. These are not user generated content, but usually stuff like html file, logos, maybe some images, etc.

The current options are:

• Workers Sites, which requires a combination of configuration ([site] in wrangler.toml) and code (configuring @cloudflare/kv-asset-handler). It’s incredibly fragile and not particularly liked by the community. It’s backed by KV. It also has issues with consistency since there’s no efficient way to expire assets, so during deploy it’s possible that some assets just 404. It was the only thing folks had for a while.
  • We should silently stop supporting this. We shouldn’t add a deprecation warning, and @cloudflare/kv-asset-handler should still get security updates and bugfixes, but we shouldn’t add any new features, and guide people towards newer solutions.
• Pages, which is an opinionated stack around Workers. Also backed by KV, but the implementation is not exposed to the user. They’ve announced a direct upload api, but it’s still not clear how it would integrate with a wrangler project.
  • If it’s a new project that’s centered around static assets, the recommendation is to simply start with Pages.
  • It’s hard to migrate an existing non-trivial project to use Pages (mostly because of missing features).
  • We can’t currently recommend people just use Pages for static assets until Pages specifies how that would work. (I… don’t know myself? How would it work? Does it require the convergence effort? How would routing work? And references? And previews? I suspect we’ll use the upload api as an implementation detail underneath an abstraction, possibly one of the below options)
• --experimental-public <path>: Exists in wrangler2. Backed by KV and kv-asset-handler, but the implementation is not exposed to the user. Light on features. Faces the same 404 issue as Sites. Particularly nice because it’s “zero config”

Plan 1: --assets <path>

• Rename --experimental-public to --assets
• Allow multiple values (--assets <path1> --assets <path2>)
• Add to wrangler.toml as assets
• Optionally have an object form { bucket: <bucket>, include: <glob>, ... }
  • bucket: path to assets
  • include: glob that matches files to include
  • exclude: glob that matches files to exclude
  • mount: path to mount to
• Implementation-wise, this can stick to using KV for now, but
  • We should move to using R2 to get past the 25 mb limit
  • We should start work on static-assets-as-a-cloudflare-primitive
  • We might use the Pages upload api for this
  • Gives us a path to solve the 404/consistency issues

Plan 2: imports

import ASSETS from "assets:path/to/bucket?include=glob&exclude=glob";

ASSETS.fetch(request, env); // env is required because it'll contain the kv (or whatever) binding 

• This is the story for people who’ll want deep customisation on how they want to handle static assets.
• With code/abstraction, they’ll be able to support usecases like those described vy the options in http://expressjs.com/en/resources/middleware/serve-static.html
• There’s a story here where we can graduate this to a proper web standard
• It’s critical that we figure out how to make this work with jest etc

Plan 3: File loader

Adds a new type to rules config

[[rules]]
type = "file"
globs = "glob/*.png"

import styles from style.css;

console.log(styles);
// http://something.com/path/to/style.css

• This is useful for serving single files
• Further useful to use as references (href/src) in html
• For files below a particular size, we could embed them directly in the Worker (with data: uris, but this requires the WOrkers runtime to support this as well)

Plan 4: Integrate Pages

We should come up with a plan to integrate Pages for assets directly into a wrangler project

Open questions:

• Should we use Pages upload API?
• R2?
• What’s a good solution for expiring assets?
• With versioning, we won’t be able to ‘delete’ assets like we now do.
• How can we hide the kv namespaces we make?
• Overall, is there a cloudflare story for first class static assets?

[rozenmd]

I was just thinking out loud how it’s cool how it’s almost possible to deploy a static eleventy site in 3 commands:

echo '# Page header' > README.md
npx @11ty/eleventy
npx wrangler publish --assets _site 

I’m thinking if an assets flag is provided, that should be enough for us to provide a boilerplate worker, and run dev/deploy with no further config required.

Folks can of course provide their own worker script if they’d like, but I’m thinking it shouldn’t be a requirement any more.

[threepointone]

Potentially related https://github.com/tc39/proposal-import-reflection