search

datamade / how-to

📚 Doing all sorts of things, the DataMade way
MIT License
87 stars 12 forks source link

Headless Django CMS with Gatsby frontend #31

Closed jeancochrane closed 5 years ago

jeancochrane commented 5 years ago

Our research in #18 revealed that CMSes for static site generators are not currently mature enough for our use cases. However, there's another popular strategy for managing content in static sites that we didn't consider: using a headless CMS to manage content, and consuming that content in a static site via an API.

Broadly, there are two ways of consuming the content in a frontend app:

  1. Write the frontend app so that it retrieves all content dynamically from the headless CMS API on page load
  2. Use the headless CMS API as a data source for the static site, and retrieving data at build time

I'm interested in doing some research to test out 2) above. Specifically, I'd like to update LISC to:

  1. Install Wagtail CMS as a headless CMS
  2. Hook into Wagtail signals to tell the Netlify API to restart a build of the frontend app when an editor publishes a page
  3. Display a status on the Wagtail admin interface telling the user when the site is building, and whether it's deployed
  4. Update the frontend app to consume content from the headless CMS

Part of my motivation here is that the authors of Wagtail recently implemented this stack for their own marketing site, so we'll have some foundation to build on.

jeancochrane commented 5 years ago

My research here was pretty successful considering how many moving parts there are to this stack, but ultimately I decided that we didn't have enough time in the LISC scope to actually make use of a headless CMS. We're going to go with straight Wagtail instead.

You can see the full set of changes here: https://github.com/datamade/lisc-cnda/compare/7ac5af21e632935a1661c7e4b533ab4f9f1dae56...601b5ad99ff336038bb7431b08f52a6fb7945f0b The major work remaining was to:

I was able to confirm all of these would work during the spike, but I wasn't able to get a fully tested instance up and running in time.

This would be a great candidate for future work to take up on a bigger project where:

An example of a project that would have met these criteria back in the day might have been something like the Openness Project. Alternatively, we could put more R&D time into this to flesh it out in the LISC case; I'm just not quite sure how I want to prioritize it yet since it's not clear to me how big of a need this is in our stack outside of LISC.

jeancochrane commented 5 years ago

Abandoning this for now. Building this plugin could be a great candidate in the future for a project where:

  1. We have a nice budget
  2. We want to use React on the frontend
  3. The client wants to be able to edit content on the backend