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.
Implementation
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.
Skills
JavaScript (ES7), ReactJS, GatsbyJS, NodeJS. Learning and understanding gatsby-source-filesystem would be a significant part of this project.
Mentors
Asko Soukka
Aims
Pull requests to gatsby-source-plone to implement and document the planned feature.
Obviously this is ”just” a community prepare and I would welcome also other GatsbyJS related GSOC submissions. That said, I can commit myself to only mentor a single project (given accepted submission).
Not yet, but you could test yourself by trying out and learning what GitHub - gatsbyjs/gatsby-starter-blog: Gatsby starter for creating a blog does and how it works (how it uses gatsy-source-filesystem -plugin to automatically detect page changes on filesystem update pages on your gatsby site development preview (launched with gatsby develop).
@datakurre My dream is still bringing Gatsby and Volto together by embedding the Volto editor in Gatsby to provide the user experience of Volto/Pastanaga with the speed, security, and frontend power of Gatsby. Though, if you think that this is too much for GSOC 2019, I don't think it makes sense to submit an additional proposal.
Having a smart and dedicated mentor like you is more important than anything else for the success of GSoC. I will only have time for one project this year and only as a secondary mentor or product owner, so I guess I will focus on Volto this year. I'd be still very much interested in the progress of this project and I am looking forward to its outcome!
@tisto Sure you can submit a proposal, but you should have more mentors. This year I need to mentor something very close to current work to keep my sanity
I still don’t understand Volto in GatsbyJS. Would you be able to give some examples?
I studied the architecture of gatsy-source-plone (GSP) and of gatsby-source-filesystem (GSP) plugins.
What GSF does is it uses chokidar which is a file watcher to watch for events and then when those events are triggered, update Gatsby source nodes.
To have similar functionality in GSP we would need to have a method to send data from Plone to the plugin without an explicit request. This method will be used to send info about changes made to Plone to GSP where we can use the gatsby api to update source nodes., much like the way GSF does it.
Since this kind of communication is not possible with REST APIs, we would need to a websocket based approach to communicate with Plone.
I have not investigated the abilities of Guillotina, but I think we should use that instead of the REST API.
Ofcourse we would need to add methods that actually send data from Plone/Guillotina to GSP on particular events (like chokidar does with files), but these can also be used for other usecases such as the one in this thread I found
All of the above points are after just a surface level inspection.
So let me know if I am thinking in the right direction or if there is a error in my understandings/assumptions.
I missed the last line on the GSoC Idea page:
"The solution probably includes implementing a small API server inside gatsby-source-plone that receives cache invalidation requests from the source Plone site."
That makes sense and could be one potential solution for this, instead of using websockets.
But websockets would work better with less overhead per-request.
@datakurre Hello mentor , I am interested to work on this Idea in GSOC 2019. I have read the docs of gatsbyJS and I am currently reading the docs of Plone/gatsby-source-plone . I have also read the Plone official documentation on docs.plone.org. I have already started implementing docs in Plone/gatsby-starter-plone of repository Plone/gatsby-source-plone sequentially.
We don't know yet, what is the best way for Plone to notify gatsby development server of the changes in content. I believe it must be done by Plone backend to ensure that the transaction for saving new version has been completed (to ensure that the gatsby development server can actually get the new version of content). But Plone backend cannot maintain long-living websocket connection to gatsby development server. Therefore we would not get the full benefits of websocket, but need to reconnect for every notification. Whatever results in most clean code
I believe, that similarly to chokidar it could be enough that the Plone backend could notify the gatsby development server (actually gatsby-source-plone) that data at certain URI has changed. Then the plugin should re-fetch all content it believes needs to be updated with Plone REST API.
If the gatsby-source-plone could provide a simple HTTP endpoint where Plone could push should notifications, we would not need any Python development during that GSOC. We already have a Plone add-on that can notify HTTP endpoints about changes: collective.webhook · PyPI
It does not, yet. Guillotina is completely different server from the current Plone releases, but the plan is to make them compatible on REST API level, so that they can share UI layer (like Volto).
@datakurre,
Hi I am Sachin Chand, a 4th year CSE undergrad studying at NIT Agartala, India, and I wanted to work for this project. I have past working experience with most of the mentioned skills except GatsbyJS.
I am interested to join this project through GSOC 2019.
My github profile link : https://github.com/crownedlake/
Hi @crownedlake! There’s still plenty of time before the application period (even the accepted organisations are published only next week). If Plone Foundation is accepted, I’d expect there to be some competition around this project idea. So, I encourage you to try it out before application period. And not necessarily with Plone, but starting with gatsby-starter-blog, because that defines the developer experience we are after.
Thanks for the reply @datakurre, I have already started with gatsby-starter-blog. I am new to plone too, do you suggest working with gasby right now only?
I suggest to try gatsby-starter-plone next, but only once you are familiar with gatsby basics to easier separate gatsby usage issues with Plone issues. gatsby-starter-plone uses demo site at a cloud by default so it is also easy to get starter and it is easy to play with it by just using the demo site without having a local plone site. Only then I would try running a Plone with Docker (from official images with “plone.restapi”-add-on added) next and building a gatsby site from that.
@datakurre If there is any Job/Internship regarding this Project , please inform me as I want to work with you. I am very disappointed with the fact that Plone is not being selected in GSOC 2019.
