Add support for EventBridge and ParameterStoreChange event mappings

[JackKelly-Bellroy]

EventBridge is quite configurable, so it is possible to send a reduced payload or even completely rearrange the JSON that goes onto the event bus. But it's still useful to capture the entirety of an event in a Haskell type.

I'm not sure how many other event mappings I'll need to add from my work, but the scheme I'm establishing here is AWS.Lambda.Events.EventBridge.#{service}.#{event}, to let people add events as-needed.

Is there some point beyond which we should split hal from event mappings?

[IamfromSpace]

Is there some point beyond which we should split hal from event mappings?

It's a good Q; I'm honestly not sure. I think my primary concern with them long term is the lack of independent evolution could lead to noise in breaks--especially given AWS' example-only approach to schemas, which leave them feeling a bit fragile (or overly defensive and less helpful). I at least feel like we're nearing the threshold where we should change the strategy, but I'm not really able to quantify my take here.

[JackKelly-Bellroy]

Yeah, noise in breaks would be bad. There are several other benefits if we split them out:

• They're potentially usable by other code which uses lambda (e.g., other runtimes, code which invokes lambdas for testing)
• The events package would have quite a lean dependency set (off the top of my head: aeson, boot libraries, hedgehog, hspec, hspec-hedgehog, I guess?)

[IamfromSpace]

Published in 0.4.10! Docs pending. Thanks for another solid addition :)

[JackKelly-Bellroy]

You're welcome. hal has been a great library for us, and I'm glad that I can give back.