Skip to content

Arch Forum 2024-11-07

Participants: Backend devs, Andy, Magnus Victor and Zak

Agenda

  • Open Source/Firebase.SDK
  • JsonProperty
  • Security Scan (Magnus)
  • Common prefix of all BE repos?
  • Automatic Code Cleanup (Rasmus)

Notes

Open Source/Firebase.SDK

Recently we forked FirebaseCoreSDK. This is a library published on nuget.org made by previous employee Shoaib, and hosted on his personal Github. We have now forked it to our own Github account to be able to update it and publish new nugets. The fork was renamed to Firebase.SDK. While updating platform to use the forked version, Victor noted that it would be easier if the code were integrated into platform instead of a separate (public) package on Github.

Andy's view is that we can open source libraries, but it requires a couple of things:
1. Open source packages are
1. If we publish code public, we need to keep it in "good" shape, since it reflects on MAJORITY
1. Majority wont force or prioritize this, meaning there needs to be at least one, preferably more, passionate developers, that ensure the package is handled properly.

Security Scan

Magnus gave an update of the updated security code scanning. Magnus will update his PRs slightly to adjust how the configuration in the csproj files look. Once new PRs are pushed the area owners need to review, fix and merge these.

JsonProperty

About a year ago we discussed the need for camelCasing of fields in Service contracts. At that time we said we do not need them. However, when Ling raised the question about if we actually follow this now, its not obvious its a good idea. When looking at our current code base, in the majority of cases we use camelCase to events and other Service contracts.

With the current state its better to follow what we already have, since its very very difficult to change existing contracts. Consistency is key. Therefore the updated guideline is to use camelCase when serialized properties (meaning a JsonProperty attribute should be used) for consumption outside the Area. That means for example Events, Service.Contracts etc. (DB entities should not have any JsonProperty attribute)
The guideline is here (with updates): https://dev.azure.com/MAJORITY/Documentation/_wiki/wikis/Main/96/Design-Guidelines

Common prefix of all BE repos?

With the move to Github there's no concept like the "Projects" in Devops. Therefore backend repositories will be mixed with FE, Data and Web repos. As such Victor raised the question if we should change to a common prefix for all backend repos, to easier distinguish them. We also believe we need to tag the repos. This is also a good time to unify Bank

Update after meeting:

Zak and Victor synced and came up with be- prefix for backend repos, and when needed an additional mf- or cde- prefix, like
- CDE/cde-carddata -> be-cde-carddata
- Bank/bank-user -> be-user
- Bank/bank-remittance -> be-remittance
- Moneyflow/Remittance -> be-mf-remittance

Cleanup (Rasmus)

Rasmus asked what we think of the current code cleanup/formatting job that runs in the pipelines. The need for a common format of all C# code is good. However, the way it works now is suboptimal. "Its a pain in the ass when it breaks the build" summarizes the feeling well.

  • A more lightweight option could be dotnet format which is also available in VS, and based on .editorconfig
  • Rasmus will make an example for a coming meeting
  • If we change formatting rules (it is likely that not all existing rules will carry over to new solution), we should make a full format everywhere to get to a good starting state.