Implementation details:

• Deployment to Lambda is done via Terraform.
  • The GraphQL definition is bundled with the image at deploy-time.
• There's no built-in KV store for AWS like there is in Cloudflare, so I built a simple Cache provider based on HashMap.
• The current implementation of LambdaFileIO reads from the filesystem, instead of, say, an S3 bucket, since it's needed to retrieve the GraphQL definition from the image bundle.

Questions:

Should the Terraform deployment code live in this repo?

The DX of a Lambda deployment is pretty bad right now. A dev has to:

1. Install Rust, Terraform, Python and cargo-lambda
2. Add AWS credentials to environment variables
3. Clone this repo
4. Build the lambda crate with cargo-lambda
5. Write a GraphQL definition into lambda/deploy/config.graphql
6. Run terraform init && terraform apply

We could move this to an external repo, and I can make the CI build Lambda images and put it in Releases, and the Terraform config can be adapted to download it. With that, the DX would be the following:

1. Install Terraform
2. Add AWS credentials to environment variables
3. Clone that repo
4. Write a GraphQL definition into lambda/deploy/config.graphql
5. Run terraform init && terraform apply

This is, in my opinion, much better. It also lets devs fork the repo and manage their own deployment schema on GitHub.

Adapted to the new TargetRuntime.

...wtf are these codecov errors

...wtf are these codecov errors

yeah, strange, but don't bother about it, it won't affect pr merge