Plan

Migration Plan – NewWebApp (Frontend: Svelte/Vite, kein SvelteKit/TS; Backend: Express)

0) Ziele und Rahmen

• Einheitliche Sprache (EN), klare API unter /api/v4/....
• Neues Projekt unter NewWebApp/ mit frontend/ und server/.
• DRY: so wenig Code wie möglich, klar strukturierte Services/Utilities.
• Vorhandenes Frontend/Backend nur als Vorlage für Design/Funktion, nicht 1:1 kopieren.

1) Grundgerüst

• Ordnerstruktur anlegen: NewWebApp/frontend, NewWebApp/server, NewWebApp/docs.
• Frontend scaffold: Svelte + Vite (kein SvelteKit, kein TS).
• Backend scaffold: Express (ESM/CJS je nach Präferenz), Basis-Middleware (cors, json, logging).

2) API-Konzept (v4)

• Ressourcen und Routen definieren (englisch):
  • /api/v4/auth (login, device-validate, sessions)
  • /api/v4/users (CRUD, profile, settings, avatar)
  • /api/v4/sessions (active sessions/devices)
  • /api/v4/flights (read arrivals/departures)
  • /api/v4/conditions (membership, reminders)
  • /api/v4/invoices (create, history, pending, unseen/mark-seen)
  • /api/v4/feedback (feature feedback)
  • /api/v4/admin/... (force reauth, user management, pdf validation, etc.)
• Auth/Headers konsistent: x-user-email, x-device-id (oder Token, falls gewünscht).

3) Backend-Basis

• Models (Mongo) für Users, Sessions/Devices, Flights (proxy), Conditions, Invoices, Feedback.
• Services/Controllers pro Domäne; keine Legacy-Pfade, optional Kompat-Wrapper falls nötig.
• Jobs/Cron (node-cron) für Online-Status/cleanup in einem Modul.

4) Frontend-Basis

• API-Client mit klaren Services (auth, users, flights, invoices, admin, feedback).
• Komponenten sauber trennen (Präsentation), zentrale Stores nur für Zustand, keine Geschäftslogik in Views.
• Auth-/Header-Handling zentral.

5) Iterative Migration

• a) Auth/Device/Conditions/Menu → neue APIs.
• b) Profil/Settings/Avatar → /users-Routen.
• c) Flugplan → /flights.
• d) Invoices/Feedback → /invoices, /feedback.
• e) Admin-Funktionen → /admin/....
• Pro Schritt Tests/Smoke-Tests, Alt-System parallel weiter.

6) Online/Session Handling

• Einheitliches Session/Device-Modul (z.B. sessions Collection): Felder email, deviceId, lastActivity, isOnline.
• Cleanup-Job für stale Sessions; Membership-Invalidation integriert.
• Block/Unblock/Limit in einem Service, keine Doppelmethoden.

7) Deployment/Übergang

• Separate Pipeline für NewWebApp (Subdomain/Subpath).
• Service Worker/Cache-Strategie neu, kein Legacy übernehmen.
• Datenmigration planen (Schema-Kompatibilität prüfen) oder zunächst Read-only gegen alte DB, dann schrittweise umstellen.

8) Offene Punkte

• Automatisierter Endpunkt-Scan des alten Projekts (Frontend/Dist) zur vollständigen Matrix.
• Mapping alter Domain-spezifischer Routen (muc4taxi…) auf neue Ressourcen, ggf. Alias-Layer.
• Teststrategie (Unit/Integration/E2E) definieren, bevor Funktionen portiert werden.