Technologie-Stack (A-4 / OP-STACK-1)
Bezug: A-4, OP-STACK-1 · Status: entschieden (2026-06-27) — Cloudflare-Stack (Workers + D1
- Queues + Cron), analog Schwesterprojekt Taktano.
Leitlinie
G-1 Standardwerkzeuge bevorzugen. Der Stack soll bewährt, gut dokumentiert und gut anbindbar sein (NextCloud, DocuSign/PandaDoc, CRM, E-Mail). Kein exotischer Eigenbau dort, wo ein Standard trägt. Medidentas ist im Kern eine Orchestrierungs-/Workflow-Anwendung mit Web-UI, API-Integrationen, Persistenz für Prozess-Status + Audit-Log und einem Scheduler für Wiedervorlagen.
Anforderungen an den Stack
| # | Anforderung | Warum |
|---|---|---|
| 1 | Web-UI (sprechend, einfach, G-3) | Cockpit + Bearbeitung |
| 2 | API-Integrationen (REST/Webhooks) | NextCloud, Signatur, CRM |
| 3 | Persistenz (relational) für Prozess-Status + append-only Audit-Log | G-4 |
| 4 | Scheduler/Queue für Wiedervorlagen & Reconciliation | R5, RISK-6 |
| 5 | EU-/CH-Hosting möglich | G-5, Datenresidenz |
| 6 | Auth/SSO anbindbar | R7, OP-AUTH-1 |
Optionen (zu bewerten, OP-STACK-1)
| Option | Skizze | Pro | Contra |
|---|---|---|---|
| Standard-Web-Framework + SQL (z. B. serverseitig gerendert oder SPA + API) | klassische 3-Tier-App, Postgres, Job-Queue | maximal bewährt, einfach zu hosten (EU), viel Standard-Tooling | „nur" Standard — kein Alleinstellungsmerkmal nötig |
| Backend-as-a-Service / Low-Code | z. B. gehostete Plattform mit Auth/DB/Functions | sehr schnell zum MVP, wenig Infra | Lock-in, Audit-Log/Residenz genau prüfen |
| Cloudflare Worker + D1/Queues (wie Schwesterprojekt) | Edge-Worker, D1, Queues | bekannt im Haus, günstig, EU-Region | Reife für relationales Audit-Log + lange Aufbewahrung prüfen |
Entscheidung (2026-06-27): Cloudflare-Stack (A-4 gesetzt)
Gewählt: der Cloudflare-Stack wie beim Schwesterprojekt Taktano — Workers (API/Backend) ·
D1 (SQLite, relationale Persistenz inkl. append-only Audit-Log) · Queues + Cron Triggers
(Wiedervorlagen, Webhook-Reconciliation) · statischer Web-Client (Angular, am --tk-*-Token-Muster
orientiert) · Zugang via Cloudflare Access (SSO).
Begründung:
- In-House-Know-how (G-1): identischer Stack wie Taktano → bewährte Patterns (Versionierung, Migrations, CI/Deploy, Logger-Wrapper) wiederverwendbar statt neu erfinden.
- EU-/Datenresidenz (G-5): D1/Workers mit EU-Jurisdiction betreibbar; passt zu DSGVO/revDSG.
- Kosten & Betrieb: günstig, wenig Infra, ein Deploy-Weg (
wrangler). - Erfüllt Anforderungen 1–6: Web-UI, REST/Webhooks, relationale Persistenz, Scheduler/Queue, EU-Hosting, SSO.
Bewusst geprüfte Vorbehalte (→ Folge-OPs):
- Audit-Log-Reife auf D1 (OP-AUDIT-1): D1 (SQLite) trägt das append-only Event-Modell; für lange Aufbewahrung (GoBD/§147 AO, 6–10 J.) ist eine Archiv-/Retention-Strategie zu definieren (Export/ kalt-Storage in R2, ggf. Hash-Verkettung). Kein Blocker, aber früh zu planen.
- Tool-Host-Runtime (OP-EXT-1): Spezial-Tools (Dexman) laufen als zusätzliche Worker-Routen/Services mit eigenem D1-Namespace je Tool (Isolation, R10).
Konventionen, die der Stack festlegt (analog Taktano)
- Versions-Single-Source:
APP_VERSION(SemVer, manuell je PR) an einer Stelle (server/src/ version.ts); Build-Nummer automatisch aus dem Git-Commit-Count gestempelt (kollisionsfrei, OP-PM-1). Dann greift derversion.ts-Teil im Doku-Konsistenz-Check (wieder aktivieren). - Persistenz/Migrationen: versioniert + idempotente Auto-Migration (
schemaVersion/onStart-Remaps); Drizzle-Schema als Single Source → generierte SQL-Migrationen (künftig OP-DATA-1). - Observability (OP-OBS-1): strukturierter Logger-Wrapper (PII-Scrubbing,
trace_id), Backend OTel/OTLP offen.
Folge-Entscheidungen, die am Stack hängen
- OP-AUDIT-1 (Audit-Store auf D1 + Retention/Archiv über R2), OP-OBS-1 (Logging/OTel-Backend), OP-AUTH-1 (Cloudflare Access + Rollenmodell), OP-DATA-1 (Drizzle-Migrations-Gate), OP-EXT-1 (Tool-Host-Runtime/Isolation).