We just released a preview Postgres + regional replicas. This setup keeps the postgres leader in one region and lets people add replicas in other regions they're interested in. It works really well for typical full stack apps.
We've also found a surprising number of customers who want to run in only one specific region. They don't spread apps out geographically, they just have a concentrated population of users in, say, Sydney. We're increasingly becoming "Heroku for <region>".
For a read-dominated access pattern that sounds quite interesting.
https://fly.io/docs/app-guides/graphql-edge-caching-apollo/
I'm not entirely convinced this is a great idea (and apparently the example uses plain http between the graphql prox/cache and openlibrary.org - that might be considered a bug, I suppose: https://github.com/fly-apps/edge-apollo-cache/blob/master/sr... At any rate I'd assume whatever source you're proxying (eg your own openapi rest end points) - you might want ssl - or connect the db/api to fly.io via vpn a la: https://fly.io/blog/building-clusters-with-serf/ See also the linked: https://fly.io/blog/incoming-6pn-private-networks/ ).
But: while you can very easily use TLS to backhaul to an API, a more "modern" Fly.io way to solve this problem is with WireGuard gateways; it's trivial --- I'd argue, easier than configuring SSH certs --- to get a WireGuard link from your cache app on Fly back to AWS, GCP, or wherever your non-Fly legacy database lives.
I really think WireGuard is going to change a lot of the ways we design systems like this.
One of the most interesting things about wireguard to me is cheap ubiquitous application neutral secure comms.
Then there are a lot of requests you can serve from read replicas or caches that can be close.
We almost shipped cockroach but it's missing some Postgres features that most full stack frameworks rely on.
If your queries have data dependencies, you'd get better results with a front end near your users, and a middle tier api near your database.
But, just TCP (or TLS) termination near your users and the real frontend near your database can make a surprising amount of difference.
On the other hand. There's a lot you can do to make sure things are fast from limited locations. Keep an eye on data size, make sure you're monitoring for and fixing slow queries, optimize your images, etc. If your html takes seconds to serve, it barely matters where you served it from.