Skip to content

Arch Forum 2023-11-16

Participants: Backend developers, Victor

Agenda

  • API Gateway / Service Aggregation Layer
  • .NET 8

Notes

In order to have something to look at Victor had prepared a couple of slides with starting points for both topics, here: https://docs.google.com/presentation/d/1hxvfhW3oJGY16YkyfP3OuZgXiyLNw87q1Ya0Q0AQYTc/edit#slide=id.g29c0d02f66f_0_0

API Gateway / Service Aggregation Layer: The first topic was around API Gateways (for simplicity API Gateway is used as a catch-all for all kinds of related tech like hosted API Gateway products, Backends For Frontends (BFF), routing in nginx etc.). Victor started with a short overview of how we do things today, why it might not be enough, and things to think about. During and afterward, a discussion followed.

Several points were raised that were not covered in the initial presentation:
- Even with a new dedicated API gateway it won't be straight forward to use in memory rate limiting, since the gateway will need to be deployed on multiple pods
- It could be useful to collect all APIs under a single domain, however we must not forget about third party callbacks which can be difficult to change (and old app versions)
- A API Gateway could help untangle the web of dependencies in Backend, where many areas depend on each other directly with REST calls, which could be moved up one layer to the gateway instead.
- In many cases, areas today need to keep / fetch information just to be able to provide it to Apps, but not for its own logic.
- The mixing of domains from product can force antipattern designs / coupling in backend, like with address change coupling with card ordering.
- Firebase could be an attractive solution in theory. However, early on we tried having more state there for at least KYC, and it was moved out because of unreliability reasons.

Note that the reason to bring this up was mostly to get input from everyone on where we are, and what the general thoughts are. It is not clear if we need/should change our current setup, and if so what we should introduce.

.NET 8: A new long term support (LTS) version of .NET was just released, .NET 8. We had a short overview (see the slides above) and discussion and could conclude that we want to upgrade, but we need to think of the order of things. We think it should be fairly straight forward, much easier than previous upgrade to .NET 6. The new .NET 8 version should be stable, so we can start upgrading whenever. Since the upgrade comes with many new features, we should hold an overview presentation / discussion of the new features.
This work is tracked in MP-450