Using the fly-region header we know where the request originated, so let’s say I had a central service that needs to dispatch calls to app instances running in the region where the request originated or the next closest region where an instance is actually running. Apart from maintaining a list of regions and their neighbors in my application what would be the best way to do that?
Thanks!
Matt
You can use internal DNS to find other instances. Here are some examples:
Get the two nearest VMs:
> fly dig aaaa top2.nearest.of.flyio-web-proxy.internal -s
fdaa:0:33:a7b:ab2:4be9:83c8:2
Get a list of all regions an app is running in:
fly dig txt regions.flyio-web-proxy.internal -s
ewr,iad
Get a list of all instances in a specific region:
fly dig aaaa iad.flyio-web-proxy.internal -s
fdaa:0:33:a7b:775b:3ad1:934d:2
fdaa:0:33:a7b:775a:aadd:9944:2
List all IPs (useful for hitting everything):
> fly dig aaaa flyio-web-proxy.internal -s
fdaa:0:33:a7b:ab2:4be9:83c8:2
fdaa:0:33:a7b:775a:aadd:9944:2
fdaa:0:33:a7b:775b:3ad1:934d:2
Does that do what you want? I think I understand your question, but I can try again if these aren’t helpful.
Hey @kurt thanks for the quick reply! Reading over the docs I’ve seen the capabilities that you mention for sure. My question is more about being able to direct an internal call to a given region or the next nearest one - example - the call came in via the region iad but I’m not running an app instance there, only in ewr. I’d like to be able to route a request internally to iad or the next closest region at some point in the future, i.e. ewr seeing as NJ is closest to VA.
As I write this I realize I might be misunderstanding something fundamental here - I’m asking this a) only having read the docs and not actually tried anything and b) under the assumption that the fly-region header indicates where the request entered the network, which could be in a different region from where your app is actually running, so for my example it entered in iad but got routed to ewr. That could be totally wrong and if so, please disregard! 
Hi @mattburton
If I understand correctly, you have an external request coming in for app1 to iad, but since you don’t have a node there it gets forwarded to the ewr region. Then, your app1 in ewr wants to make an internal request to app2 which may have a node in ewr but if it doesn’t then you want to use the next nearest region.
I believe what you’re trying to do can be achieved using top1.nearest.of.app2.internal when making the internal request to app2.
Does this sound like what you’re after? If not, can you provide an example flow of what you’re after.
Hi @charsleysa - can you confirm that what you said happens? The request enters at iad but if I don’t have my app running there it would get forwarded to the closest region such as ewr? Would the fly-region header have iad as the value in that case?
Yes that’s correct.
A request coming into iad would have the fly-region set to iad. If there are no nodes in iad then the request is forwarded to the closest available region and the fly-region header stays as iad.
Also note that these headers are only set if the request is coming through the fly proxy. If the request is internal and not going through the fly proxy then the header is not available. Requests from one fly app to another fly app using .internal addresses do not go through the fly proxy.
Nice. Unfortunately I just realized that my thinking here is invalid. The use case I was thinking of was webhooks, and making sure that they are sent from an app instance closest to the region where the request to receive the webhook came from in order to reduce delivery latency. But, just because the request to subscribe to a webhook came in at iad doesn’t necessarily mean that the URL where they want the webhook sent is in the same geographical region. Oh well, sorry for taking up everyone’s time here but thanks for the fast and thorough responses! Really impressed with fly thus far!
This is actually a helpful discussion, so no need to apologize. We’re in the very early days of multi region apps and there’s a lot to figure out (for us AND devs).