Skip to main content

3rd Fork

3rd Fork is the codename for the truly multi-tenant replacement for BMS. Iowa will launch on it, and San Francisco and eventually Oregon will be rolled in.

2023 Architecture Target

Executive Summary​

  • We are taking the San Francisco code and creating “3rd Fork”. This new system will be revised top to bottom to be truly "multi-tenant", meaning fully suitable for Iowa and for all new customers you want to sign going forward, with just one installation. No more duplication, no more big launch efforts for individual new jurisdictions. San Francisco will be rolled into this system within a few months of Iowa launch (it will be transparent to them).
  • 3rd Fork will normalize the APIs for all jurisdictions, including SF and Oregon through “proxies”.
  • This normalized API will allow us to release the mobile app updates easier.
  • It will also allow us to replace BMS 1, BMS 2, Green system, Purple system, SF Manager, and other disparate operations systems with a single modern employee-facing web app that handles all jurisdictions, and fixes a bunch of problems with security and for Dilan’s team and others at OBRC.
  • It will also allow us to build a single customer-facing web site / web app. Gard can still be involved if that’s best, but we can at least eliminate the technical issues we are running into and a bunch of the startup cost per jurisdiction.
  • Automated system self-tests will exist… all over the place. This is in part a stop-gap to prevent regressions, i.e. a change in one part of the system or for one jurisdiction that unexpectedly breaks some other part of the system, which is a big problem with the current code base. It also will help close the communication loops between PNDLM and Garen’s team on new features and bugs by explaining the specifications in advance in code. Finally it will be of great assistance in merging in San Francisco and eventually Oregon.

Dev Overview​

Summary​

If planned and executed correctly, OBRC can create and deploy a system in 2023 which allows for multiple jurisdictions beyond Iowa without significant code changes, while simultaneously reducing the amount of software systems that the OBRC development team must maintain ongoing. The system design prescribes methods for continuous improvement over time.

Details​

New fork of the backend code: “3rd Fork”. Iowa becomes a “tenant” of this new generic backend, which is built to handle all jurisdictions from a single instance going forward.

San Francisco and Oregon remain standalone at first. Although it sounds like a misstep to introduce yet a third system, it is the best way to make critical updates to the platform and prepare optimally to handle all jurisdictions ongoing without disrupting current San Francisco business.

3rd Fork exposes one consistent API for all apps and all tenants. (Currently, having separate APIs for Oregon and San Francisco causes problems for the mobile app because they are subtly different and shouldn’t be.)

Oregon and San Francisco standalone APIs are also proxied through 3rd Fork, with 3rd Fork accounting for the differences in the APIs automatically. This allows mobile and web apps going forward to work equally with all tenants including Oregon and San Francisco even while those systems remain waiting to be merged in.

A single unified consumer-facing web app will be adapted from the designs of the mobile app and will service all tenants going forward, optionally replacing sfbottlebank.org and my.bottledrop.com when desired by the business.

A single unified employee-facing web app will replace BMS Configurator, BMS 2, SF Manager, Green System and Purple System (and perhaps others yet to be identified) and eliminate the need to produce additional apps for Iowa and all tenants going forward.

Legacy apps can continue to access the standalone Oregon APIs directly, requiring no changes to do so until Oregon is merged into 3rd Fork.

Unit tests within 3rd Fork, external API tests against 3rd Fork, and end-to-end tests against the consumer mobile app, consumer web app, and employee web app, run for all tenants in succession automatically upon any change to the code, help to ensure that changes in one part of the code do not cause surprise breaks in other parts of the code or for other tenants.

San Francisco will be merged in by EoY 2023; Oregon TBD. The process of these merges will be assisted by the tests. If an engineer attempts to merge part of Oregon into 3rd Fork and a test begins to fail, they will know right away they still have work to do, until all of the tests pass.

Collaboration between PNDLM and OBRC will be further assisted by the presence of tests. If PNDLM requires a new API feature for the mobile app, for example, they will write a test in the system that tests that required feature, and it immediately fails because the API does not provide it. OBRC developers then work to update the code until the test passes. This will work to simplify communication between developers and the team about new feature requests and associated bug fixes.

For Further Discussion​

  • Inclusion of some ideas listed below
  • How to fully test real cash transactions and completion of other asyncronous tasks

Original "Switchboard" Ideas​

  • Self Testing (function catalog)
  • ServiceStack? API versioning
  • Swagger, DTOs
  • Tenant Preference + Catalog
  • Zero Trust / Auth -> SAML
    • Role Catalog
    • Service Accounts
  • Notification Service
  • Localization Service?
  • Passkey/WebAuthn support?