Support for Cloudflare Workers

[davidmytton]

Allow us to support applications built on Cloudflare workers. There's a lot of useful data in the request context cf property we could make use of.

[blaine-arcjet]

This is blocked by Connect RPC's requirement to construct a client with a baseUrl. We want to avoid reconstructing a client on each request to the worker.

[blaine-arcjet]

Related: Connect doesn't work well on Cloudflare, see connectrpc/connect-es#577

[blaine-arcjet]

Someone suggested dynamic baseUrl in connectrpc/connect-es#678 but it was closed as wontfix.

[davidmytton]

I spent a bit of time researching where we're at with support for Cloudflare workers.

This is blocked by Connect RPC's requirement to construct a client with a baseUrl. We want to avoid reconstructing a client on each request to the worker.

Seems there's a few reasons for this:

1. We want to load our WASM module into the worker outside of the request context so it can be instantiated once rather than on every request. This is why we recommend creating the Arcjet client outside of the request handler for our other adapters.
2. With feat: Attempt to warm http2 connection upon SDK startup #1201 we'd like to have a persistent connection to improve latency across requests.
3. The DX is better when you can define base rules in a client and then withRule any additional rules you might want to combine.

With Cloudflare's move from Service Workers to ES Modules, environment variables are no longer provided in the global scope. Instead, they're passed as a binding to the handler. Trying to access them as a global will error.

Also, creating the connect client requires a base URL, which we configure dynamically based on the environment variables.

Loading WASM

Cloudflare officially supports WASM in workers. They have some history with slow worker startup, but it seems they've implemented a fix for this. From 2020:

We found a way to enable V8’s Liftoff+Tier-up that we like. This should go out to production next week. I think it should cut Wasm startup time by a factor of 5-10. (This still doesn’t use code cache, which is a much bigger project that should cut Wasm startup time to almost nothing. No timeline on that yet, but let’s see how much Liftoff helps.)

It would be interesting to test the startup time of our WASM Module. They must be instantiated in the global scope outside of the handler, which implies some optimization may be going on.

There is also a worker size limit of 1MB for free plans, 10MB for paid plans.

Persistent connections

Cloudflare doesn't support persistent outbound connections so we don't get any benefit here.

You can see in the examples for databases, they create a new connection within the workers handler, then it closes after the request ends.

Given this, we could avoid our usage of the dynamic baseUrl and use a static URL when in the workers environment.

I assume we'd use the fetch client from Connect: connectrpc/connect-es#577 (comment)

Did I miss anything or get anything wrong?