#Is it a good idea to use worker as a proxy to serve s3 static files?

4 messages · Page 1 of 1 (latest)

west merlin
#

The context is I have a CNAME record, foo.com to map to bar.com. And we would like to separate the static files hosting from bar.com to s3.
By using page rules, we cache everything for foo.com for 5 minutes.

I was suggested that worker can play the role to match the subpath to serve static files. like for any url pattern foo.com/static/*, use worker to fetch assets from s3, and cache it using cache api. But as we experiment, the number of requests for this worker is huge. I'm guessing it's because worker code has to run every time a user downloads static file, no matter it is cached or not, because it needs to go through worker to interact with cache. The cache protected s3 not to be fetched frequently, but cannot stop worker from running every time a user requests a static file.

Is using worker to serve static files a good idea? or I should look into other approaches?

subtle vessel
#

Workers aren't that expensive, so if it fits in your budget thats probably not a bad idea. Also, have you checked out R2? Its Cloudflare's S3 competitor and it charges no egress fees

#

You might be able to use the savings from using R2 to pay for workers 😛

atomic oar
#

I do so only for assets I need as 1st party, such as "well-known" URIs (https://en.wikipedia.org/wiki/Well-known_URI) or service worker scripts.
I works well and I would debate for using it altogether to reduce DNS lookups in traffic. But separating the two types of traffic allows me to manage them in different zones, and in different tiers - which becomes cost effective at scale.

A well-known URI is a Uniform Resource Identifier for URL path prefixes that start with /.well-known/. They are implemented in webservers so that requests to the servers for well-known services or information are available at URLs consistent well-known locations across servers.