The project plan is to enhance existing project "gatsby-source-plone" with features that allow "gatsby develop" development server to provide up-to-date instant live previews of pages that contain data from a Plone CMS source. The aim is to enhance "gatsby-source-plone" to provide a GatsbyJS development experience matching the experience provided by "gatsby-source-filesystem" based plugins, which can create, update and delete nodes on from filesystem events.
GatsbyJS is a React-based, GraphQL powered static site generator. It creates the fastest web sites possible. It is great. With the gatsby-source-plone plugin, you can build those fast sites from content managed on Plone CMS. That is awesome. Running a GatsbyJS rebuild for a site with thousands of pages can take minutes, if not on hour, after a single change. And only after that long rebuild can the author see if their updates look cool. That's not cool.
The project plan is to enhance the existing project gatsby-source-plone with features that allow the gatsby develop development server to provide up-to-date, instant, live previews of pages with data from a Plone CMS source. This makes it possible to use gatsby develop to provide a preview of the changes and only run the static site rebuild when the author is ready. This would make gatsby-source-plone the best available CMS plugin for GatsbyJS.
GatsbyJS has the required API, but it is not well documented nor seem to be used widely outside gatsby-source-filesystem, which already provides similar development experience with, for example, gatsby-starter-blog.
The solution probably includes implementing a small API server inside gatsby-source-plone that receives cache invalidation requests from the source Plone site.
Initial solution could simply poll the configured Plone site for every few seconds and smartly update affected GatsbyJS nodes (content nodes and their, breadcrumbs and navigation nodes) and pages. Because this cannot detect deleted pages, the eventual solution requires support for a configurable websocket endpoint where the plugin could listen for updates. During GSOC this websocket endpoint could be simulated with a custom NodeJS implementation.
Pull requests to gatsby-source-plone to implement and document the planned feature.