Web-App · Gesundheit

Physio Web-App – echte App statt Telegram-Bot

Unterstützt Physiotherapie-Patienten zwischen den Terminen. Die Web-App generiert individuelle Workouts, protokolliert Sessions und macht Therapeuten-Notizen über einen sicheren Login jederzeit abrufbar – mit n8n als vollständigem Backend.

2026 · Web-App · n8n Backend · JWT · Vercel · Google Sheets

Projekt auf einen Blick

🎯

Ziel

Strukturierte Betreuung von Physiotherapie-Patienten zwischen den Terminen.

👥

Zielgruppe

Patienten und Physiotherapeut, getrennte Bereiche.

🛠️

Technologien

n8n, Vanilla JS, JWT, Google Sheets, Vercel.

✅

Status

Live, produktiv im Einsatz.

📦

Umfang

7 n8n-Webhook-Workflows, Patienten- und Admin-Interface.

Die Ausgangslage

Der Ausgangspunkt war ein einfacher Telegram-Bot für Sportübungen. Aber ein Bot hat Grenzen: keine übersichtliche Darstellung, keine strukturierten Protokolle, kein Admin-Bereich für den Therapeuten. Für eine Physiotherapiepraxis braucht es mehr.

n8n ist nicht nur ein Automatisierungstool – es kann das vollständige Backend einer Web-App sein.

Die Herausforderung

Die größte technische Hürde: Auf der eigenen n8n-Instanz ist require() blockiert – klassisches Bcrypt-Hashing für Passwörter war damit nicht möglich. Zusätzlich mussten Login, Workout-Generierung, Session-Protokoll und Admin-Funktionen komplett ohne klassischen Server-Code auskommen, nur über n8n-Webhooks.

Die Lösung

HMAC-SHA256 direkt über den n8n Crypto Node übernimmt das Passwort-Hashing sicher, ohne externe Library. n8n stellt außerdem JWT-Tokens aus und prüft sie bei jedem Request – die komplette Backend-Logik läuft über 7 Webhook-Workflows, das Frontend ist eine reine Vanilla-JS-SPA mit Login, persönlichem Workout-Plan, Fortschrittsprotokoll und einem Admin-Interface für den Physiotherapeuten.

Die Umsetzung

Was die App kann

🔐

Sicheres Login

JWT-Auth mit HMAC-SHA256 Passwort-Hashing. Patient und Admin haben getrennte Login-Bereiche und Berechtigungen.

💪

Workout-Generator

Individuell zusammengestellte Übungseinheiten aus einem Übungskatalog. Jeder Patient bekommt seine eigenen Empfehlungen.

📋

Session-Protokoll

Alle absolvierten Einheiten werden protokolliert – Datum, Übungen, Dauer. Die Fortschrittshistorie ist jederzeit abrufbar.

📝

Therapeuten-Notizen

Der Admin kann Notizen zu jedem Patienten hinterlegen – Beobachtungen, Anpassungen, Hinweise für die nächste Einheit.

Architektur: n8n als Backend

Das Besondere an diesem Projekt: Es gibt keinen klassischen Server-Backend-Code. n8n übernimmt die gesamte Backend-Logik über 7 Webhook-Workflows. Das Frontend ist eine Vanilla-JS-SPA auf Vercel, die ausschließlich mit diesen Webhooks kommuniziert.

Frontend

Vanilla JS SPA mit Hash-Router – index.html (Patienten) + admin.html – deployed auf Vercel

Auth

JWT via n8n JWT Node · HMAC-SHA256 Passwort-Hashing · separater Admin-Login

Backend

7 n8n Webhook-Workflows: Login, Admin Login, Workout, Sessions (Log + History), Notes, Admin-Operationen

Daten

Google Sheets – Übungskatalog, Nutzer, Sessions, Notizen (4 Tabs)

Tech-Stack

Frontend	Vanilla JS, Hash-Router, kein Framework
Hosting	Vercel (npx vercel --prod)
Backend	n8n Webhooks (7 Workflows)
Auth	JWT + HMAC-SHA256 (n8n Crypto Node)
Datenbank	Google Sheets (4 Tabs)
Dev-Tool	Claude Code

n8n als vollständiges Backend

Dieses Projekt zeigt was mit n8n möglich ist: Kein separater Node.js-Server, kein Express, kein Framework. Alle API-Routen sind n8n-Webhooks. Authentifizierung, Datenverarbeitung, CRUD – alles läuft in n8n. Das macht das Projekt extrem wartungsarm: Änderungen am Backend sind im n8n-Editor erledigt, kein Deployment nötig.

Ergebnis & Mehrwert

Kein separater Node.js-Server, kein Express, kein Framework – trotzdem eine vollständige App mit Login, individuellem Workout-Plan und Therapeuten-Notizen. Das macht das Projekt wartungsarm: Änderungen am Backend sind im n8n-Editor erledigt, ganz ohne Deployment.

Screenshots

Patienten-Interface – Dashboard und Session-Protokoll

Erkenntnisse

Eine Erkenntnis aus diesem Projekt: Bei GET-Webhooks kommt das JWT aus dem Authorization-Header, nicht aus dem Body – ein Unterschied, der am Anfang für einiges an Debugging gesorgt hat, bevor ich ihn richtig verstanden hatte.

Das Admin-Interface habe ich bewusst als komplett separate HTML-Datei mit eigenem Login-Flow umgesetzt, obwohl beide Seiten dieselbe n8n-Backend-Infrastruktur teilen – die strikte Trennung hat sich seitdem als der robustere Ansatz erwiesen.