No description
This repository has been archived on 2024-07-19. You can view files and clone it, but cannot push or open issues or pull requests.
Find a file
2022-10-09 13:54:45 -04:00
.github/workflows chore(deps): update actions/checkout action to v3 (#13) 2022-09-25 16:23:56 -04:00
infrastructure infra: add tagging to resources (#17) 2022-10-09 12:42:18 -04:00
script build: unified deployment script (#18) 2022-10-09 13:54:45 -04:00
src Initial version (#1) 2020-09-26 01:14:56 -04:00
.config refactor: pure bash instead of python scripts (#9) 2022-09-23 01:11:41 -04:00
.gitignore refactor: pure bash instead of python scripts (#9) 2022-09-23 01:11:41 -04:00
docker-compose.yml Initial version (#1) 2020-09-26 01:14:56 -04:00
Dockerfile Initial version (#1) 2020-09-26 01:14:56 -04:00
LICENSE Initial commit 2020-08-23 01:43:53 -04:00
README.md build: unified deployment script (#18) 2022-10-09 13:54:45 -04:00
renovate.json chore(deps): add renovate.json (#8) 2022-09-23 01:12:23 -04:00

lambda-boilerplate

🛠 Skip the boilerplate and start building fun λ things 🛠

Lambda Boilerplate

Overview

AWS Lambdas are fun, but often the amount of boilerplate involved in getting a project off the ground hinders the fun. From setting up a local environment to writing out infrastructure templates, the overhead of Lambda-based greenfield projects can be daunting. No more. Just use this repository as a template or clone it and jump straight into the action! This repository offers a quick template your can use, full with a Docker setup for local development and invocation commands that you can use to package and deploy Lambda-based apps.

Local development

The base Lambda handler is at src/base.py and all the Terraform configuration files are in infrastructure.

Read more about Terraform

Read more about AWS Lambda

Tooling

All the tooling is implemented using the One Script to Rule Them All paradigm and can be found under script.

Deployment

Provided your runtime source code is prepackages and ready to go, you can simply ARCHIVE=<path-to-function-zip> . script/deploy to deploy your function in seconds!

By default, the resources are identified with an environment name dev-$USER, but you can change this in staging / production deployments by specifying the ENV_NAME environment variable.

Individual parts of the application (i.e. the bootstrap resources or the application itself) can be deployed separately using PROJECT=<bootstrap|app> script/apply.

Prepackaging the source code depends on what language is used as a runtime, more details can be found in AWS Lambda documentation.

Contributing

Got suggestions or improvements you'd like to make? Open a PR or an issue!

Feature requests should keep in mind that the goal of this boilerplate is to be general enough so that the cost of tailoring it to specific use cases is low.