Skip to content

Meeting Minutes 2021 03 31

Stuart Lang edited this page Mar 31, 2021 · 6 revisions

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