That's great when your data to render actually exists at the edge. Most the apps I have dealt with need to pull data from a centrally located database for almost every request. This edge setup would actually increase user latency whenever there are multiple DB queries per request (this is true of all requests if you have to query a DB to validate the user or their permission, although that can be avoided with a signed token approach).
There's some potential advantage in using the cloud provider network after the edge, but it's already a known pattern to stick just a network proxy at the edge to gain the advantage of sending the rest of the request over the cloud provider network rather than sending it over the internet.
Cloudflare has a query cache tool so that you can set a TTL on database read queries and keep them at the edge to avoid the DB latency [1]. I think though that you could develop a way to do that at an edge network proxy working at the request/response level rather than the DB level. But perhaps SSR is superior for apps that can show users stale data.
There's some potential advantage in using the cloud provider network after the edge, but it's already a known pattern to stick just a network proxy at the edge to gain the advantage of sending the rest of the request over the cloud provider network rather than sending it over the internet.
Cloudflare has a query cache tool so that you can set a TTL on database read queries and keep them at the edge to avoid the DB latency [1]. I think though that you could develop a way to do that at an edge network proxy working at the request/response level rather than the DB level. But perhaps SSR is superior for apps that can show users stale data.
[1] https://developers.cloudflare.com/hyperdrive/learning/how-hy...