Building an API with AWS SAM and Go

AWS SAM is a great way to deploy web applications via Infrastructure as Code (IAC). I recently tried to use it in my work project and ran into a stark reality...

Go is the ugly duckling of AWS?

The section of the AWS SAM documentation dedicated to Go is very short and vague, recommending repeating our source code extensively ! Every lambda function has a go.mod, go.sum, and utility functions?!

I write this article for you who are as confused as me?‍?. Let's solve this problem together!

This will be a two-part series:

1. File structure (this article)
2. SAM Configuration

Go runtime context

Currently, lambda is not supported in the Go runtime. This means that AWS lambda has no specific option to specify that your code is written in Go. Instead, AWS offers 2 common runtimes?:

• al2 (Amazon Linux 2)
• al2023 (Amazon Linux 2023)

This refers to the operating system the lambda will run on. It is recommended to use al2023 as it is newer and compatible with AWS Graviton processors which offer better performance at a lower price.

Anyway, these runtimes require us to provide an executable file (usually named bootstrap) that will be executed within each lambda function. So, instead of delivering code to a lambda, we deliver an executable that we previously compiled with Go. Pretty simple, right?

This also eliminates the need for a lambda layer for languages ​​like JS, as all common dependencies will be packaged in the compiled executable.

Question

So, how do we build this executable? AWS recommends that each of our lambdas should be stored in a folder, along with its go.mod and go.sum, and the template they provide looks like this:

<code>.
├── hello-world/
│   ├── go.mod
│   ├── go.sum
│   └── main.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>

This is the function definition in template.yaml

<code>  HelloWorldFunction:
    Type: AWS::Serverless::Function 
    Metadata:
      BuildMethod: go1.x
    Properties:
      CodeUri: hello-world/
      Handler: bootstrap
      Runtime: provided.al2023
      Architectures:
        - x86_64
      Events:
        CatchAll:
          Type: Api
          Properties:
            Path: /hello
            Method: GET</code>

If we look at the Lambda definition, we learn:

1. BuildMethod: go1.x We use AWS’s built-in Go builder to build the executable for us
2. CodeUri: hello-world/ lambda code will be stored exclusively in this directory.
3. Handler: bootstrap The name of the executable will be bootstrap
4. Runtime: provided.al2023 This will be the runtime.

Do you see the problem? Currently we need a second lambda, we have to create a new directory with its own go.mod, go.sum and dependencies, what if we want to share a utility function between the two lambdas ? Too bad?! You have to copy the same files into the new lambda folder. This leaves a file structure that looks like this:

This is so bad?!

<code>.
├── function1/
│   ├── go.mod
│   ├── go.sum
│   ├── main.go
│   └── SHAREDFUNC.go
├── function2/
│   ├── go.mod
│   ├── go.sum
│   ├── main.go
│   └── SHAREDFUNC.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>

There is a lot of duplicate code!

And it gets worse the more lambdas we add. There must be a better way!

Solution

Since I want to share go.mod, go.sum and utility code through all lambdas, I came up with this structure:

<code>.
├── hello-world/
│   ├── go.mod
│   ├── go.sum
│   └── main.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>

1. I broke all the public code into the internal/ folder,
2. Place go.mod and go.sum files in the root directory
3. Move all lambda entry points to /cmd (there is a convention in Go that whenever a project produces multiple executables, the entry points are placed in the cmd directory)

Now I just need to notify AWS SAM of this new structure?! I found the solution just by adjusting the values ​​of CodeUri and Handler.

Secret?

It seems that if you

• Move go.mod and go.sum to the root folder
• Set CodeUri to whatever folder the function entry point is.

SAM will automatically detect it and build with root dependencies and internal/code? ? ?

<code>  HelloWorldFunction:
    Type: AWS::Serverless::Function 
    Metadata:
      BuildMethod: go1.x
    Properties:
      CodeUri: hello-world/
      Handler: bootstrap
      Runtime: provided.al2023
      Architectures:
        - x86_64
      Events:
        CatchAll:
          Type: Api
          Properties:
            Path: /hello
            Method: GET</code>

Can it be better?

Yes✨, we will discuss more ways to customize Go compilation in the next article!

The above is the detailed content of Building an API with AWS SAM and Go. For more information, please follow other related articles on the PHP Chinese website!