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 has a convenient interface. This is why solo developers use Notion as a backend when they don't have time to build a separate server and database. However, maintaining this structure at a production level quickly hits a wall. The Notion API imposes a rate limit of 3 requests per second for every integration token. Exceeding this limit results in 429 or 529 errors.
Even with a small amount of data, problems mount up. The maximum number of items you can retrieve at once is 100. You have to implement pagination manually, and server logic becomes complicated as you parse nested property structures. The property data size limit for a single page is 2.5 megabytes. If you deploy a service ignoring these limits, screens will freeze or data will go missing when user traffic spikes.
Waiting for external API calls every time is not an option. You need to place a caching layer in front. By caching static data in Redis or Cloudflare KV and periodically updating it with a background worker, you can handle 80 percent of total API calls locally. Response times drop below 200 milliseconds.
A parser that flattens Notion's complex properties in a Python backend is also required. Notion responses are deeply nested by type. You need to create a parser that traverses dictionaries, checks type fields, combines text into strings, and extracts arrays of IDs for relational data. Only after going through this preprocessing step can frontend developers use the data directly without parsing logic.
Even if a row changes in Notion, hitting the API as soon as a webhook is received returns old data because indexing lags behind. This is the cause of lost packets and tangled data.
To tackle this problem, a periodic background recovery routine is necessary. Utilize the Notion API's last-edited time filter to compare the local cache with timestamps. If an error occurs, wait using an exponential backoff algorithm and retry. You must embed a routine that selects and forcefully updates only the records changed since the last synchronization point so that data integrity is not broken.
Code that sends requests from a client browser while holding the Notion secret key directly is dangerous. The token gets exposed as-is and CORS issues also erupt. This is why you must place a serverless middleware proxy in the middle.
The client sends requests to the serverless middleware, and the middleware attaches the token hidden in server environment variables to communicate with the Notion API. In a multi-tenant environment, you must place a reverse authorization table in the middleware that maps app user IDs to Notion page owners. Building this structure prevents token leak accidents and securely isolates data.