|
|
|
|
|
by don-code
1507 days ago
|
|
I recently had an opportunity to build an application on top of Lambda@Edge (AWS's equivalent of Cloudflare workers). The prevailing wisdom there was to make use of regional services, like S3 and DynamoDB, from the edge. That, of course, makes my edge application depend on calls to a larger, further away point of presence. While it's possible to distribute state to many AWS regions and select the closest one, I ended up going a different route: packaging state alongside the application. Most of the application's state was read-only, so I ended up packaging the application state up as JSON alongside the deployment bundle. At startup, it'd then statically read the JSON into memory - this performance penalty only happens at startup, and as long as the Lambda functions are being called often (in our case they are), requests are as fast as a memory read. When the state does need to get updated, I just redeploy the application with the new state. That strategy obviously won't work if you need "fast" turnaround on your state being in sync at all points of presence, or if users can update that state as part of your application's workflow. |
|