Golang support

[RafalWilinski]

This is a Feature Proposal

Description

AWS Lambda now supports Golang: https://twitter.com/mthenw/status/936302935478358016
We should add aws-golang template.

[horike37]

It was pre-announcement at re-invent. We should wait for the official release a couple of weeks.

[horike37]

Finally!
https://aws.amazon.com/about-aws/whats-new/2018/01/aws-lambda-supports-go/

[mrserverless]

I can spend some time looking at this and potentially consolidate of the things I've been doing in https://github.com/yunspace/serverless-golang into the official repo. Happy to collaborate on this if anyone has already started

[horike37]

AWESOME @yunspace 💯 Thank you for jumping in !!!
I know your plugin 😄 That is one of the most popular plugins of the framework!

AFAIK, nobody started working on this, so it would be great if you can do that 😄
To introduce this new feature, we need to implement the following stuff.

1. Specify golang runtime to CloudFormation template generated by the framework.
2. Add golang template when running sls create --template aws-golang.
3. Add test template with docker-compose.
4. Add it to the framework documentation.

Additionally, we need local invoke functionality as well, but it would be good to separate another issue.

You can refer to the past PR for introducing other templates something like this
#3483
#3849

Let us (@serverless/framework-maintainers) know if you have any other questions!

[flemay]

Looking at the documentation Lambda Handler in Go , it seems the handler.go would only be for 1 lambda (1 main() function to start the lambda) so I was wondering how would Serverless use the same code for more than 1 function. 🤔

[HyperBrain]

@flemay Opposed to other languages, Go exports a main() function as entry point for the executable - so it should be one executable per handler, which is perfectly fine.
I see code sharing here on a Go library level. If you want to share code, create multiple libraries and import them into your handlers.

[franciscocpg]

right @HyperBrain 👍
But in this case this (one executable per handler) also means that we need one folder per handler.

What I mean is:

this should not work

.
├── handler1.go
├── handler2.go

this should work

.
├── handler1
│   └── main.go
├── handler2
│   └── main.go

[HyperBrain]

@franciscocpg That should be easy to achieve. If the runtime is "go", it should be disallowed to specify handlers without a relative path in the serverless.yml.

# serverless.yml
functions:
  okfunc:
    handler: myfunc/handler
  invalidfunc:
    handler: handler

Does that sound feasible?

[flemay]

So I've tried with 1 function only with different approaches: in folder, not in folder
Also tried with handler executable matching the name of the function generated by serverless i.e myproject-stage-functionname because according to AWS doc

Note that your function-name must match the name of your Lambda handler name

And I've got errors similar to the following

{
    "errorMessage": "fork/exec /var/task/myproject-dev-handler: no such file or directory",
    "errorType": "PathError"
}

Somehow it does not find anything in /var/task 🤔