search

splitbee / notion-api-worker

Notion as CMS with easy API access
MIT License
1.56k stars 197 forks source link

Issue query notion #64

Closed thanhlmm closed 3 years ago

thanhlmm commented 3 years ago

https://notion-api.splitbee.io/v1/page/76715632-d151-400d-8eb6-e7f1cc15ad6f

This API throw error and Idk what is the problem?

https://cuthanh.notion.site/Morphling-dApp-Tham-gia-Binance-Launchpad-76715632d151400d8eb6e7f1cc15ad6f

rylax commented 3 years ago

Experiencing the same issue.

thanhlmm commented 3 years ago

The issue is due to the Cloudflare worker limit of 50 sub requests, and the pages is more than 50 block, that's why it fail.

I have to use notion-client and react-notion-x instead

danielfalbo commented 3 years ago

Why is that request calling more than 50 subrequests? How can we debug this?

janniks commented 3 years ago

I believe the 50 subrequests are being re-sent, because syncRecordValues is currently failing. Pages that don't require a syncRecordValues are fine. Testing experimental fix here: https://experimental.vue-notion.workers.dev (a fork of notion-api-worker)

janniks commented 3 years ago

Potential fix: https://github.com/splitbee/notion-api-worker/pull/65 It seems the old body structure of syncRecordValues is not accepted any more...

janzheng commented 3 years ago

@janniks wow really good work! Thanks so for tracing and fixing the problem, @janniks! I guess the API is shifting a lot, from the Collection change to this syncRecordValues change.

I also can't believe they're just swapping out the API like this without using their API version URLs, e.g. api/v3/...

Also, if we have massive Notion pages we'll end up hitting 50 subrequest problem anyway — do you think it's worthwhile thinking about implementing a blockmap caching system on top of Workers KV or Durable Objects?

janniks commented 3 years ago

I think 50 subrequests will be enough for 99.9…% of pages. The endpoint can fetch many blocks at once and likely only needs few subrequests to fill up any missing blocks. The only problem might be blocks that include many recursively nested collections/similar (pretty unlikely to come up naturally). I believe the general logic is good enough.

Also, I noticed that the alternate (new/current) syncRecordValues body has been around for quite some time (found a few references and implementations using it). Just super weird that it suddenly disallows the previous api-worker behavior… Maybe some legacy cleanup happening at Notion.