Zum Inhalt springen
zurück zu den projekten

// projekt ·

Spider Gym: React-SPA-Frontend

Eine Fitnessstudio-App neu gebaut, damit alte Django-Templates nicht mehr das Frontend bestimmen. Stack: React, TypeScript, Vite, Django, Vitest.

React 19 / TypeScript 6 / Vite / Tailwind CSS v4 / React Router v7 / Vitest / Django 5.2 / DRF

Rolle: Freelance · Frontend-Migration · Jahr: 2024 - 2025 · Status: ausgeliefert

kurz: Den Django-5.2-Monolithen eines laufenden Fitnessstudios mit 67 Templates in eine typisierte React-SPA mit 68 Routen über 10 Bereiche migriert. Zuerst gegen einen json-server-Mock zu bauen hieß, dass Frontend und das DRF-Backend unter /api/v2/ parallel ausgeliefert werden konnten. Die Lehre: Ein typisierter API-Client plus Vitest-Abdeckung macht aus einer großen Migration überprüfbare, mergebare Arbeit.

Problem

Spider Gym lief auf einem Django-5.2-Monolithen mit 67 serverseitig gerenderten Templates. Die Aufgabe war, daraus eine typisierte React-SPA zu machen, ohne etwas zu verlieren, worauf das Team angewiesen war: Mitgliederverwaltung, Mitgliedschaften, Zahlungen, QR-Check-ins, ein Empfangs-Dashboard und Admin-Reports.

Rahmenbedingungen

  • Das Studio bleibt offen. Das Team nutzt das System täglich, die Migration durfte den Empfang also nicht lahmlegen.
  • Das Backend war nicht fertig. Die DRF-Endpoints unter /api/v2/ entstanden zeitgleich mit dem Frontend.
  • Drei Rollen im Team (Admin, Empfang, Kasse) sehen unterschiedliche Teile der App.

Entscheidungen

  • Zuerst die Mock-API. Die SPA nutzte einen json-server-Mock, der den geplanten DRF-Vertrag spiegelte, also wurden Frontend und Backend parallel ausgeliefert. Der Umstieg war ein Wechsel der Basis-URL.
  • Ein typisierter API-Client, früh geschrieben, übernimmt CSRF und die gemeinsamen Antwortformen und gab dem Backend-Team ein konkretes Ziel.
  • RBAC auf beiden Seiten. Django-Berechtigungen und eigene Decorators auf dem Server; ein React-Auth-Kontext mit isAdmin, isReceptionist und isCashier plus geschützte Routen im Client.
  • QR-Scannen wanderte in den Browser. Der alte Ablauf dekodierte Codes serverseitig mit pyzbar und NumPy. html5-qrcode im Browser nahm das Backend aus der Scanschleife und zeigt den Mitgliedsstatus sofort an.
  • React 19, TypeScript 6, Vite 8, Tailwind CSS v4 und React Router v7, der React Compiler übernimmt die Memoisierung.

Ergebnis

Die SPA ging mit 68 Routen über 10 Bereiche und 60+ typisierten Komponenten live, mit Ladezuständen, Skeleton-Screens, Error Boundaries und responsivem Layout auf jeder Route. Vitest und React Testing Library decken die migrationskritischen Abläufe ab: Login, Check-in, Verlängerung der Mitgliedschaft und Zahlung. Die Lehre: Ein früh vorhandener Frontend-Vertrag entblockt das Backend, und eine dünne Testschicht über den schmerzhaften Abläufen ist eine billige Versicherung bei einer langen Migration.