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_properties are 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!
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:
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!