julien
a9ef4cf629
Rewrites all 7 backend ADRs from a custom structure to the MADR 2.1.2 template required by the VS Code ADR Manager extension: bullet metadata (Status/Date), standardised section headings, "Chosen option: X, because Y" wording, and explicit Pros/Cons blocks per option.
47 lines
2.1 KiB
Markdown
47 lines
2.1 KiB
Markdown
# Maintain frontend and backend in separate repositories
|
|
|
|
* Status: accepted
|
|
* Date: 2026-04-26
|
|
|
|
## Context and Problem Statement
|
|
|
|
The frontend (Angular SPA) and backend (Express API) are distinct deployment units with different runtimes, dependencies, and release cycles. Should they live in the same repository or in separate ones?
|
|
|
|
## Considered Options
|
|
|
|
* Separate repositories (`adastra_app` and `adastra_api`)
|
|
* Monorepo (managed with Nx or Turborepo)
|
|
|
|
## Decision Outcome
|
|
|
|
Chosen option: "Separate repositories", because the two applications have independent dependency trees and deployment lifecycles, and the current scale does not justify the tooling overhead of a monorepo.
|
|
|
|
Both repositories are treated as a single product during development: the Angular frontend's `CLAUDE.md` declares `adastra_api` as an additional working directory so that cross-repo tasks can be handled in a single session. Tasks that span both (e.g. adding an endpoint and its frontend consumer) are handled together.
|
|
|
|
### Positive Consequences
|
|
|
|
* Independent dependency management — `package.json` files don't interfere with each other.
|
|
* Simpler per-repo CI/CD pipeline when production deployment is configured.
|
|
* Each repo's git history reflects only its own changes.
|
|
|
|
### Negative Consequences
|
|
|
|
* No shared type definitions between frontend and backend. API contract changes must be coordinated manually.
|
|
* Cross-repo changes require two separate commits. A monorepo would allow atomic cross-boundary commits.
|
|
|
|
## Pros and Cons of the Options
|
|
|
|
### Separate repositories
|
|
|
|
* Good, because independent dependency management and deployment.
|
|
* Good, because clean git history per application.
|
|
* Bad, because no shared types — API contract drift must be caught manually.
|
|
* Bad, because cross-repo changes require coordinated commits in two places.
|
|
|
|
### Monorepo (Nx or Turborepo)
|
|
|
|
* Good, because atomic cross-boundary commits and shared type definitions.
|
|
* Good, because single place to run all tasks (build, test, lint).
|
|
* Bad, because significant tooling overhead not justified at the current scale.
|
|
* Bad, because requires migrating both repos and learning monorepo tooling.
|