Allow multiple handlers in the same binary

[benkehoe]

For other languages on Lambda, a single deployment artifact (JAR or zip file) can have multiple handlers functions in them. Multiple Lambda functions can use the same deployment artifact, with different behavior based on the handler selected in the Lambda function configuration. For Go, this isn't possible. lambda.Start(handler interface{}) takes a single function. This means a separate binary has to be built for every function, and since Go builds are statically linked, there's no speedup when functions share code. This has caused users create custom build systems like Fender has to parallelize their builds.

This would be in concert with the Lambda service supporting handler function specification for Go functions in the API.

[benkehoe]

A possible solution:

1. Make Start variadic: lambda.Start(handler ...interface{}) to keep existing code working correctly.
2. Use reflection to catalog the function names. (This appears possible)
3. On invoke, check os.Getenv(_HANDLER), and if it's the same as the executable name, and there's one entry, use that (compatibility with existing behavior). Otherwise, look up the handler function by name.

[mweagle]

@benkehoe - This is a great suggestion and one I'd also like to see supported.

[bmoffatt]

Cool suggestion! This approach may also benefit cold-start times for users sharing a single jumbo .zip across many functions. I'll pass it along to the product team.

[terrywarwar]

This will help reduce boilerplate code: mains --> build.

[SimplyKnownAsG]

Can you already accomplish this goal through specifying the environment variable within the aws lambda create-function call? It wouldn't have the benefit of jumbo.zip cold start times as @bmoffatt suggested.

Can you specify a command line argument to the lambda? Then you might be able to use a CLI tool to generate subcommands within a single build.

[benkehoe]

You're right that it might be possible to implement this as a library that would provide its own single handler function, which would then look up the actual handler name from an env var and delegate to it. I still think that should be seen as a temporary measure and native support should be the goal.

[yurilaaziz]

Any updates on this ?