Repository navigation
Make Events derive from a common abstract type #59
Description
Use case: Create a lambda function that handles different event types
The handler class has to implement the RequestHandler interface with <T,String>, being T one of the event types. As those do not share a common ancestory type, we need to implement the handling of each event type as a separa te class, and hence a separate Lambda. Having a common ancestor type would allow to implement RequestHandler<LambdaEventAbstractType,String> and determine in the handler function the type of event by inspecting its class with event.getClass().
This would also be a more Object oriented design, with a group of closely related types having a common ancestor.
We can now do something similar by implementing RequestHandler<Object,String> but it is poorer design and too loose in terms of type control.
Activity
jblacker commentedon Feb 26, 2019
This would be very helpful for creating base classes and shared logic between different lambda functions or multiple triggers to the same function.
jainishshah17 commentedon Aug 15, 2019
I am also looking for this feature. I want to trigger my lambda function with SQSEvent/CloudWatchLogs Event.
simon1389 commentedon Sep 23, 2021
any updates on this?
msailes commentedon Sep 24, 2021
No, update. This may be considered in the future, but not at the moment.
smirnoal commentedon May 13, 2022
which interface do you think would be useful to introduce? Also wanted to learn more about what would differentiate
LambdaEventAbstractTypefromObject, usecases would be helpful. Thanks!bump: RIC version (#59)
smirnoal commentedon Sep 3, 2024
resolving this issue as not planned. I would not recommend the proposed pattern with
LambdaEventAbstractTypeand making reflection api calls to determine the actual type during runtime, but rather use compile-time capabilities to detect possible errors earlier in the process.bump: RIC version (#59)