Considerations for custom runtimes

[endgame]

There are a couple of things in the AWS docs on custom runtimes that could be neat to bake into hal. Some of these would likely require major version bumps:

• Custom initialisation step: Maybe an additional IO a or IO (Either e a) argument to the runtime functions, whose a is made available to the callbacks? (catch exceptions and report them using the lambda runtime api).
• The _HANDLER environment variable lets the same piece of code be deployed multiple times to handle different requests, and limits the proliferation of executable targets in cabal files for larger lambda applications. One way to do this could be to provide a Handler GADT that can wrap up functions matching the types of those in AWS.Lambda.Runtime, and a function runHandlers :: [(Text, Handler)] -> IO () or something.

[IamfromSpace]

Custom Initialization Step

Definitely, a custom init step would be interesting--I had built that into some tooling I had done with node some time ago. In theory this could go into a ReaderT or StateT monad? Perhaps it's as simple as just building a new combinator from bracket?

I could never get my head around the right interface though. I'm also not sure it's possible in all cases to capture all initialization work, as you need to run more and more complex monads.

Curious to see any ideas you've got though!

Utilize _HANDLER

Interesting, it's crossed my mind that a user could leverage this, but I could never come up with a real use case. If we had many lambdas, and wanted to build a single executable that could support each, why not simply use a single lambda? In this case, you'll get more sharing and therefore reduced cold starts. The only real advantage I could think of was IAM separation.

I suppose if two lambdas can receive the exact same event type that truly couldn't be distinguished, then you'd need some other way to tell them apart and _HANDLER could do that. I'm not sure I've really seen a need for that though--it seems like you'd prefer to live in a world where your event is processed solely according to it's content.

[endgame]

I'll make a separate issue to continue the _HANDLER discussions.

[endgame]

Custom initialisation is easily done by calling functions in IO before calling into hal. I'm closing this, because i believe that the strength of hal is its simplicity.