one thing i had in mind was sending ppl to "local" servers; i.e. near their closest cf-POP. i hope this will be possible with snippets 😄

Is your API HTTP already?

yea

you can already do multiple fetches in parallel and just race to the first one that completes.

hmm... doesn't seem like an elegant solution.

sure it is 😛

if i have lets say 5 servers then i get 5x the traffic with this method

One thing to note is that snippets can only make 1 subrequest, as Kian said

yea, basically just "forwarding" the request somewhere, right?

Correct

Sure, but you can cache the result too if it's problem.

You could use

request.cf.country

or

request.cf.colo

to try and work out where the nearest server is - and fetch that, but if one is offline, there's not much you can do

depends on what one wants to accomplish.

It's really nice since you can do "advanced" ish load balancing too if want. e.g. can see the round-trip latency by doing:

curl -s "https://untrusted.files.ai.moda/api/v1.0.0-alpha/ping" | jq

if i, lets say want to build some kind of "low-latency" storage for small files, that is kinda guaranteed to have sub <50-60 ms latency, i could make that with less (or no) js on the user side, while still being able to serve the data quickly.

what do you mean with that?

https://untrusted.files.ai.moda/api/v1.0.0-alpha/url/generate_one_time

^ we have a similar ish use-case, and made this to return the endpoint with the estimated lowest latency for the user.

ahhh 🙂

basically just a request to where the client should then upload to. so same thing accomplished, just not intransparent to the user

sure it can be

uh, nearest datacenter hit is london?

that sounds right, since that uses an S3 backend with buckets in Frankfurt, Ireland, London, Montreal, San Jose, and Virginia.

well, then from austria it should have hit frankfurt 😛 😉

if it's <100MB, you can just accept the request data body directly in the Worker and POST it to an endpoint elsewhere without needing to make the client wait.

ah so this crappy S3 provider has terrible uptime, and their Frankfurt server has crazy reliability issues (hours of downtime per month). That's why this Worker is really nice, because it actually checks if the S3 endpoint is working or not.

(off-topic but are only using this unreliable S3 provider temporarily mainly because of the lack of per-bucket API tokens for R2.)

ahhh 🙂 thanks for the insight, always interresting to hear what others are building.

Will your users be using a browser, or is this going to be used by another backend?

mainly browser.

we do a lot of preloading on our website. e.g. we have this at the bottom of our head tags:

html
<link fetchpriority="low" rel="preload" href="/geolocation.json" as="fetch" crossorigin="anonymous" />

That way when we fetch

/geolocation.json

later, it's already loaded.