# Create an captur-apis repo

## Problem:
- Our models get out of sync
- Lots of duplicated code (models, interfaces, enums, utils)
- Lots of duplicated configs (testconfig, eslint, CI/CD, tsconfig)
- Hard to keep in sync
- Inconsistent business logic

## Proposed solutions:
- Shared Packages (interfaces, enums, utils, etc)
- Monorepo (using either Nx or Turborepo)
- leave as is, and take out stable things into packages (like configs)

### Shared packages:
- Weird ergonomics and having too many versions in case of breaking changes
- Secrets sharing (when using github packages) Proof of concept was performed
- when upgrading something as you have to simultaniously deploy on multiple repos (or use seperate versions)

### An API monorepo:
- Our core and tasks share models and we have to either copy or maintain each change, having sharing them the following is a huge base already seen benefit: models, interfaces, enums
- Using tools like Nx or Turborepo will help alot,
- Futhermore, sharing utils comes in handy as we do have more than half of our utils duplicated and actively used (while the others might not be used and just duplicated between repos)

## Initial Structure thoughts:
- Apps
- `core`
- Auth handling
- Serving UI
- `tasks`
- Scheduled tasks
- Heavy queries and data processing (eg: analytics daily runs or exports)
- Currently also handling external integrations
- `analytics`
- Recieves analytics daily reports from tasks
- Accumulates and stores data into its seperate database `analytics`
- Serves dashboard and seperate database `analytics` serves mongodb charts
- Packages - prefixed with `@captur/<package-name>`
- `@captur/types` **enums and interfaces** (publishable)
- `@captur/<database-name>-models`
- `@captur/captur-models` - has our `captur` database model definitions
- `@captur/analytics-models` - has our `analytics` database models definitions
- `utils` - **Not implemented yet**
- Need a guideline as in when to take it into utils, or keep it app specific
- Need a rule to help decide on stuff that need enviroment variables (like storage utils)
- Can break down into seperate utils:
- date utils (these are shared between all and even frontends copied them)
- validation/middleware utils
- business logic (`getStageUpdates`)
- Configs
- `@captur/eslint-config`
- `@captur/tsconfig`
- `@captur/jest-config`
- `/test/~` for test setup and teardown
- `/root/scripts/~` repo tooling
- `.github/actions/~` reusable github actions in same repo

## Draft guidelines/convention:
- Think about when you wanna put something in `packages/*` especially if only one app is going to use it
- Respect repos dependency graph, and when you propose a change it needs to be approved by majority
- Think about how apis call each other and we should outline it

### Resources:
- https://monorepo.tools/
- https://nx.dev/more-concepts/turbo-and-nx