Open vwkd opened 2 years ago
I'm using the broadcast API in my project to coordinate isolates dispatching server side events to the client. Being able to target a region by using a dedicated url would make testing easier.
Kudos to the Deno & Deno Deploy teams for putting out excellent features at such a breakneck speed! Looking forward to this feature being added.
In the meantime, I was interested in testing my deployed code around the world to observe latency. I ended up going with GeoPeeker which can quickly load websites across multiple locations around the world and serve up screenshots. Eg the following shows Supabase latency from Deno Deploy from various regions:
Another option is to use WebPageTest
We also really need this :)
I'm having the issue where my Deno project needs to consume a REST API that's restricted for certain regions. What would help in this scenario is if Deno Deploy would allow us to specify which regions incoming requests get routed to per project. Or perhaps even better: specifying which regions outgoing requests get routed through as that's really the underlying issue!
Currently, a request to a Worker (pending name #105) is automatically routed to the instance in the best region which is usually the closest. It might be useful to be able to specify an instance in a specific region in the request ^cdnplanet. Note, this is different from deploying the Worker only to specific regions in the first place, see #93.
One option could be to use the URL. To not interfere with the API of the Worker which can access the path, a subdomain could be used, e.g.
<region>.<project>.deno.dev
. If no<region>
subdomain is given it uses the default routing like right now.But if in the future more settings are added this would prove cumbersome since in a URL the order of subdomains is fixed and for any subdomain all previous subdomains have to be set, e.g.
<setting3>.<setting2>.<setting1>
. Likely there aren't many more settings for Workers, but there is already one for Coordinators (#88) which uses a subdomain for a duplicate Coordinator.A better option could be to use a custom HTTP header, e.g.
X-Deno-Deploy: region=<region>
. The header would be filtered out at the Deno Deploy edge and not be visible to the Worker that receives the request. The advantage of key-value pairs in a header is that the order is not fixed and any one can be left out. The advantage is similar to using a single object as function argument instead of named arguments.