We are deploying a new site running on NextJS with heavy use of SSR.
The reason we are using SSR is primarily to provide excellent performance to clients (we use an additional caching layer on top).
The SSR function needs to query data from a DynamoDB endpoint. But if the DynamoDB endpoint is halfway across the world, this could add maybe 1s of latency.
We would like to use DynamodDB Global Tables - i.e. have the same data available in multiple regions, so that each Netlify node running the SSR would be able to use an endpoint close to it. The quesion - how can we know inside the SSR function where we are running, and therefore which DynamoDB endpoint to use?
This doesn’t seem to be documented anywhere, so looking for any creative ideas!
BTW the value of the AWS_REGION environment variable, as seen by the SSR function, is always us-east-1, even though dnschecker.com tells us the the site is being served from multiple data centers worldwide. So we are not sure what’s happening here…
Your functions will always run in us-east-1 (by default - you can also choose some other single location that we support which is many but not all lambda-capable AWS data centers; only selectable for Pro and above customers and requiring configuration by our staff to enable). So - if you are using SSR, your code is likely running in functions, and the functions will always run in that single location (we do not support multi-region lambdas at present). So, probably it would make sense to move your function to the same region as your database, or supply your database in us-east-1, somehow, so it is more easily connected to by your Netlify functions.
Should you still desire geo-centric behavior, you can probably use the geo redirects in next to do different operations in different locations, though:
…are probably your best reading for deciding how to do that - most likely using next.js redirects, with the hack to add geo data into the environment (from my first link), since Netlify’s redirects will run outside of your function and do not allow you to incorporate any real logic such as selecting different database endpoints (you’d have to use our geo redirects, to first redirect to a separate webpage per region, which pages are all hardcoded with endpoints or different behavior, based on that pre-specified location. Doesn’t sound optimal to me, but now you can decide what make sense for your business!)
Thanks @fool for the detailed answer. Will analyze it.
So just to be sure we understand how this works:
When we see DNS Checker reporting that our site on Netlify is being served from multiple regions across the world - is that just some kind of caching layer similar to Amazon CloudFront? But each and every request that uses SSR still gets forwarded to a single region?
As a workaround, we might actually deploy more than one site using the same codebase - each site being deployed to a different region. Each site would be configured to use a different data store.
The downside is this will double the number of build minutes, as well as the required build concurrency limit - so we will probably end up deploying to fewer locations than we were hoping.
It would be nice if there were a Netlify feature for doing this type of multi-region deployment without having to create multiple sites. It’s probably relevant for other types of functions, not just SSR.