Allow specifying port for local server

[eneko]

Enhancements

• Allow specifying TCP port to listen when running lambda in local server. This will allow for running multiple lambdas at the same time in a local set up.
• If no port is specified, default 7000 port (from RuntimeEngine configuration) is used.

Usage

#if DEBUG
try Lambda.withLocalServer(port: 7001) {
    Lambda.run { (_, request: Request, callback) in
        callback(.success(Response(message: "Hello, \(request.name)!")))
    }
}
#else
Lambda.run { (_, request: Request, callback) in
    callback(.success(Response(message: "Hello, \(request.name)!")))
}
#endif

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[fabianfett]

Thanks @eneko, for the proposed change. This is something that we should definitely support, since it will make local development much easier.

We do have a problem however: Just changing the port of the server where the lambda is invoked is not enough. The Lambda uses the same port for the local control plane. That's why we also need to instruct the lambda to look for the control plane at the new specified port.

We could do this by locally setting the AWS_LAMBDA_RUNTIME_API env variable. @tomerd wdyt?

[tomerd]

thanks @eneko as @fabianfett points out changing the server is not enough, as we need to coordinate the configuration between the lambda (client) and the mock server. we chose to expose this woth an env variable that can be set in Xcode (scheme menu) or command line and is also how aws communicates the desired configuration.

We could do this by locally setting the AWS_LAMBDA_RUNTIME_API env variable

correct: https://github.com/swift-server/swift-aws-lambda-runtime/blob/master/Sources/AWSLambdaRuntimeCore/LambdaConfiguration.swift#L72

[eneko]

Thanks for the feedback, @fabianfett & @tomerd.

While having the environment variable is a great for a single lambda (both release and debug), it is not trivial when running multiple lambdas. The goal for this PR was to make this trivial, very easy todo.

While Xcode schemes allow for defining environment variables for each scheme, this might be harder to achieve without using Xcode.

For example, I'd like to do:

$ swift run Lambda1    # on one terminal (port 7000)
$ swift run Lambda2   # on another terminal (port 7001)
etc...

How about replacing:

let ipPort = env("AWS_LAMBDA_RUNTIME_API")?.split(separator: ":") ?? ["127.0.0.1", "7000"]

With something like:

let ipPort = env("AWS_LAMBDA_RUNTIME_API")?.split(separator: ":") ?? [DefaultIPPort.ip, DefaultIPPort.port]

Then, somewhere accessible:

// Somewhere accessible
struct DefaultIPPort {
  static var ip: String = "127.0.0.1"
  static var port: String = "7000"
}

Usage would be:

DefaultIPPort.port = "7001"
try Lambda.withLocalServer {
    Lambda.run { (_, request: Request, callback) in
        callback(.success(Response(message: "Hello, \(request.name)!")))
    }
}

Or like on the PR changes:

try Lambda.withLocalServer(port: 7001) { // DefaultIPPort.port set to "7001" inside Lambda.withLocalServer
    Lambda.run { (_, request: Request, callback) in
        callback(.success(Response(message: "Hello, \(request.name)!")))
    }
}

Thoughts?

[fabianfett]

hi @eneko, you can set an env variable on the terminal pretty easy:

$ AWS_LAMBDA_RUNTIME_API="localhost:7001" swift run lambda1
$ AWS_LAMBDA_RUNTIME_API="localhost:7002" swift run lambda2

should do the trick!

[eneko]

Yep, I'm aware of that, is just not pretty, or trivial, nor have the desire to type it each time.

If there is no interest on finding a better solution, I'll go ahead and close the PR, no worries.

Thank you!

[fabianfett]

If there is no interest on finding a better solution, I'll go ahead and close the PR, no worries.

Don't get me wrong here. I just wanted to ensure that you have a quick fix for the situation at hand.

As I stated above, I think this is something that we should address. We just need to make sure that we find a good solution... And we should be able to support this going forward. As you may have seen in #83, we have some plans for the local server and we need to make sure that all stars align.