-
Notifications
You must be signed in to change notification settings - Fork 18
Meeting Minutes 2021 05 26
Meeting Date: 2021-05-26
Meeting Purpose: Regular catch-up
Note Taker: gkinsman
- Stuart Lang
- Dec
- Alberto Olivares
- George Kinsman
- Monica
- Teck Loy Low
- Tim van Wijk
| Item | Who | Notes |
|---|---|---|
| Create issue/s to track future improvements | Brian | In progress ⌨ |
| Create GH issue for Contributor Guide | Stu |
| Item | Who | Notes |
|---|---|---|
| Large message working group. | Brian | Discussions are ongoing in the other working group, we're still waiting for it to firm up before doing anything in JS. Interesting discussion on how we might support alternative serializers in JS, notes below. |
| Update on the "optional infrastructure" work. | Stu/Brian | Tim and Dec gave demo on using JustSayingStack with ref arch. Discovered issue in JS 6 where it doesn't handle the last message until its visibility timeout for that message expires. Stu to investigate so we can be sure the same issue doesn't exist in JS 7. Tim and Dec will work on a JS7 app next. |
| What else can we do before V7? Release notes? Wiki updates? Docs? Training? | Brian | - |
| Discuss "Subject Deprecation: https://github.com/justeat/JustSaying/discussions/916 | All | Briefly discussed - felt it would tie in to the large message support well as a re-think of how we do serialization. |
| AOB | All | Notes below. |
We had a discussion on how our serialization might need to change to support large messages. The problem is that currently JS expects a particular format that doesn't provide a reasonable way of adding metadata. If we can make our serializer API more flexible then we could swap in one that understands alternative formats. Lots of questions came out of this.
- How hard is it to plug in different serializers? Could we start making them pluggable so we could support new formats?
- Weird that you need to add serializers per message - could we specify them once at the top level instead?
- Can we hide the details of which serializer is required for each message?
- Monica's team have messages that are occasionally too big, which is what we've seen elsewhere.
- Does the message size include the SNS envelope? Could make determination of whether to send to S3 trickier.
Monica and Teck came along to talk about conversation id's and how currently, they're not required which means that most people don't include them. George expressed concern that if we were to auto-generate them if they were missing, then it would be difficult to spot where a conversation had been broken due to not passing it through from e.g. a web request.
We agreed that a set of integration packages to make this eaiser could be a good solution.
- The Data/analytics team wishes for it to be easier to enrich messages with ConversationIds to make event correlation and behaviour tracing easier.
- 30-50% of analysis will use JS data
- Is it better to have no conversation id or a wrong conversation id? ○ Always set to new one vs require user to set it ○ George suggested we default to no id, but make it easy to add via integrations
- Can we use IMessageContextAccessor to populate it from a handler context?
- Can we use integration packages to make this work without knowing about each possible source? (e.g. Message handler, web api)
- The data/analytics team have a document that outlines what they're after, so lets take a look at it and come back to this.
| Item | Who | Due Date |
|---|---|---|
| Open issue to start thinking about how we can support more flexible serializers | George | |
| Investigate JS6 bug so we can be sure the same issue doesn't exist in JS 7 | Stu |