SNS/S3/API AWS Lambda opinionated boilerplate cookicutter

The goal of this article is to share and explain, a very basic and straightforward, AWS Lambda template for GoLang, based on cookiecutter templating capabilities.

Table of content:

1. What it is
2. How to use
3. What it is Not
4. Worth mentioning

What this template is

This is a so-called "tightly coupled" template, it was build with the purpose of mainly satisfying these goals:

1. Template that can be executed/tested locally, withoud deploying the Lambda to the Cloud, by running Docker image with AWS SAM framework
2. Abitlity to chose an example event, which can be: SNS, S3 or API Gateway
3. Template that generates all scaffolding files: LICENSE, AUTHORS, Makefile, SAM template, pre-commit, VERSION, gitlab CI example jobs, envs.json
4. An opionated template that ideally is meant to be testable locally in Docker encapsulated environment to provice the developer an ability to provide a test event ( ./events/event.json ), an used it to develop Lambda fast by executing it locally numerous times
5. Minimalistic code example (aka "Hello Works"), with backpack full of batteries included, and minimise the need for an additional configuration as much as possible

How to use

Here is the repo: https://github.com/zahaar/go-lambda-cookiecutter

README.md contains all core instructions and prerequisites needed to use this cookicutter

...
...
First, get Cookiecutter. Trust me, it's awesome::

    $ pip install "cookiecutter>=1.7.0"

Now run it against this repo::
...
...

What this template is Not

1. No deployment to AWS, leave it to Terraform, Claud Formation or other IaaC tool of your preference
2. Not a complex example. A complex example would complicate things, and negatively influence initial understanding of the structure. Therefore SNS, S3 and API example, contain a simple print-out as an output.
3. It's hard to simulate complex scenarios locally with AWS. P.e: the complexity of AWS SAM template will scale tremendously if we would include a complex chain of Lambdas that invoke one another. KISS.

Worth mentioning

1. Don't treat go serverless programm any different from other programs that you write > CC: Go Time Podcast, Serverless and Go
2. Take great care about business logic, and it's application. How it will shape Lambda code.
3. Serverless code should be small, minimalistic. Something in a sense of 50 lines microservice
4. Striving for Cloud Agnostic serverless code ( e.g something that will work on GPC, Azure and AWS simultaneously ) , Doesn't make sense. That why we aim only for AWS Lambda > CC: Go Time Podcast, Serverless and Go
5. Why use GoLang for AWS Lambda: link
6. Collection of cookiecutter from AWS SAM: link
7. Testing, unit testing, integration testing with AWS SAM is at this moment the best things that industry can offer. IMHO/
8. In case of failing to pull/build Docker image, refer to this thread