Meeting Minutes 2021 03 31

Meeting Minutes - 2021-03-31

Meeting Information

Meeting Date: 2021-03-31

Meeting Purpose: Regular catch-up

Note Taker: slang25

Attendees

• brainmurphy
• gkinsman
• maurofranchi
• slang25
• iancooper

Previous Action Items

Item	Who	Notes
Create issue/s to track future improvements	Brian	In progress ⌨

Agenda Items

Item	Who	Notes
Review Project board	All	Done
Update on the "optional infrastructure" work.	Stu/Brian	Work is underway and we have a project board where we are managing work and spikes.
What else can we do before V7? Release notes? Wiki updates? Docs? Training?	Brian	Discussed in items listed below.
AOB	All
Should v7 of JustSaying include the infrastructureless changes?	All	Consensus was yes, let's get it in to minimize churn for early adopters.
JustSayingStack - Do we need a v7 update at all?	All	Consensus; Lets proceed with the aim to not require a v7 JustSayingStack, and look to offer guidance & migration instead.
GitBooks Documentation	George	Demo provided by George, very cool! George has filed a bug report with GitBooks about an issue with it not syncing to our main branch, they are working on a fix.
README	All	Docs have been removed from README and it's now a bit bare, we could now use a "brochure style" section of the README to clearly present what JustSaying is about to anyone landing on the repo for the first time.
LocalStacks Docs	All	Agreed we could us a page within the GitBooks docs on how to get going with LocalStacks for local development
Contributors Guide	All	Agreed we could use a page on the README that explains running the JustSaying integration tests locally.

Publishing Large Messages (#889)

Mauro raised the issue of some messages (e.g. OrderCreated) occasionally exceeds the max payload of SQS (256KB). We discussed how this would fit into JustSaying:

• There is an official Java "extended client" provided by AWS, let's look there for inspiration (It uses S3 and message attributes).
• Nimbus do this: https://github.com/NimbusAPI/Nimbus/wiki/Large-Message-Support
• There are multiple approaches;
  • Store (i.e. S3) and pass a pointer
  • Aggregate
  • Compress
• Is this an indication that we have an issue with our message modelling? (i.e. is this a smell?)
• A compression/pointer approach would need support from all consumers (including Data Lake ingestion)
• A JustSaying implementation of the "extended client" approach (i.e S3 + message attribute) would require:
  • Publisher middleware's
  • Consideration of the S3 TTLs, would it match the message queue retention?
  • We'd need to plan adoption with the Just Eat Data team
  • Add a discussion point in the Lambda guide, it makes a good case for sharing a common dispatcher implementation.

Action Items

Item	Who	Due Date
Enable GitHub Discussion and put a message on Gitter	Brian & Stu	Immediately
Create GH issue for "brochure style" README section	Stu
Create GH issue for Contributor Guide	Stu
Raise discussion point with Lambda guide on large message support	George
Chase GitBooks for main branch sync bug resolution	George
Add Large Message discussion points to existing GH issue	Stu