Instalytics
Wer entfolgt mir, und wann?
Instagram bietet keine Schnittstelle für Follower-Historie. Wer wissen will, wer entfolgt ist, muss die Daten selbst über die Zeit erfassen, für mehrere Nutzer gleichzeitig und ohne dass Zugangsdaten irgendwo im Klartext liegen.
Fakten
- Rolle
- Alles: Frontend, Backend, Datenbank, Deploy
- Status
- Nie öffentlich gestartet
- Sprachen
- TypeScript, Python, SQL
Das Problem
Die offizielle Graph API liefert nur aktuelle Zahlen, keine Historie und keine Follower-Listen. Wer eine Historie will, muss selbst regelmäßig Momentaufnahmen speichern und vergleichen.
Die eigentliche Schwierigkeit war nicht das Auslesen, sondern die Sicherheit. Eine Instagram-Session ist faktisch ein Login. Sie darf nie im Browser landen und nicht im Klartext in einer Datenbank stehen.
Architektur
- BrowserNext.js, sieht nie Instagram-Daten
- BFFRoute Handler, prüft die NextAuth-Session
- FastAPInur mit Internal-Secret erreichbar
- PostgreSQLSnapshots + verschlüsselte Sessions
Entscheidungen
Backend-for-Frontend statt direktem API-Zugriff
Der Browser spricht ausschließlich mit Next.js. Die FastAPI-Instanz nimmt nur Anfragen mit einem geteilten Internal-Secret an. Dadurch führt kein Weg von außen direkt an den Instagram-Layer, auch nicht mit einem gültigen Nutzer-Token. Der Preis: ein zusätzlicher Netzwerk-Hop, den ich absichern muss.
AES-256-GCM für Sessions im Ruhezustand
Session-Daten werden mit einem 32-Byte-Schlüssel aus der Umgebung verschlüsselt gespeichert, nicht gehasht, denn sie müssen wieder benutzbar sein. GCM statt CBC, weil es Authentifizierung mitbringt: manipulierte Daten fallen beim Entschlüsseln auf, statt still falsch weiterzulaufen.
Zwei Laufzeiten statt einer
Next.js auf Vercel, FastAPI auf Railway. Der Instagram-Client braucht einen langlebigen Python-Prozess mit eigenem Zustand. Das passt nicht in eine Serverless-Funktion mit Timeout. Zwei Deployments sind mehr Aufwand, aber die Alternative wäre gewesen, den Client in eine Umgebung zu zwingen, für die er nicht gebaut ist.
Durchgehend asynchron
SQLAlchemy mit asyncpg statt des synchronen Treibers. Die Arbeit ist fast vollständig I/O-gebunden: warten auf Instagram, warten auf Postgres. Synchron hätte jeder wartende Nutzer einen Worker blockiert.
Ergebnis
Fertige Multi-User-App mit eigener Registrierung, Onboarding, Dashboard und Verlaufsansicht.
Jeder Nutzer sieht ausschließlich eigene Snapshots, durchgesetzt in der Datenbankabfrage, nicht nur in der Oberfläche.
Bewusst nie öffentlich gestartet: das Auslesen von Follower-Listen widerspricht den Nutzungsbedingungen von Instagram. Das Projekt lief privat auf meinem eigenen Konto. Technisch war es die größte Lernstrecke. Deshalb steht es hier, mit dieser Einschränkung offen dazugeschrieben.
Was ich gelernt habe
Wo Geheimnisse liegen dürfen und wo nicht. „Im Backend“ ist als Antwort zu ungenau.
Datenbankmigrationen sind kein Detail. Die erste falsche Migration war ein sehr lehrreicher Abend.
Und: vor dem Bauen prüfen, ob man das Produkt überhaupt veröffentlichen darf.