Better documentation for using this with static site generators such as Gatsby

[sminnee]

Although it may seem that, with a site architecture such as using Gatsby/Netlify to host a static site, this module is unnecessary, I can see a few benefits:

• The module provides scaffolding for identifying which URLs should be re-generated in response to a given content change. On a site with 10,000s or 100,000s or static URLs, this would be critical even with a high-performance publication system.
• More trivially, it's also hooks into the publish action

In essence this is a matter of implementing the StaticPublisher interface. There's an example of this in DorsetDigital/silverstripe-edgepublisher

Arguably, we could split this module into 2 parts, with the core render scheduling shifted into an underlying renderqueue module. However, the additional complexity is probably not warranted as it's only a few classes that are not relevant in other use-cases.

One thing that is a notable limitation is the lack of a batch-publish hook on the StaticPublisher interface. This would be a welcome addition, but probably warrants a second ticket.

The core point of this ticket is to broaden our view of this module's purpose. :)

cc @chillu @DorsetDigital

[maxime-rainville]

@unclecheese @adrhumphreys From memory you guys have been experimenting with SilverstripeCMS and Gatsby. Any insight on how this might impact or interact with static publisher?

[sminnee]

One thing that I thought would be obvious but I can't immediately see is how you trigger incremental updates in these 3rd party services. If it's not a well-supported feature, then this might be less relevant.

[unclecheese]

Incremental updates are a huge area of discussion right now in the Gatsby community. It's one of the next pillars that needs to fall in order for Gatsby to work at scale. They already have a "preview" feature which relies on incremental changes being pushed to a lambda function, so it's hard to imagine it isn't coming soon.

I'm not sure I see these two modules as compatible. I see it as one replacing the other. The nice thing about the Gatsby approach, among many things, is the dependency graph is implicit through embedded graphql, whereas with staticpublisher, you have to wire all that up explicitly, and it's error prone.