Skip to content

Allow custom initialisation of the HandlerType of the LambdaRuntime. #308

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

Closed
wants to merge 3 commits into from

Conversation

tachyonics
Copy link
Contributor

Allow custom initialisation of the HandlerType of the LambdaRuntime.

Motivation:

Provide the flexibility for custom initialisation of the HandlerType as this will often be required by higher level frameworks.

Modifications:

Modify the LambdaRuntime type to accept a closure to provide the handler rather than requiring that it is provided by a static method on the Handler type. This is achieved by a new base protocol NonFactoryByteBufferLambdaHandler that does not have the makeHandler function requirement.

Also provide a new base protocol NonFactoryLambdaHandler that doesn't have the initialisation requirements of either LambdaHandler or SimpleLambdaHandler. This will allow higher level frameworks to initialise their own handlers that however can take advantage of the Codable conveniences of this package.

@Sendable
func handlerProvider(context: LambdaInitializationContext) 
-> EventLoopFuture<some NonFactoryByteBufferLambdaHandler> {
    let underlyingHandler = <initialise a type conforming to NonFactoryLambdaHandler>
    let codableHandler = underlyingHandler.withWrappingCodableHandler(allocator: context.allocator)

    return context.eventLoop.makeSuceededFuture(codableHandler)
}

Result:

Existing high level use cases (LambdaHandler and SimpleLambdaHandler) will continue to be provided but a lower level integration will be possible aimed at higher level frameworks.

tomerd added a commit to tomerd/swift-aws-lambda-runtime that referenced this pull request Oct 10, 2023
Motivation:

Provide the flexibility for custom initialisation of the HandlerType as this will often be required by higher level frameworks.

Modifications:
* Modify the LambdaRuntime type to accept a closure to provide the handler rather than requiring that it is provided by a static method on the Handler type
* Update downstream code to use HandlerProvider
* Update upstream code to support passing Hanlder Type of Handler Provider
* Add and update tests

Originally suggested and coded by @tachyonics in swift-server#308
@tomerd
Copy link
Contributor

tomerd commented Oct 10, 2023

thanks for putting together @tachyonics, I finally had time to review and came up with a slightly more minimal change in #310. If the minimalistic approach is good enough for your use case we can update #308 to that end and close #310 or vice versa.

tomerd added a commit to tomerd/swift-aws-lambda-runtime that referenced this pull request Oct 10, 2023
Motivation:

Provide the flexibility for custom initialisation of the HandlerType as this will often be required by higher level frameworks.

Modifications:
* Modify the LambdaRuntime type to accept a closure to provide the handler rather than requiring that it is provided by a static method on the Handler type
* Update downstream code to use HandlerProvider
* Update upstream code to support passing Hanlder Type of Handler Provider
* Add and update tests

Originally suggested and coded by @tachyonics in swift-server#308
tomerd added a commit to tomerd/swift-aws-lambda-runtime that referenced this pull request Oct 10, 2023
Motivation:

Provide the flexibility for custom initialisation of the HandlerType as this will often be required by higher level frameworks.

Modifications:
* Modify the LambdaRuntime type to accept a closure to provide the handler rather than requiring that it is provided by a static method on the Handler type
* Update downstream code to use HandlerProvider
* Update upstream code to support passing Hanlder Type of Handler Provider
* Add and update tests

Originally suggested and coded by @tachyonics in swift-server#308
tomerd added a commit to tomerd/swift-aws-lambda-runtime that referenced this pull request Dec 7, 2023
Motivation:

Provide the flexibility for custom initialisation of the HandlerType as this will often be required by higher level frameworks.

Modifications:
* Modify the LambdaRuntime type to accept a closure to provide the handler rather than requiring that it is provided by a static method on the Handler type
* Update downstream code to use HandlerProvider
* Update upstream code to support passing Hanlder Type of Handler Provider
* Add and update tests

Originally suggested and coded by @tachyonics in swift-server#308
tomerd added a commit to tomerd/swift-aws-lambda-runtime that referenced this pull request Dec 8, 2023
Motivation:

Provide the flexibility for custom initialisation of the HandlerType as this will often be required by higher level frameworks.

Modifications:
* Modify the LambdaRuntime type to accept a closure to provide the handler rather than requiring that it is provided by a static method on the Handler type
* Update downstream code to use HandlerProvider
* Update upstream code to support passing Hanlder Type of Handler Provider
* Add and update tests

Originally suggested and coded by @tachyonics in swift-server#308
@tachyonics
Copy link
Contributor Author

Closing as this has been replaced by #310

@tachyonics tachyonics closed this Dec 8, 2023
@tachyonics tachyonics deleted the low_level_provider branch December 8, 2023 22:06
tomerd added a commit that referenced this pull request Jan 18, 2024
…310)

Motivation:

Provide the flexibility for custom initialization of the HandlerType as this will often be required by higher level frameworks.

Modifications:
* Modify the LambdaRuntime type to accept a closure to provide the handler rather than requiring that it is provided by a static method on the Handler type
* Update downstream code to use HandlerProvider
* Update upstream code to support passing Handler Type of Handler Provider
* Add and update tests

Originally suggested and coded by @tachyonics in #308
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants