mirror of
https://github.com/Memo-2023/mana-monorepo.git
synced 2026-05-21 00:06:42 +02:00
ee42b6cc76
## New Features ### Network Graph Visualization (Contacts, Calendar, Todo) - D3.js force simulation for physics-based layout - Zoom & pan with mouse/touchpad - Keyboard shortcuts: +/- zoom, 0 reset, Esc deselect, / search, F focus - Filtering by tags, company/location/project, connection strength - Shared components in @manacore/shared-ui ### Central Tags API (mana-core-auth) - CRUD endpoints for tags - Schema: tags table with userId, name, color, app - Shared tag components in @manacore/shared-ui ### Custom Themes System - Theme editor with live preview and color picker - Community theme gallery - Theme sharing (public, unlisted, private) - Backend API in mana-core-auth ### Todo App Extensions - Glass-pill design for task input and items - Settings page with 20+ preferences - Task edit modal with inline editing - Statistics page with visualizations - PWA support with offline capabilities - Multiple kanban boards ### Contacts App Features - Duplicate detection - Photo upload - Batch operations - Enhanced favorites page with multiple view modes - Alphabet view improvements - Search modal ### Help System - @manacore/shared-help-content - @manacore/shared-help-ui - @manacore/shared-help-types ### Other Features - Themes page for all apps - Referral system frontend - CommandBar (global search) - Skeleton loaders - Settings page improvements ## Bug Fixes - Network graph simulation initialization - Database schema TEXT for user_id columns (Better Auth compatibility) - Various styling fixes ## Documentation - Daily report for 2025-12-10 - CI/CD deployment guide 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
513 lines
10 KiB
Markdown
513 lines
10 KiB
Markdown
Redis Cache für uLoad - Was bringt es
|
|
wirklich?
|
|
|
|
Das Hauptproblem aktuell
|
|
|
|
Jedes Mal wenn jemand einen deiner
|
|
Short-Links klickt, muss deine App:
|
|
|
|
1. PocketBase fragen "welche URL gehört zu
|
|
diesem Short-Code?"
|
|
2. Warten bis PocketBase in der SQLite
|
|
Datei sucht
|
|
3. Antwort zurückgeben und weiterleiten
|
|
|
|
Das dauert 50-100ms pro Klick. Bei vielen
|
|
Klicks wird PocketBase zum Flaschenhals.
|
|
|
|
Was Redis ändern würde
|
|
|
|
Redis ist wie ein ultra-schneller
|
|
Zwischenspeicher. Statt jedes Mal
|
|
PocketBase zu fragen, schaust du erst in
|
|
Redis nach. Das ist 20-50x schneller!
|
|
|
|
Die 3 größten Verbesserungen
|
|
|
|
1. Link-Redirects (90% deines Traffics)
|
|
|
|
Problem: Jeder Klick = PocketBase Query =
|
|
langsam
|
|
Lösung: Beliebte Links werden in Redis
|
|
gespeichert
|
|
|
|
Beispiel:
|
|
|
|
- Dein Link "ulo.ad/meeting" wird 100x am
|
|
Tag geklickt
|
|
- Ohne Redis: 100x PocketBase Query (100x
|
|
80ms = 8 Sekunden Serverzeit)
|
|
- Mit Redis: 1x PocketBase + 99x Redis (1x
|
|
80ms + 99x 2ms = 0.28 Sekunden)
|
|
|
|
Ergebnis: 30x schneller, 95% weniger
|
|
PocketBase Last
|
|
|
|
2. Dashboard Performance
|
|
|
|
Problem: Dein Dashboard lädt alle deine
|
|
Links aus PocketBase
|
|
Lösung: Links werden für 5 Minuten gecacht
|
|
|
|
Beispiel:
|
|
|
|
- Du hast 50 Links, checkst Dashboard 20x
|
|
am Tag
|
|
- Ohne Redis: 20x komplette Liste laden =
|
|
langsam
|
|
- Mit Redis: 1x laden, 19x aus Cache =
|
|
blitzschnell
|
|
|
|
3. Analytics & Statistiken
|
|
|
|
Problem: Click-Zahlen berechnen ist langsam
|
|
(viele Datenbankabfragen)
|
|
Lösung: Statistiken werden live berechnet
|
|
und gecacht
|
|
|
|
Beispiel:
|
|
|
|
- "Zeige Clicks der letzten 7 Tage" braucht
|
|
normalerweise komplizierte Queries
|
|
- Mit Redis: Zahlen werden kontinuierlich
|
|
aktualisiert, sofort verfügbar
|
|
|
|
Rate Limiting Verbesserung
|
|
|
|
Aktuell: Dein Rate Limiter vergisst alles
|
|
bei Server-Restart
|
|
Mit Redis: Rate Limits bleiben bestehen,
|
|
auch über Restarts hinweg
|
|
|
|
Das bedeutet: Angreifer können nicht mehr
|
|
durch Server-Restart deine Limits umgehen.
|
|
|
|
Konkrete Zahlen für dich
|
|
|
|
Traffic-Verteilung schätzen:
|
|
|
|
- 90% Redirects (Leute klicken deine Links)
|
|
- 8% Dashboard/API (Du managst deine Links)
|
|
|
|
- 2% Sonstiges (Login, Settings, etc.)
|
|
|
|
Performance ohne Redis:
|
|
|
|
- Redirect: 80ms durchschnittlich
|
|
- Dashboard laden: 300ms
|
|
- Bei 1000 Klicks/Tag: PocketBase ist
|
|
gestresst
|
|
|
|
Performance mit Redis:
|
|
|
|
- Redirect: 5ms (95% aus Cache)
|
|
- Dashboard laden: 20ms (meist aus Cache)
|
|
- Bei 10.000 Klicks/Tag: PocketBase
|
|
entspannt
|
|
|
|
Wann merkst du den Unterschied?
|
|
|
|
Sofort spürbar:
|
|
|
|
- Dashboard lädt viel schneller (besonders
|
|
mit vielen Links)
|
|
- Redirects sind blitzschnell
|
|
- Analytics laden sofort statt zu "denken"
|
|
|
|
Bei mehr Traffic:
|
|
|
|
- Server bleibt entspannt auch bei
|
|
Viral-Links
|
|
- Keine Timeouts mehr bei hoher Last
|
|
- PocketBase überlastet nicht
|
|
|
|
Skalierung:
|
|
|
|
- Ohne Redis: ~500 Redirects/Minute machbar
|
|
- Mit Redis: ~5000+ Redirects/Minute
|
|
machbar
|
|
|
|
Kosten vs. Nutzen
|
|
|
|
Option 1: Kostenlos starten
|
|
|
|
- Upstash Redis (10k Commands/Tag gratis)
|
|
- Perfekt zum Testen
|
|
- Upgrade wenn nötig
|
|
|
|
Option 2: Minimale Kosten
|
|
|
|
- €5-15/Monat für ordentlichen Redis
|
|
- Dafür 10x bessere Performance
|
|
|
|
Was du sparst:
|
|
|
|
- Weniger Server-Stress = längere
|
|
Hardware-Lebensdauer
|
|
- Bessere User Experience = mehr zufriedene
|
|
Nutzer
|
|
- Skalierung möglich ohne neuen Server
|
|
|
|
Die Realität für uLoad
|
|
|
|
Jetzt: Bei 100 Klicks gleichzeitig würde
|
|
dein Server wahrscheinlich strugglen
|
|
Mit Redis: Bei 1000 Klicks gleichzeitig
|
|
läuft alles smooth
|
|
|
|
Jetzt: Dashboard mit 100 Links braucht eine
|
|
Sekunde zum Laden
|
|
Mit Redis: Dashboard lädt in 0.1 Sekunden
|
|
|
|
Jetzt: Click-Statistiken berechnen dauert
|
|
ewig
|
|
Mit Redis: Statistiken sind immer aktuell
|
|
und sofort da
|
|
|
|
Meine ehrliche Einschätzung
|
|
|
|
Für uLoad ist Redis ein No-Brainer:
|
|
|
|
- Minimaler Aufwand (2-3 Tage Setup)
|
|
- Maximaler Nutzen (10x Performance)
|
|
- Kosten fast null (kann gratis starten)
|
|
|
|
Der größte Gewinn ist bei Redirects - das
|
|
ist dein Kernfeature und wird damit
|
|
ultra-schnell. Plus du bist ready für
|
|
Viral-Links die plötzlich 1000x geklickt
|
|
werden.
|
|
|
|
Bottom Line: Redis macht aus deinem "hobby
|
|
project" eine professionelle, skalierbare
|
|
Anwendung für praktisch null Zusatzkosten.
|
|
Das ist vermutlich das beste ROI was du
|
|
kriegen kannst! 🎯
|
|
|
|
> super danke. wir können ja reddis auch
|
|
> einfach auf unserem hetzter vps mit coolify
|
|
> hochfahren oder? was brucht es an
|
|
> reccourcen? was mus man beachten? sollte es
|
|
> lieber auf einem adnere server liegen?
|
|
> sollte es im gleichen project in coolify
|
|
> liegen?
|
|
|
|
⏺ Redis auf Hetzner VPS mit Coolify -
|
|
Perfekte Idee!
|
|
|
|
Ja, absolut machbar und sinnvoll!
|
|
|
|
Dein aktueller Hetzner VPS kann Redis
|
|
problemlos mit hosten. Coolify macht das
|
|
super einfach.
|
|
|
|
Resource-Bedarf von Redis
|
|
|
|
RAM (das Wichtigste):
|
|
|
|
- Redis lädt alles in den RAM - das macht
|
|
es so schnell
|
|
- Für uLoad geschätzt: 50-200MB RAM
|
|
- Link Cache: ~1MB pro 10.000 Links
|
|
- Session Cache: ~10MB für 1000 aktive
|
|
User
|
|
- Analytics: ~20-50MB je nach History
|
|
- Rate Limiting: ~5-10MB
|
|
|
|
CPU:
|
|
|
|
- Minimal! Redis ist extrem CPU-effizient
|
|
- Für uLoad: <1% CPU Auslastung
|
|
- Nur bei komplexen Operationen mehr
|
|
|
|
Disk:
|
|
|
|
- Persistence: 100-500MB für Dumps
|
|
- Logs: 10-50MB
|
|
- Total: <1GB
|
|
|
|
Dein CX21 VPS Kapazität:
|
|
|
|
- RAM: 8GB total, aktuell ~2GB verwendet →
|
|
6GB frei!
|
|
- CPU: 2 vCPUs, aktuell <20% → Mehr als
|
|
genug
|
|
- Disk: 40GB, Redis braucht <1GB → Kein
|
|
Problem
|
|
|
|
Fazit: Dein Server kann Redis locker
|
|
verkraften! 🎯
|
|
|
|
Coolify Setup - zwei Optionen
|
|
|
|
Option 1: Gleiches Projekt (Empfohlen für
|
|
Start)
|
|
|
|
# Einfach Redis Service zu deinem
|
|
|
|
bestehenden docker-compose hinzufügen
|
|
services:
|
|
app: # Deine bestehende App
|
|
|
|
redis:
|
|
image: redis:7-alpine
|
|
command: redis-server --appendonly yes
|
|
|
|
--maxmemory 512mb --maxmemory-policy
|
|
allkeys-lru
|
|
volumes: - redis-data:/data
|
|
restart: unless-stopped
|
|
healthcheck:
|
|
test: ["CMD", "redis-cli", "ping"]
|
|
interval: 30s
|
|
timeout: 10s
|
|
retries: 3
|
|
|
|
volumes:
|
|
redis-data:
|
|
|
|
Option 2: Separates Projekt in Coolify
|
|
|
|
- Vorteil: Unabhängiges Deployment von
|
|
deiner App
|
|
- Nachteil: Etwas komplizierter zu
|
|
verwalten
|
|
|
|
Ich empfehle Option 1 - Redis ist so
|
|
stabil, das macht keinen Unterschied.
|
|
|
|
Coolify Konfiguration
|
|
|
|
Redis Environment Variables:
|
|
|
|
# In Coolify für Redis Service setzen:
|
|
|
|
REDIS_PASSWORD=dein-sicheres-passwort-hier
|
|
REDIS_MAXMEMORY=512mb
|
|
REDIS_SAVE_INTERVAL=900 # Auto-save alle
|
|
15 Min
|
|
|
|
Deine App erweitern:
|
|
|
|
# Environment Variable für deine App
|
|
|
|
hinzufügen:
|
|
REDIS_URL=redis://:dein-passwort@redis:6379
|
|
|
|
Networking in Coolify:
|
|
|
|
- Redis und App sind automatisch im
|
|
gleichen Docker Network
|
|
- Deine App kann Redis über redis:6379
|
|
erreichen
|
|
- Kein Port nach außen öffnen nötig
|
|
(Sicherheit!)
|
|
|
|
Wichtige Redis Konfiguration
|
|
|
|
Memory Management:
|
|
|
|
# Redis Config (über Command Parameter):
|
|
|
|
--maxmemory 512mb # Begrenze RAM Nutzung
|
|
--maxmemory-policy allkeys-lru # Alte Keys
|
|
löschen wenn voll
|
|
|
|
Persistence:
|
|
|
|
# Zwei Optionen kombinieren:
|
|
|
|
--appendonly yes # AOF für Durability
|
|
--save 900 1 # RDB Snapshot alle 15
|
|
Min
|
|
|
|
Security:
|
|
|
|
# Passwort setzen:
|
|
|
|
--requirepass dein-starkes-passwort
|
|
|
|
# Gefährliche Commands deaktivieren:
|
|
|
|
--rename-command FLUSHDB ""
|
|
--rename-command FLUSHALL ""
|
|
|
|
Monitoring in Coolify
|
|
|
|
Redis Logs überwachen:
|
|
|
|
- Coolify zeigt Redis Logs in Echtzeit
|
|
- Achte auf Memory Warnings
|
|
- Connection Errors beobachten
|
|
|
|
Wichtige Redis Metriken:
|
|
|
|
# Commands zum Monitoring (über redis-cli):
|
|
|
|
INFO memory # RAM Nutzung
|
|
INFO stats # Operations/sec
|
|
INFO clients # Verbindungen
|
|
MONITOR # Live Commands (nur
|
|
zum Debugging!)
|
|
|
|
Backup Strategy
|
|
|
|
Automatische Redis Backups:
|
|
|
|
# Script in deinem Container:
|
|
|
|
#!/bin/bash
|
|
|
|
# redis-backup.sh
|
|
|
|
DATE=$(date +%Y%m%d_%H%M%S)
|
|
redis-cli --rdb
|
|
/backups/redis_backup_$DATE.rdb
|
|
|
|
# In Coolify als Cron Job alle 6 Stunden
|
|
|
|
Oder einfacher:
|
|
|
|
# Volume Mount für Persistence reicht:
|
|
|
|
volumes: - redis-data:/data # Redis saved
|
|
automatisch hier
|
|
|
|
Separater Server - wann sinnvoll?
|
|
|
|
Bleib bei einem Server wenn:
|
|
|
|
- <10.000 Requests/Tag (definitiv dein
|
|
Fall)
|
|
- <1000 gleichzeitige User
|
|
- Development/Early Stage (definitiv dein
|
|
Fall)
|
|
|
|
Separater Redis Server nur bei:
|
|
|
|
- > 100.000 Requests/Tag
|
|
- Multi-Region Setup
|
|
- Dedicated Redis Cluster mit Failover
|
|
|
|
Für uLoad: Ein Server reicht völlig!
|
|
|
|
Coolify Deployment Steps
|
|
|
|
1. Docker Compose erweitern:
|
|
|
|
# Zu deiner bestehenden docker-compose.yml
|
|
|
|
hinzufügen:
|
|
services: # ... deine bestehenden Services
|
|
|
|
redis:
|
|
image: redis:7-alpine
|
|
command: >
|
|
redis-server
|
|
--appendonly yes
|
|
--maxmemory 512mb
|
|
--maxmemory-policy allkeys-lru
|
|
--requirepass ${REDIS_PASSWORD}
|
|
volumes:
|
|
- redis-data:/data
|
|
restart: unless-stopped
|
|
networks:
|
|
- app-network
|
|
healthcheck:
|
|
test: ["CMD", "redis-cli", "-a",
|
|
|
|
"${REDIS_PASSWORD}", "ping"]
|
|
interval: 30s
|
|
timeout: 10s
|
|
retries: 3
|
|
|
|
volumes:
|
|
redis-data:
|
|
|
|
networks:
|
|
app-network:
|
|
driver: bridge
|
|
|
|
2. Environment Variables in Coolify:
|
|
|
|
# Für Redis:
|
|
|
|
REDIS_PASSWORD=SuperSecurePassword123!
|
|
|
|
# Für deine App:
|
|
|
|
REDIS_URL=redis://:SuperSecurePassword123!@
|
|
redis:6379
|
|
|
|
3. Deploy & Test:
|
|
|
|
- Coolify deployed automatisch
|
|
- Teste Connection aus deiner App
|
|
- Check Redis Logs für Errors
|
|
|
|
Was beachten?
|
|
|
|
Security:
|
|
|
|
- Passwort setzen (Redis hat standardmäßig
|
|
keins!)
|
|
- Port nicht öffentlich machen (nur intern)
|
|
- Command Renaming für gefährliche Commands
|
|
|
|
Performance:
|
|
|
|
- Memory Limit setzen (512MB reicht für
|
|
Start)
|
|
- LRU Policy aktivieren (alte Keys werden
|
|
gelöscht)
|
|
- Connection Pooling in deiner App
|
|
|
|
Monitoring:
|
|
|
|
- Redis Logs in Coolify beobachten
|
|
- Memory Usage im Auge behalten
|
|
- Hit Rate messen (wie oft Cache getroffen
|
|
wird)
|
|
|
|
Troubleshooting
|
|
|
|
Häufige Probleme:
|
|
|
|
1. Connection refused: Redis Service nicht
|
|
gestartet
|
|
2. Auth failed: Passwort falsch oder nicht
|
|
gesetzt
|
|
3. Memory full: Maxmemory erreicht, LRU
|
|
Policy prüfen
|
|
|
|
Debug Commands:
|
|
|
|
# In Coolify Terminal (Redis Container):
|
|
|
|
redis-cli -a dein-passwort info
|
|
redis-cli -a dein-passwort ping
|
|
redis-cli -a dein-passwort client list
|
|
|
|
Meine Empfehlung
|
|
|
|
Setup für uLoad:
|
|
|
|
1. Gleicher Server (Hetzner VPS) ✅
|
|
2. Gleiches Coolify Projekt ✅
|
|
3. 512MB Memory Limit ✅
|
|
4. Passwort-geschützt ✅
|
|
5. Persistence aktiviert ✅
|
|
|
|
Vorteile:
|
|
|
|
- Einfachste Lösung
|
|
- Keine Extra-Kosten
|
|
- Latenz minimal (gleicher Server)
|
|
- Easy zu verwalten
|
|
|
|
Nachteile:
|
|
|
|
- Keine (für deine Use Case)
|
|
|
|
Redis auf deinem bestehenden Setup ist der
|
|
perfekte nächste Schritt! 🚀
|