Feature set comparison to Fastly


Apologies if this type of question is not appropriate (e.g. it’s too broad/not specific enough, or is expecting too much from people to reply to).

I’m not currently a Cloudflare user and so I wanted to get an idea (at a glance) what features were available in Cloudflare’s Worker platform/service when compared to another CDN provider that I currently use who offer a programmatic edge, i.e. Fastly.

I’m currently utilizing the following features (see below list) and couldn’t really tell (without going through a whole load of API documentation) whether these features are available with Cloudflare Workers or not.

Hopefully the community here can help me ascertain what’s supported and what is not.

Many thanks for your time and patience.

  • Purge authentication: Prevents unauthenticated users from purging our cache.

  • Block lists: Reject requests recognized as bad/invalid.

  • Geolocation: Identifying the locality of the user using the edge node their request was handled by.

  • Redirects: Redirecting and modification of incoming requests (e.g. HTTP to HTTPS).

  • Request Modifications: Modifying aspects of a request (e.g. headers, method, url host & path, query string etc).

  • State Modifications: Ability to modify a request depending on the state of the cache (e.g. MISS vs HIT).

  • Stage Authentication: Preventing access to our stage environment (e.g. Basic Auth, or in future calling out to an authentication backend service before allowing the request to flow through to a staging environment).

  • Dynamic Backends: Able to switch backend at runtime depending on request specific contextual data.

  • Custom Error Pages: Ability to serve fully custom error pages at the edge.

  • Customizable Cache Keys: In some of our Fastly services we utilize request specific data as part of the cache key generation (it’s a rare occurrence, but it has been utilized).

  • Dynamic Cache Purging: Support for HTTP ‘Edge Arch’ header (https://www.w3.org/TR/edge-arch/) (e.g. Surrogate-Key, Surrogate-Control).

  • Serving Stale Content: Support for HTTP cache extension (e.g. stale-while-revalidate, stale-if-error).

  • Edge Dictionaries: Key-Value store that can be updated via API calls, and enables dynamic logic flows.

Update: I’ve taken a look through the documentation as thoroughly as I can given my time restraints on investigating alternative providers and it would seem that CloudFlare workers will support the various scenarios we have. That said I’d still be interested in feedback from the community, especially if there are requirements I’ve defined which aren’t as straight forward to work with in Cloudflare.

1 Like

Hi Mark,

I’ll reply to each individually, but to preface the whole thing: Workers are a JS/V8 environment, so basically everything you can do with JS, within the APIs given is possible.

This is the ones I understand less, in which sense you authenticate the purge? Purges on Cloudflare can be done only via the Dashboard or the API (you can obviously call it via Workers), but without your Cloudflare auth nothing can be done. There are API Tokens which can be scoped, but still via the API.

This is included as Firewall and Firewall rules. It doesn’t need Workers, it can run independently on all requests.

The POP and country are in all requests, header and in an object within the Worker. Business plan and above do go at the city level within the Worker (not sure as far as headers to origin).

This is the best use case of Workers, HTTPS redirection doesn’t need Workers though. There are also Page Rules which can do a subset.

Same as above, modify at will. Host won’t be changeable, unless in your own Cloudflare account or verified by the Cloudflare team for Enterprise plans.

Not completely sure on this one, but I believe you can see the header and info on the fetch from the Worker, showing this info as well.

I would look into Cloudflare Access, but works just fine with the JS backend of Workers.

Obviously doable, there is probably a way to do some of the same with Load Balancing.

Return what you wish, there are some custom pages already in the dashboard, but you can return whatever, it’s an Express kind of interface.

This is doable, I believe it requires Enterprise though.

Not sure, never heard of that header. Would be doable manually in Workers for sure, automatically it would be best to contact sales (maybe @cscharff or @cloonan know).

This is supported by default, standard cache behavior.

There is the Worker KV Store, accessible directly by the Worker or by API. The data is immediately available from the same POP upon change or everywhere upon create and eventually consistent (within 10s, usually 1s) for all or other POP.

1 Like

Amazing! thank you Matt for this detailed break-down. :+1:t2:

re: “State Modifications” – I think it’ll take me a bit of playing around to fully understand Cloudflares implementation. I’m used to using Varnish and having distinct ‘states’ of a request flow where as it feels like the JS implementation is more free-form (in the sense of it’s just code that you define and execute). So understanding when and where cache information gets exposed is likely a documentation thing I’ll discover eventually.

re: “Purge authentication” – with Fastly you can purge an individual URL using a PURGE method request to that endpoint unless you enable “requires API authentication” first. This was something we missed for a long time and realized it wasn’t enabled by default and so anyone could have in effect built a site scraper and then iteratively purged an entire cache o_O so I just wanted to be sure purging unauthenticated was strictly a no-no :slight_smile:

1 Like

I believe the best way to check for the various features is this: https://developers.cloudflare.com/workers/reference/

I believe on Cloudflare doing a different thing depending on cache status isn’t a good idea, simply because there are a ton of POPs, the purges can happen, so ideally treating all them identically is best. The best thing is setting good Cache-Control headers.

Wow. Didn’t know this. Really absurd, if you ask me… By default it’s API only here, you could wrap it in a Worker and make it public, but it’s not recommended.

PS: Cache Keys are Enterprise only.

1 Like

This topic was automatically closed after 31 days. New replies are no longer allowed.