# 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