Refactor init

[tomerd]

No description provided.

[tomerd]

needs #23

[tomerd]

@fabianfett we discussed the topic in #11. this API change bring two things:

1. users can provide a LambdaHandler with a throwing init(eventLoop: EventLoop) ctor, which could be then used to initialize things like db-drivers, async-http-client etc. The lambda can then be run with Lambda.run(MyLambda.init)

2. users can implement an optional bootstrap method via the BootstrappedLambdaHandler protocol for lambdas that need to once-only-action like preloading data from some remote source.

error in either of these will report an initialization error to the lambda runtime engine

[tomerd]

cc @glbrntt as you implemented the original init logic

[glbrntt]

typo: it's -> its (and elsewhere)

[tomerd]

will address in a following PR as we are about to refactor these APIs

[glbrntt]

1. users can provide a LambdaHandler with a throwing init(eventLoop: EventLoop) ctor, which could be then used to initialize things like db-drivers, async-http-client etc. The lambda can then be run with Lambda.run(MyLambda.init)

@tomerd why did you go for a provider over the init you described here? So you don't force users to have an event loop?

[fabianfett]

Okay, long story short, I like the LambdaHandlerProvider idea a lot. So much, that I would keep it as the single solution and change it to:

public typealias LambdaHandlerProvider = (EventLoopGroup, EventLoopPromise<LambdaHandler>)

If we have this we don't need extra bootstrap callbacks:

• all preparation work can be done in the provider
• bootup error are reported
• developers get access to the EventLoopGroup
• the handler struct can have lets for everything needed.

Of course we can derive easier to use, potentially blocking, APIs from this. But as we have the LambdaHandler as the source of truth this should be the bootup source of truth ;)

[fabianfett]

I like this a lot! What do you think about making this:

• async with a promise?
• providing the EventLoopGroup? As I stated before: with more than 1700mb of ram one get's access to two cores, and I would really like to use both 😉
• I think, if we make this async we don't need the bootstrap callback, and we can all call it a day? With this we have one callback that initialises a struct where we can set all properties.

[tomerd]

thanks @fabianfett

async with a promise?
I think, if we make this async we don't need the bootstrap callback, and we can all call it a day? With this we have one callback that initialises a struct where we can set all properties.

the idea of separating this into a init (provider) and a bootstrap phases, is that we can make the provider blocking+throwing and the bootstrap async. this means you can do things like Lambda.run(MyLambda.init) in which you initialize some database/http client with the event loop that will run the lambda but dont have to worry calling a callback or completing a promise. we could change the provider API to also take a callback/promise and then create invariants of the user facing API that call-the-callback/complete-the-promise on the user's behalf to keep the user facing API simpler. I will play with that idea and post another version if it turns out okay

providing the EventLoopGroup? As I stated before: with more than 1700mb of ram one get's access to two cores, and I would really like to use both 😉

interesting point. the goal for exposing the underlying eventLoop to the be able to share it with a database/http client (for example) that also uses swift-nio. further, the eventLoopGroup we are using in the library only has 1 thread, since it optimizing for the lambda runtime use case and ensuring 1 thread is good for nio's performance. of course, the user can always create their own EventLoopGroup and use that if they want to do things in parallel.

[tomerd]

@fabianfett @glbrntt here is the other alternative: #28

it works but a bit complicated to reason about so not sure which I prefer

[tomerd]

@tomerd why did you go for a provider over the init you described here? So you don't force users to have an event loop?

@glbrntt an init that takes an EventLoop (ie init(eventLoop: EventLoop) == LambdaHandlerProvider signature, so this should work as described unless I am missing something?

[glbrntt]

@tomerd why did you go for a provider over the init you described here? So you don't force users to have an event loop?

@glbrntt an init that takes an EventLoop (ie init(eventLoop: EventLoop) == LambdaHandlerProvider signature, so this should work as described unless I am missing something?

Ah, I misinterpreted it: thought you meant the init was part of the LambdaHandler protocol.

[tomerd]

replaced with #28