70 lines
1.7 KiB
Markdown
70 lines
1.7 KiB
Markdown
# ADR 0012 — Frontend-Strategie
|
|
|
|
## Status
|
|
Accepted
|
|
|
|
## Kurz erklärt
|
|
Die Frontend-Strategie legt fest, wie Benutzer die Anwendung bedienen.
|
|
|
|
Wichtig ist die Frage:
|
|
|
|
```text
|
|
Klassische Laravel-Seiten
|
|
oder modernes API-basiertes Frontend?
|
|
```
|
|
|
|
## Kontext
|
|
Das Architekturreview hat kritisiert, dass „Blade oder später Vue/Nuxt“ eine offene Grundsatzentscheidung ist.
|
|
|
|
Für API-first darf das Frontend nicht direkt an Datenbanklogik hängen.
|
|
|
|
## Entscheidung
|
|
V1 verwendet ein Laravel-basiertes Admin-Frontend, aber strikt über interne Service-/API-Schichten.
|
|
|
|
Es wird kein vollständig getrenntes Nuxt/Vue-SPA in V1 gebaut.
|
|
|
|
Das Frontend darf nicht direkt fachliche Datenbanklogik umgehen.
|
|
|
|
## Warum?
|
|
Ein vollständiges SPA erhöht V1-Komplexität:
|
|
|
|
- separater Build-Prozess
|
|
- separate Auth-Flows
|
|
- mehr Frontend-Architektur
|
|
- mehr Testing-Aufwand
|
|
|
|
Für V1 ist ein Laravel-nahes Frontend effizienter.
|
|
|
|
## API-first bleibt bestehen
|
|
API-first bedeutet hier:
|
|
|
|
- Geschäftslogik liegt in Services/Contracts
|
|
- REST API wird parallel sauber definiert
|
|
- spätere externe Clients bleiben möglich
|
|
- WordPress-Plugin nutzt später ausschließlich API
|
|
|
|
## Später möglich
|
|
In V2/V3 kann ein SPA-Frontend entstehen, wenn:
|
|
|
|
- API stabil ist
|
|
- Auth-Scopes klar sind
|
|
- Kundenportal ausgebaut wird
|
|
- Plugin-/App-Ökosystem entsteht
|
|
|
|
## Konsequenzen
|
|
|
|
### Positiv
|
|
- schnellerer V1-Start
|
|
- weniger Komplexität
|
|
- gute Laravel-Integration
|
|
|
|
### Negativ
|
|
- API-first muss diszipliniert umgesetzt werden
|
|
- Gefahr eines klassischen Laravel-Monolithen bleibt
|
|
- klare Architekturregeln nötig
|
|
|
|
## Verwandte ADRs
|
|
- ADR 0006 — Auth-Strategie
|
|
- ADR 0018 — WordPress-Plugin-Security
|
|
- ADR 0020 — Customer-Portal-Scope
|