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.
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/FromJSONinstances 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 packageThat got me thinking: should we look at separating
halfrom the event types? A package name likeaws-lambda-eventssounds 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 onaesonand 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.