Structures for not-just-lambda events?

[JackKelly-Bellroy]

At work, we're considering using Lambda Destinations to respond to failed asynchronous lambda invocations. The obvious thing to do would be to PR some new types and ToJSON/FromJSON instances for that type, but they're not really lambda-specific: they can also be sent to SQS Queues, SNS Topics, or onto an EventBridge Event Bus. So there's a decent case for putting it in some other package

That got me thinking: should we look at separating hal from the event types? A package name like aws-lambda-events sounds like a fine home for events sent to Lambda Functions (e.g., things that come from an Event Source Mapping) as well as events generated by Lambda Functions (e.g., invocation records sent to a Lambda Destination, regardless of type). And the package would only really need to depend on aeson and testing libraries.

I'm interested to hear what you think here, and what namespace we could use to ensure a smooth transition. I expect we'd want to do something clever with re-exports or something so that existing code can keep working with warnings, and then migrate to using the new package as a direct dependency.

[IamfromSpace]

I agree that separating the two is probably a good idea. The recent move of the Aeson parser was quite a pain for compatibility, so my lean is either to do this soon, or just commit to this being the long term place for events. I think that's likely not a good idea because I just generally expect that to be a bit more volatile.

So, I think now is probably the best time if more schemas (events or destinations) are of interest. Based on the Aeson changes, I think flags are the way to go. It looks like we can add a flag to Hal that keeps event modules out so that they don't collide with the new package. It would default to the existing behavior today, and then maybe eventually we just no longer export them at all in future major version bump.

[JackKelly-Bellroy]

I'm not sure we need to do too much with flags to ensure a smooth experience for users.

What made things hard in the aeson case was IIRC that the package with no modules wasn't initially present, and its lower bounds excluded a lot of previous versions, and it needed aeson machinery in its implemenation. This forced downstream packages to use flags. I think we can avoid both of these if we're careful.

What I propose we do:

1. Decide on a namespace for AWS events that's not going to clash. Network.AWS.* is pretty full of amazonka <2.0 stuff, so my first thought of Network.AWS.Events.* is probably bad. Maybe Data.AWS.Event.*?
2. Decide on a package name for events. Maybe aws-events?
3. Decide which new version V of hal will include phase 1 of the migration
4. Move the event mapping structures across to aws-events-0.1.0.0. In version V of hal, re-export event mappings from AWS.Lambda.Events.* and mark these modules as deprecated.

I think this means packages can move across to aws-events at their own pace, and both can be present in the dependency graph without clashing.