I've been following Bunny (BunnyCDN/Bunny.net) for a while and love what they are doing. Couple of suggestions:
• Every code snippet should be copy/pasteable (and work well), that article might be the entry point to what many are doing.
• I have this feeling this is following Cloudflare's Workers style of `addEventListener('fetch', eventHandler);`. I need to write a 500-word essay on that, but the short version is that I strongly believe that it'd be way better for their clients if the client could just do `export default async function handleDns(event) { ... }` instead of having a global (what?) context where there's a function unattached called `addEventListener` and you need to know it's for `"dns"` (is there even other possibility here?) and that the respondWith() only accepts a promise, which is not common (it's more common to accept an async fn which then becomes a promise). Compare these two snippets, current and with my small proposal:
// Current API:
addEventListener('dns', event => {
event.respondWith(handleRequest(event.request));
});
function handleRequest(request) {
return new TxtRecord('Hello world!, 30);
}
vs
// Potential/suggested API:
export default function handleDns(event) {
return new TxtRecord('Hello world!, 30);
}
This way it's easier to write, to reason about, to test, etc. It's all advantages from the client point of view, and I understand it's slightly more code from Bunny's point of view but it could be done fairly trivially on Bunny's end; they could just wrap the default export with this code on their infra level, simplifying and making dev lives a lot easier:
// Wrapper.js
import handler from './user-fn.js';
addEventListener('dns', event => {
if (typeof handler === 'function') {
event.respondWith(handler(event));
} else {
// Could support other basic types here, like
// exporting a plain TxtRecord('Hello', 30);
throw new Error('Only handler functions supported now');
}
});