Physio Web-App – echte App statt Telegram-Bot
Vollständige Web-Applikation für Physiotherapie-Patienten – mit sicherem Login, individuellem Workout-Generator, Session-Protokoll und Physiotherapeuten-Notizen. n8n als vollständiges Backend, Vercel als Hosting.
Warum eine Web-App?
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.
Die Idee: Eine richtige Web-App, die Patienten auf dem Handy nutzen können. Mit Login, persönlichem Workout-Plan, Fortschrittsprotokoll und einem Admin-Interface für den Physiotherapeuten – der Notizen hinterlegen und Übungen zuweisen kann.
n8n ist nicht nur ein Automatisierungstool – es kann das vollständige Backend einer Web-App sein.
Was die App kann
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.
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 |
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.
Technische Highlights
Das Projekt hatte einige interessante technische Herausforderungen. Da require() auf meiner n8n-Instanz blockiert ist, war kein klassisches Bcrypt-Hashing möglich. Lösung: HMAC-SHA256 direkt über den n8n Crypto Node – sicher, ohne externe Library.
JWT-Tokens werden von n8n ausgestellt und geprüft. Bei GET-Webhooks kommt das JWT aus dem Authorization-Header, nicht aus dem Body – ein Unterschied der am Anfang für Debugging gesorgt hat.
Das Admin-Interface läuft als separate HTML-Datei mit eigenem Login-Flow – vollständig isoliert vom Patienten-Frontend, gleiche n8n-Backend-Infrastruktur.