Go + Serverless Offline, Wait Go! YES, It is really simplified

Back in 2018, when AWS announced the Go support for lambda, everyone was excited about this big announcement, later the support came partially to different frameworks. However with diversity of frameworks we have today like Serverless, AWS SAM, Apex, or even tools such as Terraform and CloudFormation, it becomes really hard to remember all of these commands and also difficult to switch and migrate to different framework.

I have been looking for a solution in the market that wraps all of these frameworks in one simple, yet powerful solution that unifies all the commands to invoke lambda functions or to deploy to AWS without the hassle of remembering specific framework-related commands. Unfortunately, every time I switch to use or try a different framework I’m stuck reading tons of documentation in their websites and use different plugins to achieve what I am looking for. It was literally a waste of time.

So, I came up with an idea to wrap all of these frameworks in one simple solution that generates templates based on the selection of the framework you are willing to work with. Not only that, but it allows you to switch from one framework to another, for example if you selected Serverless (SLS) you can switch to AWS SAM.

Prerequisites

• Install NodeJS
• Install Go
• Install Make [Mac, Windows, Ubuntu]
• Install Yeoman, aka yo, run the following

$ npm install -g yo

Let’s Go

To Create a new service, run the following command. This should ask you questions, like language, unit test framework, routes and their types.

$ yo sls

As shown in the screenshot below you can choose between SAM and Serverless to manage deployments. I am planning to add more options like Apex, Terraform and CloudFormation.

Once you hit enter, this will generate bunch of scripts that will simplify a lot of heavy lifting jobs like local invoking, network management, debugging ..etc.

Now, specify the routes that you need to add to the service, and the type of the method you want to use to trigger the underlying lambda to be generated.

Finally, specify the framework to be used in unit testing

As shown in the screenshot below, this is what we built. As you can see every route has its own directory, under which there will be a lambda function handler, simple test cases, Makefile and event.json that is compliant with the type of the route you’ve chosen earlier. For example, if you specified “get” as a route type, this will generate an event of type GET from APIGateway. Additionally, the generated project supports GO111MODULES and is bundled with go.mod and build scripts as well.

One last thing to note, the Makefile under the route folder corresponds to that specific route, and the Makefile present in the root directory is for the whole project.

Testing out

To start testing out what we just created, lets start building the whole project by simply running

$ make

The generated template comes with simple route func and their test cases as well, to run the tests

$ make test

If I want to build the project and invoke a specific function, you need to run the following, to invoke the lambda function defined under “route1” directory with attaching event.json defined under the same directory.

$ make local-invoke func=route1

If you need to try a different event.json file, you can pass it by using the following example:

$ make local-invoke func=route1 event=/path/to/event.json

If you want to run as a local API, use the following command to start local API on port 3000

$ make local-api

Debugging

When I started Serverless with Go about a year ago, I found many difficulties in debugging it locally, I had to configure ports and install dlv for linux and then port or mount it inside a container and then attach a session from VS Code. With a simple command, it is now easier than you might think.

$ make debug func=route1

This is now listening on port 8997 waiting for a debugging session to attach. The project comes with everything configured and ready to work. Open the project directory in VS Code, put a break point in your function and go to debugging tab in the left side and click on start debugging as shown below.

Docker Networking

In case you are running a docker container that’s in a specific docker network and you need your lambda to connect to this container; for example if you are running DynamoDB in a docker-compose stack locally, then its container will be running in a XX network, so you need to run your lambda inside the same network, simply pass network parameter when invoking your function as below.

$ make local-invoke func=route1 network=XX

Routing

None of these standard frameworks provides any way to add a new route under the service after you create it, this can be done easily by just running the following command, it will ask you simple questions such as route type and test framework to be used.

$ yo sls:route

Deployments

Make sure you have your own AWS keys defined in ~/.aws/credentials under default profile. To deploy your service, run the following command. It will deploy your service with the required resources as defined in serverless.yml or template.yml, based on the chosen framework.

$ make deploy

After you deploy your service, you can have the option to destroy the whole stack by simply running the following command:

$ make undeploy

Running the commands above will deploy and destroy the whole service. However in some cases you may want to deploy only one function that you just modified. If so, change the working directory to the route and deploy only this route by executing the below commands:

$ cd route1$ make deploy

Frameworks

If you created your project with the Serverless framework, you can still switch to use AWS SAM at any point in time. The following command will generate template.yml for SAM based on the defined serverless.yml.

$ make sam

In case you want to just try to invoke a function using SAM, run the following command which accepts event and network as arguments the same way as described earlier with local-invoke

$ make sam-invoke func=route1

Finally, this project is still under progress. Currently it supports Go, C#, Python and Java, nevertheless, there will be support for different features, frameworks and languages in the future.

If you like this article, It would be nice to star, fork, and/or contribute.

Go + Serverless Offline, Wait Go! YES, It is really simplified was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.