Storytelling tool: decoupling editing and viewing stories

Cindy Li cli at
Wed Aug 5 17:34:25 UTC 2020

Hi Justin,

I think using static websites for archived storytelling websites is a great idea.

However, for the site that editing can be enabled, since each save to the database will trigger a re-deploy of the static site, we might like to understand and clarify some questions before making a decision:

1. The usage of the editing tool: how are stories created? Are they usually created in workshops with a number of people editing/creating stories simultaneously, or the usage is spread over time?
2. How fast the static viewing part can be deployed?
3. Would swamped saves to the database mess up the deploy of the static part?

Moreover, with the implementation of server side auto save <> for uploaded medias/files, creating/editing a story could lead to multiple saves to the database rather than at the publish step.


> On Aug 5, 2020, at 7:58 AM, Justin Obara <obara.justin at> wrote:
> Hi Gregor and Dana,
> I was reading over the Branches <> doc for Storytelling this morning and also reflecting on the testing work that was needed following the 0.3.0 release last week. If I’m understanding things correctly, only the AIHEC <> (currently in production use) and staging <> sites allow for authoring stories. During the “Storytelling Tool long-term technical road map discussion <>” we spoke about the possibility of integrating with a SSG like 11ty <>. I don’t think I fully grasped, and may still not, the distinction between the authoring of stories and viewing stories on the site. At the moment it appears that these are coupled together into a single system which can be set to enable story authoring/editing. In the case where editing is disabled there is still a server and database backing the browsing/viewing of stories.
> If our end goal is to decouple the authoring/editing from the story viewing/browsing, we should revisit this along with the login and authentication. It will probably depend on how things are actually implemented so I’ll just illustrate one possible scenario below. We should consider how we actually want this to work, what the benefits and tradeoffs are, and etc.
> Possibile scenario:
> The deployed story site is always a static site. When a story is authored/edited, the server triggers the site to redeploy at which point the static site is regenerated with the content stored in the database. When story authoring/editing is enabled, an instance of the storytelling tool is deployed alongside it. The storytelling tool being just an authoring interface which stores stories to the database. When login/authentication is provided, it will also provide a view into the users' stories for editing/deleting. When story authoring/editing is disabled we only deploy the static site; the storytelling tool does not need to be deployed. Additionally the backend database can be archived and disabled if the stories are intended for view only and are effectively archived.
> Points of configuration between the systems would include configuration for the SSG to enable/disable the link to the storytelling tool, linking from the storytelling tool to the published story on the static site, and styling for preview in the storytelling tool to match the output in the static site. 
> Please let me know what you think and if I’m misunderstanding anything.
> Thanks
> Justin
> _______________________________________________________
> fluid-work mailing list - fluid-work at
> To unsubscribe, change settings or access archives,
> see

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1487 bytes
Desc: not available
URL: <>

More information about the fluid-work mailing list