v4 Events Lib - Major Version Change

[msailes]

The next major version of the aws-lambda-java-events library is now being worked on. As part of this we are considering changes around serialization. Our goals are to make it easier for customers to handle different serialization scenarios, reduce package size and to more easily add new events to the library.

Our current plans include enabling customers to bring their own serializer by implementing the PojoSerializer interface and including a provider-configuration file under META-INF/services.

To make it easier for new event objects to be added we are exploring ways to remove the use of mixins in the serialization library.

For example the SecretsManagerRotationEvent uses the SecretsManagerRotationEventMixin.java to change upper case attributes Step, SecretId and ClientRequestToken to lower case ones. This is required because Jackson expects lower case attribute names. Instead Jackson annotations will be added directly to the event fields which require them.

At this time we’ll also change the existing event objects to all follow the same design. Lombok annotations @Data, @NoArgsConstructor, @Builder(setterPrefix = "with"), @AllArgsConstructor and @Singular(when needed) will be added to events without them.

The joda-time dependency will be removed in this release.

[msailes]

@ilopmar, @olegz, @GoodforGod, @sdelamo, @FieryCod

[drissamri]

I'm not entirely aware on how the internals work right now. In my experiments around cold start performance I have always opted to use Jackson-jr instead of regular Jackson since it positively impacts the cold start. Now I use this, but internally ofcourse jackson regular is still being used so it's a double hit on performance.

Will this change make it possible to have internal serialization also leverage faster frameworks and be replace the current (slower) Jackson lib?

[sdelamo]

For a sample SQS event such as:

{
  "Records": [
    {
      "messageId": "19dd0b57-b21e-4ac1-bd88-01bbb068cb78",
      "receiptHandle": "MessageReceiptHandle",
      "body": "Hello from SQS!",
      "attributes": {
        "ApproximateReceiveCount": "1",
        "SentTimestamp": "1523232000000",
        "SenderId": "123456789012",
        "ApproximateFirstReceiveTimestamp": "1523232000001"
      },
      "messageAttributes": {},
      "md5OfBody": "{{{md5_of_body}}}",
      "eventSource": "aws:sqs",
      "eventSourceARN": "arn:aws:sqs:us-east-1:123456789012:MyQueue",
      "awsRegion": "us-east-1"
    }
  ]
}

I assume it Is currently working because you are using Jackson with

        mapper.configure(MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES, true);

https://github.com/aws/aws-lambda-java-libs/blob/master/aws-lambda-java-events/src/main/java/com/amazonaws/services/lambda/runtime/events/SQSEvent.java

If records is always Records in the JSON payload. It would be great if you could annotate with @JsonProperty. Replace:

public class SQSEvent implements Serializable, Cloneable {

    private static final long serialVersionUID = -5663700178408796225L;

    private List<SQSMessage> records;

with:

public class SQSEvent implements Serializable, Cloneable {

    private static final long serialVersionUID = -5663700178408796225L;

     @JsonProperty("Records")
    private List<SQSMessage> records;

We should not need to support case insensitive properties.

[graemerocher]

Please no lombok 🤢🤮

[msailes]

@sdelamo There is also a mixin for SQSEvent - https://github.com/aws/aws-lambda-java-libs/blob/master/aws-lambda-java-serialization/src/main/java/com/amazonaws/services/lambda/runtime/serialization/events/mixins/SQSEventMixin.java

[andclt]

@graemerocher What would you prefer?

[GoodforGod]

There is a good reason not to use lombok in libraries -> no source code compatibility, your decompiled Java code won't be compatible with the source code and IDEA would light red like Christmas lights, so probably that's better to generate getters\setters via IDEA manually from my point of view, but hell thats so much boiler plate for such library (lombok is ok in libs thats provides DTO from my point of view)

But when we are talking about library which whole purpose is to provide some kind of DTO, thats became debatable, standartization across whole code base (all lombok or all manual) from this stand point is good

I also thing that it's better to replace Lombok @builder with just @Setter & @accessors(chain = true) (if we are talking about Lombok)

As an example
https://github.com/GoodforGod/aws-lambda-java-events/blob/master/src/main/java/io/goodforgod/aws/lambda/events/ConnectEvent.java#L17