Written with AI assistance from the source video. The video is the authority.
30:37Vercel
Log in to leave a comment
No posts yet
Notion bietet eine komfortable Benutzeroberfläche. Das ist der Grund, warum Ein-Personen-Entwickler Notion als Backend nutzen, wenn keine Zeit da ist, Server und Datenbanken separat aufzubauen. Wer diese Architektur jedoch auf Production-Ebene beibehält, stößt schnell an Grenzen. Die Notion API beschränkt alle Integrationstokens auf drei Anfragen pro Sekunde. Wird dieses Limit überschritten, treten 429- oder 529-Fehler auf.
Schon bei geringen Datenmengen wächst das Problem. Die maximal abrufbare Datenmenge liegt bei 100 Einträgen auf einmal. Paging muss manuell implementiert werden, und das Parsen verschachtelter Eigenschaftsstrukturen verkompliziert die Serverlogik. Die Eigenschaftsdatengröße pro Seite ist auf 2,5 Megabyte begrenzt. Wird dieses Limit ignoriert und der Dienst deployed, friert der Bildschirm bei hohem Nutzeraufkommen ein oder es kommt zu Datenverlusten.
Auf externe API-Aufrufe kann nicht jedes Mal gewartet werden. Eine Caching-Schicht muss vorgeschaltet werden. Durch das Caching statischer Daten in Redis oder Cloudflare KV und die regelmäßige Aktualisierung über einen Hintergrund-Worker lassen sich 80 Prozent aller API-Aufrufe lokal verarbeiten. Die Antwortzeit sinkt auf unter 200 Millisekunden.
In einem Python-Backend wird zudem ein Parser benötigt, der Notions komplexe Eigenschaften flachklopft (flattening). Notion-Antworten sind nach Typ tief verschachtelt. Es wird ein Parser erstellt, der durch das Dictionary iteriert, das Typfeld prüft, Text zu Strings zusammenfügt und bei relationalen Daten nur das ID-Array extrahiert. Erst durch diesen Vorbereitungsprozess können Frontend-Entwickler die Daten direkt und ohne eigene Parselogik nutzen.
Ändert sich in Notion eine Zeile, führt ein sofortiger API-Aufruf beim Eingang des Webhooks dazu, dass veraltete Daten zurückgegeben werden. Der Grund dafür ist eine Verzögerung bei der Indizierung. Dies führt zu verloren gegangenen Paketen oder fehlerhaften Daten.
Um dieses Problem in den Griff zu bekommen, ist eine regelmäßige Hintergrund-Wiederherstellungsroutine erforderlich. Mithilfe des Filters für das Änderungsdatum der Notion API wird der lokale Cache mit dem Zeitstempel abgeglichen. Bei Fehlern wird nach dem Exponential-Backoff-Algorithmus gewartet und ein neuer Versuch gestartet. Um die Datenintegrität nicht zu gefährden, muss eine Routine eingebaut werden, die ausschließlich Datensätze aktualisiert, die seit dem letzten Synchronisationszeitpunkt geändert wurden.
Code, bei dem der Notion Secret Key direkt im Client-Browser hinterlegt ist und Anfragen gesendet werden, ist riskant. Das Token wird offen gelegt und es treten CORS-Probleme auf. Aus diesem Grund muss eine Serverless-Middleware-Proxy dazwischen geschaltet werden.
Der Client sendet Anfragen an die Serverless-Middleware, welche das in den Server-Umgebungsvariablen versteckte Token anhängt und mit der Notion API kommuniziert. In einer Mandantenfähigkeit-Umgebung (Multi-Tenant) sollte in der Middleware eine Reverse-Permission-Tabelle eingerichtet werden, die die App-Benutzer-ID mit dem Besitzer der Notion-Seite verknüpft. Nur mit dieser Struktur lassen sich Token-Lecks verhindern und Daten sicher isolieren.