1.7 KiB
1.7 KiB
ADR 0012 — Frontend-Strategie
Status
Accepted
Kurz erklärt
Die Frontend-Strategie legt fest, wie Benutzer die Anwendung bedienen.
Wichtig ist die Frage:
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