Last mile DynamoDB: Deno Deploy edition

In my last post, I introduced a small Rust library named aws-region-nearby that helps reduce latency by finding the AWS region closest to a user’s location. As a real-world example of this type of geolocation routing, I mentioned Cloudflare Workers accessing data in a DynamoDB global table from the edge.

Of course, Cloudflare Workers aren’t the only – or even best – way to run code as close as possible to the end user. Another excellent option is Deno Deploy, the isolate cloud from the creators of the open-source Deno runtime for JavaScript and TypeScript. Deno is among the most exciting projects I’m following at the moment, so it’s no surprise that I added support for Deno Deploy to the latest version of aws-region-nearby. 🚀

Implementation was mostly straightforward, with the main difference being that Workers directly provide latitude and longitude as part of HTTP requests, while Deploy sets the DENO_REGION environment variable to the region where the deployment is running. However, with this handy list of available Deno regions and some educated guesses about edge/city locations, it’s just as simple to calculate the shortest distance to Amazon’s data centers for Deploy as it is for Workers.

Show me the code

Let’s get practical. This is what the API looks like (check out the entire Rust code here):

use aws_region_nearby::{AwsRegion, DenoRegion};

let replica_regions: Vec<AwsRegion> = env_var("REPLICA_REGIONS")
    .unwrap()
    .split(',')
    .map(|r| r.parse().unwrap())
    .collect();
let deno_region: DenoRegion = env_var("DENO_REGION").unwrap().parse().unwrap();
let aws_region = deno_region.find_region_from_list(&replica_regions);

Given this input:

REPLICA_REGIONS=eu-central-1,us-east-1,ap-northeast-1
DENO_REGION=europe-west4  # Netherlands

The library would pick eu-central-1 (Frankfurt) as the clear winner, which you could then pass as the target region to your DynamoDB client of choice – or any regional service client, for that matter.

DynamoDB edge playground

Speaking of DynamoDB, I also spent some time brushing up the examples that come with aws-region-nearby:

  • I introduced a CDK stack that deploys a replicated DynamoDB table for testing.
  • I added a Deno example and extended the one for Workers so that both write and read items to and from DynamoDB.
  • For the latter to work, I first had to add async support to Tiny Dynamo – a neat little Rust crate that, unlike other full-blown AWS SDKs, compiles to WebAssembly out of the box.

Edge runtimes are the future, but persisting data at the edge can be tricky. Tutorials like this make it look easy, but the fact is that the AWS SDK for JavaScript doesn’t support Deno yet, unfortunately.1

I hope my recent additions to aws-region-nearby remove some of the friction involved in the process.

What’s next

A nice side effect of making the examples functionally identical is that it allows us to compare cloud providers, which will be the topic of my next post. Get ready for a surprise or two!

Update (March 2023): The surprise was that I never published that post. Deno Deploy destroyed Cloudflare Workers in all of my micro-benchmarks. But benchmarking is hard and things evolve. While I might revisit the topic, please draw your own conclusions.

  1. After publishing this post, someone from Deno pointed me to aws-api.deno.dev, which turned out to include the only DynamoDB client for Deno that worked for me right off the bat, at least for simple scripting. ↩