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 tiene una interfaz cómoda. Esta es la razón por la cual los desarrolladores independientes que no tienen tiempo para configurar un servidor y una base de datos por separado la usan como backend. Sin embargo, si mantienes esta estructura a nivel de producción, chocarás contra un muro rápidamente. La API de Notion impone un límite de tres solicitudes por segundo para cada token de integración. Si superas este límite, se producen errores 429 o 529.
Tan pronto como se acumulan un poco de datos, el problema se agranda. La cantidad máxima de datos que se pueden recuperar a la vez es 100. Debes implementar el procesamiento de paginación por tu cuenta, y la lógica del servidor se vuelve compleja debido al análisis de estructuras de propiedades anidadas. El tamaño de los datos de los atributos en una sola página está limitado a 2,5 megabytes. Si ignoras este límite y despliegas el servicio, la pantalla se congelará o los datos se perderán cuando se acumulen las solicitudes de los usuarios.
No puedes esperar a cada llamada de una API externa. Debes colocar una capa de caché en la parte frontal. Debes almacenar en caché los datos estáticos en Redis o Cloudflare KV y actualizarlos periódicamente con un trabajador en segundo plano para poder procesar el 80 por ciento de todas las llamadas a la API de forma local. La velocidad de respuesta cae por debajo de los 200 milisegundos.
También se necesita un analizador para aplanar las complejas propiedades de Notion en el backend de Python. Las respuestas de Notion están profundamente anidadas por tipo. Creas un analizador que recorre el diccionario para verificar el campo de tipo, combina el texto en cadenas y extrae solo la matriz de ID para los datos relacionales. Solo después de pasar por este proceso de preprocesamiento, los desarrolladores frontend pueden usar los datos directamente sin lógica de análisis.
Incluso si una fila cambia en Notion, si realizas una llamada a la API tan pronto como se recibe el webhook, se devuelven los datos antiguos. Esto se debe a que la indexación se retrasa. Es la causa de que los paquetes se pierdan o los datos se enreden.
Para solucionar este problema, se necesita una rutina periódica de recuperación en segundo plano. Utiliza el filtro de marca de tiempo de modificación de la API de Notion para comparar la caché local con la marca de tiempo. Si se produce un error, espera con un algoritmo de retroceso exponencial y vuelve a intentarlo. Debes incorporar una rutina que seleccione y actualice a la fuerza solo los registros que han cambiado desde el último punto de sincronización para que la integridad de los datos no se rompa.
El código que toma la clave secreta de Notion directamente desde el navegador del cliente y envía solicitudes es peligroso. El token queda expuesto tal cual y también surgen problemas de CORS. Esta es la razón por la cual se debe colocar un proxy de middleware serverless en el medio.
El cliente envía una solicitud al middleware serverless, y el middleware se comunica con la API de Notion adjuntando el token oculto en las variables de entorno del servidor. Si estás en un entorno multi-inquilino, debes colocar una tabla de permisos inversos en el middleware que asocie el ID de usuario de la aplicación con el propietario de la página de Notion. Solo creando esta estructura puedes prevenir accidentes por fugas de tokens y aislar los datos de forma segura.