julien/adastra_app
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(adr): convert all ADRs to MADR 2.1.2 format

Browse Source 
Rewrites all 12 frontend 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.
This commit is contained in:
Julien Gautier
2026-04-26 16:50:34 +02:00
parent 8f2632f456
commit c8e2fba13e
12 changed files with 478 additions and 191 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/decisions/0001-migration-from-nextjs-to-angular.md
+39 -13
View File
@@ -1,21 +1,47 @@
# ADR 0001: Migration from Next.js/React to Angular
# Migrate frontend from Next.js to Angular
**Date:** 2026-04-26
**Status:** Accepted
- Status: accepted
- Date: 2026-04-26
## Context
## Context and Problem Statement
The project was initially built with Next.js (React). The development team already maintained an existing Angular stack for other projects. Running two separate frontend frameworks in parallel created an unnecessary knowledge split and increased maintenance overhead.
The project was initially built with Next.js (React). The development team already maintained an existing Angular stack for other projects, creating a knowledge split between two frontend frameworks. Server-side rendering — Next.js's main differentiator — was not required: all data is user-specific and served via authenticated API calls.
Server-side rendering, which is Next.js's main differentiator, was not required for this application — all data is user-specific and served via authenticated API calls, making SSR provide little to no benefit.
## Considered Options
## Decision
- Keep Next.js/React
- Migrate to Angular
- Migrate to Vue or Svelte
Migrate the frontend to Angular, reusing the existing Angular expertise and toolchain. The Next.js/React code (pages, components, utilities, middleware) is abandoned entirely.
## Decision Outcome
## Consequences
Chosen option: "Migrate to Angular", because the team already maintained an Angular stack for other projects, making it the path of least resistance with no additional knowledge split.
- **Positive:** Single frontend framework across projects. Reuse of existing Angular expertise, libraries, and patterns.
- **Positive:** No SSR complexity. The app is a pure SPA, which fits Angular's model.
- **Negative:** Complete rewrite of frontend code. No incremental migration path between React and Angular.
- **Residual:** Next.js artifacts (`.next/`, `next.config.js`, `src/modules/`, `src/middleware.ts`, etc.) were removed as part of the cleanup after the migration.
### Positive Consequences
- Single frontend framework across projects — reuse of existing expertise, libraries, and patterns.
- No SSR complexity; the app is a pure SPA, which fits Angular's model naturally.
### Negative Consequences
- Complete rewrite — no incremental migration path exists between React and Angular.
- Next.js artifacts (`.next/`, `src/modules/`, `src/middleware.ts`, etc.) required a dedicated cleanup pass after the migration.
## Pros and Cons of the Options
### Keep Next.js/React
- Good, because no rewrite cost.
- Bad, because maintaining two frontend frameworks in parallel increases overhead.
- Bad, because SSR provides no benefit for this authenticated, user-specific application.
### Migrate to Angular
- Good, because leverages existing team expertise.
- Good, because consistent toolchain across projects.
- Bad, because full rewrite required.
### Migrate to Vue or Svelte
- Good, because smaller bundle size.
- Bad, because no existing team expertise — introduces a third framework.