Refactor init 2 #28
Refactor init 2 #28
Conversation
tomerd
force-pushed
the
refactor-init-2
branch
6 times, most recently
from
9678b53 to
4727ed1
Compare
| /// | ||
| /// - note: This is a blocking operation that will run forever, as it's lifecycle is managed by the AWS Lambda Runtime Engine. | ||
| @inlinable | ||
| public static func run(_ factory: @escaping LambdaHandlerFactory) { |
There was a problem hiding this comment.
Here we use a typealias LambdaHandlerFactory
I would guess we will also offer just a handler closure option. Do we want to name those run() {} and the factory closures functions like this one createHandlerAndRun() {}
There was a problem hiding this comment.
personally like the shorter name but can consider makeAndRun in a different PR?
| /// | ||
| /// - note: This is a blocking operation that will run forever, as it's lifecycle is managed by the AWS Lambda Runtime Engine. | ||
| @inlinable | ||
| public static func run(_ factory: @escaping (EventLoop) throws -> LambdaHandler) { |
There was a problem hiding this comment.
Here we don't use a typealias.
There was a problem hiding this comment.
that's because its used in much less place and not user facing, typically you would pass in a ctor here
There was a problem hiding this comment.
I personally like the shorter name but can consider wrong commentmakeAndRun in a different PR?
| @@ -113,31 +150,33 @@ public enum Lambda { | |||
| private let eventLoop: EventLoop | |||
There was a problem hiding this comment.
Maybe we should move this Lambda.Lifecycle into another file.
There was a problem hiding this comment.
will do in another PR
motivation: make initialization logic more robust, allowing setup at contructor time and also async bootstrap changes: * break apart "initialization" into two parts: * optional throwing constructor (provider) that takes an EventLoop * optional BootstrappedLambdaHandler protocol that takes an EventLoop and returns async * update core API and logic to support new initialization logic * add tests to various initialization flows
motivation: make initialization logic more robust, allowing setup at contructor time and also async bootstrap changes: * break apart "initialization" into two parts: * optional throwing constructor (provider) that takes an EventLoop * optional BootstrappedLambdaHandler protocol that takes an EventLoop and returns async * update core API and logic to support new initialization logic * add tests to various initialization flows
alternative to #24