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 offre une interface confortable. C'est la raison pour laquelle un développeur solo choisit d'utiliser Notion comme backend lorsqu'il n'a pas le temps de configurer un serveur et une base de données séparés. Cependant, maintenir cette structure en environnement de production se heurte rapidement à un mur. L'API Notion impose une limite de 3 requêtes par seconde pour chaque jeton d'intégration. Au-delà de cette limite, des erreurs 429 ou 529 sont renvoyées.
Le problème s'amplifie dès que les données s'accumulent légèrement. Le nombre maximal de données récupérables en une seule fois est de 100. La pagination doit être implémentée manuellement, et la logique du serveur devient complexe en raison de l'analyse des structures de propriétés imbriquées. La taille des données attributaires pour une seule page est limitée à 2,5 mégaoctets. Ignorer cette limite lors du déploiement d'un service entraîne des gels d'écran ou des pertes de données lorsque les requêtes des utilisateurs affluent.
Il est impossible d'attendre chaque appel d'API externe à chaque fois. Une couche de mise en cache doit être placée en amont. La mise en cache des données statiques dans Redis ou Cloudflare KV, actualisées périodiquement par un travailleur d'arrière-plan, permet de traiter 80 pour cent des appels API totaux localement. La vitesse de réponse chute en deçà de 200 millisecondes.
Un analyseur capable d'aplanir les propriétés complexes de Notion dans le backend Python est également nécessaire. Les réponses de Notion sont profondément imbriquées par type. Il faut créer un analyseur qui parcourt le dictionnaire pour vérifier le champ de type, combine le texte en chaînes de caractères et extrait uniquement les tableaux d'ID pour les données relationnelles. C'est seulement après ce processus de prétraitement que les développeurs frontend peuvent exploiter directement les données sans logique d'analyse.
Même lorsqu'une ligne est modifiée dans Notion, interroger l'API dès la réception du webhook renvoie les anciennes données. Cela est dû au retard d'indexation, qui provoque la perte de paquets ou l'enchevêtrement des données.
Pour résoudre ce problème, une routine de récupération périodique en arrière-plan est indispensable. Le filtre de date de modification de l'API Notion est utilisé pour comparer le cache local et l'horodatage. En cas d'erreur, le système attend en appliquant un algorithme de backoff exponentiel avant de réessayer. Il est nécessaire d'intégrer une routine qui sélectionne et met à jour de force uniquement les enregistrements modifiés depuis le dernier point de synchronisation afin d'éviter toute altération de l'intégrité des données.
Le code qui envoie des requêtes en incluant directement la clé secrète Notion dans le navigateur du client est dangereux. Le token est exposé tel quel et des problèmes de CORS surviennent. C'est pourquoi un proxy middleware sans serveur doit être placé au milieu.
Le client envoie des requêtes au middleware sans serveur, et ce dernier communique avec l'API Notion en y attachant le jeton masqué dans les variables d'environnement du serveur. Dans un environnement multilocataire, une table de contre-autorisation mappant l'ID utilisateur de l'application et le propriétaire de la page Notion doit être placée dans le middleware. C'est la création de cette structure qui permet de bloquer les accidents de fuite de jetons et d'isoler les données en toute sécurité.