# Using a Monolith for Genius Core Clients in Various Languages

* Status: approved
* Deciders: @prasaanth-verses, @link-verses, @tom-mason-verses
* Date: 2024-05-01

## Context and Problem Statement

We have three language-specific SDKs (Rust, Node, Python) that provide the same functionality: authentication and operations on Genius DB. While they offer a great developer experience, they also result in duplicate code. By using a monolith for the core functionality, we can reduce code duplication. However, the challenge lies in doing this in a way that is well organized, supports auto incrementing versioning, and supports the language deployment workflow that we want to have.

## Decision Drivers

- Code Duplication: The solution must reduce code duplication.
- Versioning: The solution must support auto incrementing versioning.
- Deployment Workflow: The solution must support the language deployment workflow that we want to have.
- Maintainability: Preference for solutions that are easier to maintain and support.

## Considered Options

- [Monolith](https://en.wikipedia.org/wiki/Monolithic_application)
- [Separate Repositories](https://en.wikipedia.org/wiki/Microservices)

## Decision Outcome
Chosen option: "Monolith", because it reduces code duplication, simplifies the deployment process, and is easier to maintain in the long run.

### Positive Consequences

- Reduces code duplication across different language SDKs.
- Simplifies the deployment process by centralizing updates.
- Easier to maintain and update a single codebase. 

### Negative Consequences

- Potentially slower initial setup due to the need to integrate multiple languages into a single framework.

## Pros and Cons of the Options

### Option 1: Monolith

#### Monolith is good, because it's
- Centralized, which simplifies maintenance and deployment.
- Efficient in reducing code duplication.
- Easier to manage versioning and dependencies.
- Easier to maintain and prevent code behaviour drift across the various client libraries. When there is a change in functionality or a new feature that needs to be implemented, the 3 clients can be updated in a single PR and versioned / deployed together.

#### Monolith is bad, because it's
- More complex to set up initially.

### Option 2: Separate Repositories

#### Separate Repositories are good, because they
- Allow for language-specific optimizations.
- Can be independently developed and deployed.

#### Separate Repositories are bad, because they
- Increase code duplication.
- Complicate the versioning and deployment process.
- Require more resources to maintain multiple codebases.
- Can lead to code behaviour drift across the various client libraries if one language has features / functionalities that are not present in the other languages.