[WIP] Headless CMS for static sites

[fgregg]

Background

Working on static sites charges.thecircuit.cc and thecircuit.cc, editing copy was a major bottleneck and source of urgent, stressful last minutes changes.

We should endeavor to take ourselves out of this loop.

The owners of the text should be able to edit the text in a way that is familiar to them and trigger a deployment to update the copy themselves.

Things I'm thinking about

• Leaning more into google docs, and finding ways around shortcomings
• Setting up wagtail instance on heroku and exposing a hasura endpoint

Regardless of the CMS, the user should be able to push a big red button that to rebuild the content of the site.

A useful thread for context, read the replies

Proposal

What shape do you want your R&D to take? Focus on the big picture: What tasks you want to accomplish, what questions you want to answer.

Deliverables

What artifacts will you produce from your R&D? How will we know when you're done?

Timeline

How long do you expect this R&D to take? What could cause you to need more or less time?

[hancush]

See also: #18. Some of this tooling may have matured since we last evaluated.

[hancush]

And #31.

[fgregg]

31 looked really promising!

[derekeder]

When we talked to Webitects about the CALES project, Billy mentioned they are using Webflow. It was also mentioned on my call for the Food Resource Navigator project. Apparently Table XI uses it as well. Might be worth looking into.

[fgregg]

we flow seems like a netlify competitor?

On Tue, Aug 17, 2021 at 4:25 PM Derek Eder @.***> wrote:

When we talked to Webitects about the CALES project, Billy mentioned they are using Webflow https://webflow.com/. It was also mentioned on my call for the Food Resource Navigator project. Apparently Table XI uses it as well. Might be worth looking into.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/datamade/how-to/issues/223#issuecomment-900606086, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEDC3KEY3WFMRRPQCJQDT3T5LASTANCNFSM5CKFSJKQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[derekeder]

they are both static web hosting services, but i think netlify is more geared for developers and webflow for designers (they feature no/low code)

[smcalilly]

The Google Docs workflow is promising on the surface, especially since it's a familiar workspace for most everybody. However, the gatsby-source-google-docs plugin we're using in the Charges app is pretty basic and doesn't have the support that a full-on headless CMS might have (with the dedicated support of a company). It takes the Google Doc and converts it into markdown, which is queried with GraphQL. Then the markdown is converted into html. The plugin also had some weird bugs. And it was kind of an obscure development experience -- wasn't obvious how it worked on the surface and took a bit of digging in Google Docs and the code to find how it pieced together.

I've worked on a Gatsby site that was using Contentful. It was pretty easy to use from a development perspective, especially since it was using GraphQL. Not sure how it is from a CMS user's perspective, so can't speak on that. I've also heard good things about Prismic, but never used it.

Contentful and Prismic can work with a backend like Django, since it's simply using API calls to get the content. This is out of the scope of static sites, but we could potentially use something like that in both a Gatsby and Django app (so less tech for a developer to learn, since we're using something familiar across our stack). That use case might be at odds with our typical architecture since that's like a microservice, plus it would add extra overhead for a user account separate from a Django admin account.

[smcalilly]

Re:

Regardless of the CMS, the user should be able to push a big red button that to rebuild the content of the site.

We could make a google workspace add-on script to do this! But that might not be worth the time/effort.

[hancush]

Effective immediately: We won't build new static sites with a CMS. If we create a new static site, we'll own content changes.

As for next steps, we'll use an existing Gatsby project (maybe Green Jobs or The Circuit static site) to spike out a headless Wagtail CMS backing a Gatsby site.

I also want to add the Django/React issue (https://github.com/datamade/how-to/issues/66) and PR (https://github.com/datamade/how-to/pull/84) as a good example of a time we've explored and adopted a new-to-us pattern.

[smcalilly]

closing, we've moved on from gatsby.