Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document what to do with AWS "Handler" name. #57

Open
fabianfett opened this issue Apr 6, 2020 · 4 comments
Open

Document what to do with AWS "Handler" name. #57

fabianfett opened this issue Apr 6, 2020 · 4 comments
Labels
documentation Improvements or additions to documentation

Comments

@fabianfett
Copy link
Member

We currently don't respect the chosen handler and rely on the executable being named bootstrap. We should at least document that we don't care about the given handler name, or that developers might want to use it in their lambda startup method to decide which handler they wanna attach to the runtime.

@fabianfett fabianfett added the documentation Improvements or additions to documentation label Apr 6, 2020
@Andrea-Scuderi
Copy link
Contributor

I think the handler name is important as the code could contain many lambda function in the same binary even if it executes the only one selected.

@fabianfett
Copy link
Member Author

fabianfett commented May 29, 2020

Hi @Andrea-Scuderi , you can easily achieve the use case you mention with the tools at hand right now:

import AWSLambdaRuntime

switch Lambda.env("_HANDLER") {
case "foo":
     Lambda.run(FooHandler())
case "bar":
     Lambda.run(BarHandler())
default:
    preconditionError("Unexpected handler name: \(Lambda.env("_HANDLER") ?? "none given")")
}

In my humble opinion it doesn't make much sense though to include two or more Handlers in one executable:

  1. If you want to have two different Lambdas, you need to upload the binary twice anyway. AWS does not allow two Lambda functions to share the same binary.
  2. Having more than one Handler within a binary increases the size of the executable, which increases download time onto the Lambda executor and dynamic linking time (cold start time).

Instead I would suggest you create an executable target for each lambda. This way you will have better performance and one less String attached. 😉

In other languages like golang the _HANDLER referrers to the name of the binary. This is something that you can easily build yourself with a bootstrap script that you ship with your lambda. But be aware including multiple binaries within your zip will dramatically worsen your cold start performance.

@Andrea-Scuderi
Copy link
Contributor

@fabianfett Agreed, your considerations are right, but there are cases in which this could make sense:

  1. The binary can be stored in a lambda layer and shared among lambdas.
  2. If the size of the binary doesn't change dramatically by adding more Lambdas, the advantage of having a fatter one could pay in terms of deployment time by reducing the complexity of creating more swift targets in the package. Having a small number of target in the swift package could speed up build time, packaging and upload time. 😉

@Andrea-Scuderi
Copy link
Contributor

Here the example with multiple handlers #125

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants