-
Notifications
You must be signed in to change notification settings - Fork 1
Description
First of all, thank you for creating such a great project.
I've really enjoyed using Notion Presso, but I had one question while working with it, so I’m leaving this issue.
Why I Decided to Use Notion Presso
Previously, I used a similar project called morethan-log, which allows deploying a Notion page as a blog.
One of the best features of that project, in my opinion, was its "dynamic sync" capability — once the page was deployed, any updates made in the Notion DB were automatically reflected without re-deploying.
However, I moved away from morethan-log and chose Notion Presso because morethan-log forced users to follow a specific Notion DB structure, which made it hard to use flexibly.
What I love about Notion Presso is that it doesn't enforce a strict Notion structure, giving me full control over the page design.
That said, having to edit the code and redeploy every time I update the Notion page feels a bit inconvenient.
Regarding Dynamic Sync Feature
This leads me to my main question: Why did you choose JSON as the source of truth instead of fetching data directly from Notion at runtime?
Here are my guesses:
- Without using a DB or some persistent state, you’d have to access each Notion page individually. Once deployed, updating which pages to fetch dynamically would be difficult unless hard-coded.
- Due to Notion’s data structure (which is similar to a NoSQL DB), many
additional_propertiesare embedded in the API response. Serializing to JSON might have been a way to prevent type-related issues during development and runtime.
I’d love to know if these assumptions are correct — or if there were any other technical reasons behind this choice.
Additionally, if it’s technically feasible, I’d like to suggest adding a dynamic sync mode, where Notion pages are fetched and rendered dynamically without needing to modify and redeploy the code every time.
Looking forward to your insights!