search

Nike-Inc / hal

hal provides an AWS Lambda Custom Runtime environment for your Haskell applications.
BSD 3-Clause "New" or "Revised" License
241 stars 13 forks source link

Feature/support api gateway proxy events #52

Closed IamfromSpace closed 3 years ago

IamfromSpace commented 4 years ago

Alrighty, I think I'm finally happy with this interface. I think this is the right balance between "looking like" the AWS examples while still leveraging types, smart constructors, and helpers to hide a lot of the uglier details.

endgame commented 4 years ago

Question: what is the goal of the hal package? If it's to eventually provide a full toolkit for lambda-related stuff, this PR makes a lot of sense here. If it's to provide just a runtime, then maybe a hal-api-gateway package makes more sense? (Probably still in this repo, with a cabal.project file. Something like https://github.com/hedgehogqa/haskell-hedgehog 's repo layout?)

IamfromSpace commented 4 years ago

Question: what is the goal of the hal package?

@endgame , It's a good question, and I'm not sure I've got a totally solid answer. I don't think it's strictly a low level handler, otherwise we would not have provided combinators and a plethora of different runtimes to choose from. I also don't think it'll be a comprehensive toolkit, because there's simply too much ground for this to cover.

I think either we support all official AWS events or we break all common events out into a separate module(s). And I probably lean further towards the latter. However, I also think that many people literally do not realize that Lambda /= Api Gateway Lambda HTTP APIs. The micronaut + Graal runtime for example, doesn't even support any other events (which seems crazy to me). So this event type is so core many people's thinking of Lambda, that I'm not too afraid to include it here--even if it's one of the very few to ever make it in.

In the future, I think one option is to use a separate library, move everything over, and then simply re-export it all here for backwards compatibility. That seems like a manageable approach going forward.

Curious if you've got other thoughts or concerns though :)

endgame commented 4 years ago

many people literally do not realize that Lambda /= Api Gateway Lambda HTTP APIs.

Heh, yes. I've had this problem in other contexts, where overly-"helpful" libraries have made it really hard to work with other event types.

In the future, I think one option is to use a separate library, move everything over, and then simply re-export it all here for backwards compatibility. That seems like a manageable approach going forward.

Split-when-necessary seems like a fine approach, and if you ever want to pare back the re exports you can do it with a major version bump.

One thing I've seen a couple of times: a project starts with foo package, which eventually gets too big. Eventually it splits into foo-core, foo-bar, foo-baz, foo-quux etc, and foo becomes compatibility/convenience re-exports. This seems fine, if hal gets so big that it becomes necessary. At a rate of one module per event type, that might not be necessary.