feat(event-sources): cache parsed json in data class

[michaelbrewer]

Issue #, if available:

• #844

Description of changes:

A micro optimization to cache the parsed json within the event source data class

Checklist

• Meet tenets criteria
• Update tests
• Update docs
• PR title follows conventional commit semantics

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov-commenter]

Codecov Report

Merging #909 (7a623f2) into develop (cd15ee9) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop     #909      +/-   ##
===========================================
+ Coverage    99.90%   99.92%   +0.01%     
===========================================
  Files          118      118              
  Lines         5246     5255       +9     
  Branches       596      600       +4     
===========================================
+ Hits          5241     5251      +10     
  Misses           1        1              
+ Partials         4        3       -1     

Impacted Files	Coverage Δ
...wertools/utilities/data_classes/active_mq_event.py	100.00% <100.00%> (ø)
.../utilities/data_classes/code_pipeline_job_event.py	100.00% <100.00%> (ø)
...lambda_powertools/utilities/data_classes/common.py	100.00% <100.00%> (ø)
...wertools/utilities/data_classes/rabbit_mq_event.py	100.00% <100.00%> (ø)
.../utilities/data_classes/cognito_user_pool_event.py	100.00% <0.00%> (+0.26%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cd15ee9...7a623f2. Read the comment docs.

[heitorlessa]

I'm fine with this solution - better than actual caching as UX and memory would've been tricky.

As we're gonna do it, let's revisit all other fields that do any sort of deserialisation -- Kinesis is one that does it heavy (json + b64) etc

[michaelbrewer]

@heitorlessa ok. I will update others like this too.

[michaelbrewer]

@heitorlessa - ok i have added various singleton caching options.

[brysontyrrell]

This looks great! Looking forward to applying it.

[heitorlessa]

I was gonna suggest a decorator but given the amount of fields we're fine. If we get a feature request to optimize other fields that require expensive operation like decoding & unzipping CloudWatch Logs record, or decoding and JSON parsing Kinesis records, then we should refactor this to allow for growth.

Future note: If more fields are required, we should convert this into a reusable one-item @cache class decorator. This will make it easier to maintain and support any property we might want like a base64/gzip operation, e.g. @cache would keep the property name as key and its value in memory, cache["property_name"] = return_value

[heitorlessa]

Just one question on the usefulness of tests; happy to merge otherwise

[michaelbrewer]

@heitorlessa - was thinking of a @cache decorator, might end up in the future or just use a builtin python3 feature in the future. it is minor right now right?

[heitorlessa]

@heitorlessa - was thinking of a @cache decorator, might end up in the future or just use a builtin python3 feature in the future. it is minor right now right?

Like this but we don't need the threading safety I believe, as it'll compute once and more lightweight and faster than the LRU cache - once we deprecate older Python versions we can use it natively.

We would need to test whether that work for our data types tho, but should be easily adjustable as the logic is simple

https://github.com/python/cpython/blob/e9a01e231aae19fd1249368e477a60bc033b2646/Lib/functools.py#L955

[heitorlessa]

Merging as is - I'll look into the hash dunder and decorator when Mypy is fully supported across the codebase