Skip to content

Arch Forum 2023-11-09

Participants: Backend developers, EMs, Andy, JD, Victor

Agenda

  • Recap and clarification of decisions and discussions
  • Backwards compatibility
  • API Gateway (out of time for this topic)

Notes

Recap and clarification of decisions and decisions: First we had a recap and short clarification of what to expect from these meetings.

Backwards compatibility: The first (and only) topic of the day was about backwards compatibility. Recently, we've had two cases where we did things that were not fully backwards compatible and created problems. A rename of an enum field, and a merge of two InsufficientBalanceException into one.

Victor prefaced the discussion with an emphasis that the actual changes, especially the second one (InsufficientBalanceException) were very good, we should not be afraid to clean up and refactor the code!

We could see that its mainly 3 types of breaking changes:
- API/Service rest interfaces
- Events
- DB changes

We could further note that any breaking change in any of these can potentially create issues, even if it's only internal in a single area, since our deployments happen step-by-step. For example, DB is deployed before code, therefor new DB needs to support old code. Another case is old API call new Service, or new API call old Service. If the deploy pipeline has a problem, what normally is a short delay between the deploy steps can result in a long delay, meaning the chance that both new and old co-exist when an external call come in increases.

A related question came up, when a breaking change (but not in public API) happens, who is responsible for fixing all the broken renovate PRs. We believe that the developer that commit breaking changes should also try and fix all the broken PRs. If it's tricky/difficult, for example because the change need area specific logic, then ask area owners for help. To help to know if some change break Renovate PRs, it would be very useful with a Slack notification that commit X broke Renovate PR in area Y.

Lastly the discussion went to the PR template. Their usage is a bit unclear, and recently we have not been very strict to fill them in. JD stressed that the checklists are there for a reason, especially for CDE services, PCI puts requirements on many of those checkboxes. We should really try to fill it in. At the same time, some of it might be outdated, and in those cases we should update the template.

Outcomes

  • By default, any change should be backwards compatible.
  • If there's a good reason, we can make an exception. In this case it's important to think through the change, and make the rest aware, for example in #minority-backend or in standups or other meetings.

API Gateway: The backwards compatibility discussed used up most of the meeting, this topic has to be discussed another time.