Written with AI assistance from the source video. The video is the authority.
30:37Vercel
Log in to leave a comment
No posts yet
O Notion tem uma interface prática. É por isso que desenvolvedores solo o usam como backend quando não têm tempo para construir servidores e bancos de dados separados. No entanto, manter essa estrutura em nível de produção rapidamente leva a um beco sem saída. A API do Notion impõe um limite de taxa de 3 solicitações por segundo para cada token de integração. Exceder esse limite resulta em erros 429 ou 529.
O problema se agrava assim que os dados começam a se acumular. O número máximo de dados que podem ser buscados de uma só vez é 100. A paginação precisa ser implementada manualmente, e a lógica do servidor se torna complexa devido à análise de estruturas de propriedades aninhadas. O limite de tamanho para os dados de atributos em uma única página é de 2,5 megabytes. Ignorar esses limites ao implantar um serviço faz com que a interface trave ou dados sejam perdidos quando as solicitações dos usuários aumentam.
Não é viável esperar por chamadas de API externas o tempo todo. Uma camada de cache deve ser colocada na frente. Armazenar dados estáticos em cache no Redis ou Cloudflare KV e atualizá-los periodicamente com um worker em segundo plano permite que 80% de todas as chamadas de API sejam tratadas localmente. O tempo de resposta cai para menos de 200 milissegundos.
Também é necessário um parser no backend Python para achatar as propriedades complexas do Notion. As respostas do Notion são profundamente aninhadas por tipo. Cria-se um parser que percorre o dicionário para verificar o campo de tipo, combina texto em strings e extrai apenas arrays de IDs para dados relacionais. É preciso passar por esse processo de pré-processamento para que os desenvolvedores frontend possam usar os dados imediatamente sem lógica de análise.
Mesmo que uma linha mude no Notion, chamar a API assim que um webhook é recebido faz com que dados antigos sejam retornados. Isso ocorre porque a indexação sofre atrasos. Essa é a causa de pacotes perdidos ou dados corrompidos.
Para resolver esse problema, é necessária uma rotina periódica de recuperação em segundo plano. O filtro de carimbo de data/hora de modificação da API do Notion é usado para comparar o cache local com os carimbos de data/hora. Se ocorrer um erro, o sistema aguarda usando um algoritmo de backoff exponencial antes de tentar novamente. Uma rotina que atualiza à força apenas os registros alterados desde a última sincronização deve ser implementada para evitar que a integridade dos dados seja quebrada.
Código que envia solicitações diretamente do navegador do cliente segurando a chave secreta do Notion é perigoso. O token fica exposto e problemas de CORS também ocorrem. É por isso que um proxy de middleware serverless deve ser colocado no meio.
O cliente envia solicitações para o middleware serverless, e o middleware se comunica com a API do Notion anexando o token oculto nas variáveis de ambiente do servidor. Em um ambiente multilocatário, uma tabela de permissões reversas que mapeia o ID do usuário do aplicativo e o proprietário da página do Notion deve ser colocada no middleware. Essa estrutura deve ser criada para evitar incidentes de vazamento de token e isolar dados com segurança.