Hallo zusammen,
kurze Vorstellung eines Side-Projects: Ha(e)ltBis – eine reine Web-App, läuft direkt im Browser unter https://haltbis.de/app/, ohne Installer, ohne Store, ohne Pflicht-Account.
Persistenz: IndexedDB (Dexie) im Browser – Vorrat, Rezepte, Einkaufsliste, Settings und Backups liegen client-side. Kein zentraler User-Datenspeicher auf meiner Seite; optionaler Traffic nur bei expliziten Aktionen (OFF-Suche, Rezeptimport, Übersetzung).
Handbuch + PDF: Handbuch + PDF
Feedback/Bugs gerne hier im Thread oder Feedback/Bugs
KURZBESCHREIBUNG
Ha(e)ltBis = Speisekammer-Tool für MHD, Vorrat und Rezept-Matching. Name = „hält bis …“. Zielgruppe eigentlich jeder Haushalt – technisch aber bewusst offline-first & privacy-by-architecture.
ARCHITEKTUR (für ITler)
Deployment Statische Site + SPA, keine Installation nötig – URL öffnen reicht
Datenhaltung IndexedDB im Browser (Dexie), kein Backend-DB für Userdaten
Session/Auth Kein Login, kein JWT, kein Server-Session
Sync Keine Cloud-Sync – JSON-Export/Import für Gerätewechsel
Offline Vorrat, gespeicherte Rezepte, Matching, Einkaufsliste, Settings ohne Netz
Online nur on-demand REST-Calls zu OFF, TheMealDB, RecipeRadar, Forkify, MyMemory, Marktguru – nur wenn der User sucht/importiert
Stack React 19, TypeScript, Vite, React Router, Dexie
Optional PWA „Add to Home Screen“ möglich – kein Muss, rein optional
Wichtig: Browser-Cache/Storage-Löschung = Daten weg. Deshalb JSON-Backup in den Settings – bewusst so designt, kein versteckter Cloud-Fallback.
FUNKTIONAL (technisch relevant)
• Home: MHD-Ampel, Stat-Tiles, „Heute kochen“ (Top-3 aus Matching), Wochen-Hinweis
• Vorrat: Filter/Suche, Kategorien, Lagerorte, Nutri-Score, Barcode via OFF
• Matching-Engine: client-side gegen lokalen Bestand + Einkaufsliste
• Parallele OFF-Suche: mehrere Endpoints, Merge im Client, paginiert (20/Seite)
• DB-Wartung in Settings: Tabellengröße, Cache-Shrink (OFF, Rezeptbilder, Search-Caches), IndexedDB-Compaction
• F1-Kontext-Hilfe: statische Hilfetexte pro Route, lokal, kein Helpdesk-Ticket-System
• i18n: DE/EN, gleicher Build
WAS BEWUSST NICHT DRIN IST
• Kein SaaS-Abo
• Kein Telemetrie-Account
• Kein „wir laden euren Vorrat zur besseren KI hoch“
• Kein erzwungenes App-Store-Deployment
EXTERNE ABHÄNGIGKEITEN (nur bei User-Aktion)
• Open Food Facts – Produktsuche/Barcode
• TheMealDB / RecipeRadar / Forkify – Rezeptimport
• MyMemory – optionale DE↔EN-Übersetzung
• Marktguru – optional, PLZ-basiert (DE)
Cross-Source-Contribution zurück an Quellen falls aktiviert: opt-in, default off.
LINKS
App: App
Docs: Handbuch
PDF: Handbuch PDF
Datenschutz: Datenschutz
FEEDBACK GESUCHT
Interessiert mich besonders aus IT-Sicht:
• IndexedDB-Verhalten über Browser hinweg (Chrome/Firefox/Safari)
• Performance bei größerem Vorrat (>500 Items)
• Edge Cases: Private Mode, Storage-Quota, Cache-Clear
• Sinnvolle Ergänzungen ohne Cloud-Zwang?
Danke – gern technisch diskutieren.
kurze Vorstellung eines Side-Projects: Ha(e)ltBis – eine reine Web-App, läuft direkt im Browser unter https://haltbis.de/app/, ohne Installer, ohne Store, ohne Pflicht-Account.
Persistenz: IndexedDB (Dexie) im Browser – Vorrat, Rezepte, Einkaufsliste, Settings und Backups liegen client-side. Kein zentraler User-Datenspeicher auf meiner Seite; optionaler Traffic nur bei expliziten Aktionen (OFF-Suche, Rezeptimport, Übersetzung).
Handbuch + PDF: Handbuch + PDF
Feedback/Bugs gerne hier im Thread oder Feedback/Bugs
KURZBESCHREIBUNG
Ha(e)ltBis = Speisekammer-Tool für MHD, Vorrat und Rezept-Matching. Name = „hält bis …“. Zielgruppe eigentlich jeder Haushalt – technisch aber bewusst offline-first & privacy-by-architecture.
ARCHITEKTUR (für ITler)
Deployment Statische Site + SPA, keine Installation nötig – URL öffnen reicht
Datenhaltung IndexedDB im Browser (Dexie), kein Backend-DB für Userdaten
Session/Auth Kein Login, kein JWT, kein Server-Session
Sync Keine Cloud-Sync – JSON-Export/Import für Gerätewechsel
Offline Vorrat, gespeicherte Rezepte, Matching, Einkaufsliste, Settings ohne Netz
Online nur on-demand REST-Calls zu OFF, TheMealDB, RecipeRadar, Forkify, MyMemory, Marktguru – nur wenn der User sucht/importiert
Stack React 19, TypeScript, Vite, React Router, Dexie
Optional PWA „Add to Home Screen“ möglich – kein Muss, rein optional
Wichtig: Browser-Cache/Storage-Löschung = Daten weg. Deshalb JSON-Backup in den Settings – bewusst so designt, kein versteckter Cloud-Fallback.
FUNKTIONAL (technisch relevant)
• Home: MHD-Ampel, Stat-Tiles, „Heute kochen“ (Top-3 aus Matching), Wochen-Hinweis
• Vorrat: Filter/Suche, Kategorien, Lagerorte, Nutri-Score, Barcode via OFF
• Matching-Engine: client-side gegen lokalen Bestand + Einkaufsliste
• Parallele OFF-Suche: mehrere Endpoints, Merge im Client, paginiert (20/Seite)
• DB-Wartung in Settings: Tabellengröße, Cache-Shrink (OFF, Rezeptbilder, Search-Caches), IndexedDB-Compaction
• F1-Kontext-Hilfe: statische Hilfetexte pro Route, lokal, kein Helpdesk-Ticket-System
• i18n: DE/EN, gleicher Build
WAS BEWUSST NICHT DRIN IST
• Kein SaaS-Abo
• Kein Telemetrie-Account
• Kein „wir laden euren Vorrat zur besseren KI hoch“
• Kein erzwungenes App-Store-Deployment
EXTERNE ABHÄNGIGKEITEN (nur bei User-Aktion)
• Open Food Facts – Produktsuche/Barcode
• TheMealDB / RecipeRadar / Forkify – Rezeptimport
• MyMemory – optionale DE↔EN-Übersetzung
• Marktguru – optional, PLZ-basiert (DE)
Cross-Source-Contribution zurück an Quellen falls aktiviert: opt-in, default off.
LINKS
App: App
Docs: Handbuch
PDF: Handbuch PDF
Datenschutz: Datenschutz
FEEDBACK GESUCHT
Interessiert mich besonders aus IT-Sicht:
• IndexedDB-Verhalten über Browser hinweg (Chrome/Firefox/Safari)
• Performance bei größerem Vorrat (>500 Items)
• Edge Cases: Private Mode, Storage-Quota, Cache-Clear
• Sinnvolle Ergänzungen ohne Cloud-Zwang?
Danke – gern technisch diskutieren.
.
.