Evaluate static site CMSes

[jeancochrane]

Background

Django's CMS solutions are not great. To boot, we don't have any CMS options at all for static sites.

Netlify CMS promises to be a lot better. It claims to be an open source static app that you can plug in to any app built with a static site generator in order to expose content editing via Git. Content is staged for editing as GitHub PRs and can be reviewed with Netlify's preview builds. In essence, it's a frontend on top of GitHub, Markdown, and Netlify.

Relevant questions include:

1. What are our authentication options? Do clients need to know how to use GitHub?
2. Can we restrict permissions so that clients can only write to content, or do they have to have write access to the whole repo?
3. How hard is it to integrate Netlify CMS with a Gatsby app? Is it as plug-and-play as the docs claim?
4. What is the editing interface like? How extensible is it?
5. What kinds of content can you edit? Pages? Posts? Arbitrary data?
6. What sorts of changes to our standard static app deployment SOP would we need to enact to use Netlify CMS?
7. Is Netlify CMS promising enough to pilot on the next iteration of LISC CNDA?

Deliverables

I'd like to test Netlify CMS by plugging it into LISC CNDA to see if it would be a workable alternative to Django CMS for static sites. The deliverable will be a pull request incorporating Netlify CMS into LISC CNDA, either with a recommendation for further research, or with my reasons for abandoning it.

Timeline

I propose to start and finish this work on Friday, 6/21.

[hancush]

i'm interested in this as a way to avoid building what are essentially static sites as django apps because we desire an admin interface.

that said, all the parts of django, i've found the admin interface to be the most straightforward and extensible, so i would be very hesitant indeed to consider this a replacement, especially for applications like ihs that have require a cms for text posts, but also richer admin actions, like uploading data (teeing off an import process) and manipulating the cache.

of these, i'm most interested in points 4 and 5: how hard does your life become if you need any custom behavior, and are there limitations to the types of content management you can perform?

[jeancochrane]

Netlify CMS initial impressions

Based on one R&D day's worth of time playing around with Netlify CMS, I don't recommend that we go forward with it. Overall, I think the idea behind Netlify CMS (use GitHub as your CMS for a static site) is really strong, but the project exhibits a number of inconveniences that indicate to me that it's too immature for production use.

A few dealbreakers that arose during my research:

• Login flow is finicky. Netlify CMS uses Netlify Identity under the hood for user auth. I have some problems with Netlify Identity, and while Netlify CMS solves one of these problems by providing a fancy-looking login widget out of the box, the widget doesn't actually work very well, and in particular it exhibits a slight lag of 1-5 seconds after the user submits their credentials to login where it appears that the user has been taken back to the login screen. This is a crucial part of the application for building user trust in the CMS and I can't see our clients getting past it.
• Page creation is tricky. Netlify CMS is optimized for posts, and not necessarily pages. This became painful for me when I wanted to include a Markdown widget in a Page data type and realized that it wasn't supported.
• Previews in editorial flow are non-intuitive. "Editorial flow" is a thin UI on top of GitHub PRs where Netlify CMS will push a pull request for the user when the user wants to request review on their changes, and then reviewers can look at a Netlify deploy preview to see how the changes look. The concept is attractive -- why not repurpose PRs and deploy previews for non-technical review? -- but in practice, it's hampered by the way that deploy previews are presented. In order to show a preview, a PR has to be opened and Netlify has to run a build, which takes anywhere from one to fifteen minutes depending on the complexity of the site. During this time the user has to hit a "check for preview" button that will poll Netlify and see if the preview isn't ready. If you don't already understand how GitHub/Netlify/building code works, this would probably strike you as unecessary and cumbersome.
• Image uploads in editorial flow don't fit with the PR. When creating a draft in editorial flow, image files will get committed to master, then content will be opened in a separate PR referncing the image files as necessary. This is a weird departure from the premise of editorial flow in that it commits to master before a draft has been reviewed. Perhaps not a big deal, but it indicated to me that there are quirks in the editorial flow that haven't been ironed out yet.

All of these gripes are relatively minor, and it's only in their sum that they give me the impression that Netlify CMS is an immature project. I would be interested in revisiting Netlify CMS in about a year to see how the project has progressed, since I think the basic idea (use GitHub as your CMS) is still a strong one.

[jeancochrane]

Next steps: Try Forestry.io. David Eads also suggests looking at Ghost and Dato as "headless CMSes".

[jeancochrane]

Finally got a chance to play around with Forestry.io last Friday. Overall, my impression is that Forestry is a far better solution than Netlify CMS, but is ultimately not ready for production use just yet. Here are some thoughts:

Improvements over Netlify CMS

• Previews. Forestry can deploy a quick testing app (similar to a deploy preview) to allow a content editor to preview their changes before saving. With a Gatsby site this is kind of slow, since Gatsby has a long build time and the instant preview has to rebuild the site from scratch, but it's faster than Netlify CMS and makes more sense in the UI. There's also an "Instant Preview" which purports to run a remote dev server that you can connect to. I didn't try this out, but it seems like a promising solution, particularly for speeding up Gatsby site builds.

• Clean, professional UI. The user interactions in Forestry are generally nicer than in Netlify CMS. The login flow feels robust, and the user interface is similar to Wordpress.

• Great docs. The documentation is extensive and easy to read.

Downsides

• Long Gatsby build times. Because Gatsby is focused on runtime performance and not build performance, Forestry warns that builds and previews can take a long time.

• Editors need write access to repos. This is perhaps my biggest problem with static site CMSes so far. Since the CMSes are just UI wrappers on Git, editors need to have write access to repos, and content changes will push updates to repos. Maybe this is a compromise we can accept -- I can't think of an easy-to-define danger situation -- but it makes me uneasy, particularly given that our development team is often very separate from the team editing our site contents (i.e. we may not have a maintenance contract, or we may go many months without working on the code during which time lots of content changes will be pushed).

• Media uploads still get committed directly to master. This problem persists between Netlify CMS and Forestry, so there must be a good and real limitation here that prevents uploading media into draft branches. Still, it messes with the history and "draft" nature of a branch.

• No Netlify integration. Forestry has an impressive number of hosting integrations but Netlify isn't one of them. We would probably have to figure out an S3 + CloudFront build pipeline for Forestry to make sense.

What next?

Unfortunately, the result of this R&D sprint is that there still isn't a static site CMS I would recommend for Gatsby. This is disappointing, but also not surprising given the opinions on static site CMSes that I was getting from developer friends.

I think it's worth keeping an ear out to hear if anyone we know starts using these tools, at which point we can re-evaluate them. Alternatively, if a DataMade developer successfully uses a tool on a personal/side project I would be more comfortable giving it a try in production.

On the CMS side, we're piloting Django CMS in a few new projects and I would love to try to do some work in the future to give it a try as a headless CMS for a Gatsby site. Django CMS might not support this (see this old blog post) but Wagtail, a very similar Django-backed CMS, does support a headless CMS.

[hancush]

Thanks for looking into this, @jeancochrane.

If we return to this, I had a thought re:

Editors need write access to repos.

Unless we wire up a static app to interact with a remote database (did Eads do this with the ticket trap?) or a headless CMS as you suggest, I think this particular point is going to be hard to get around, because the new content is going to have to live with the site code. Thinking more about this, would it be possible to architect static sites such that the site code is separate from the articles, and one is included as a submodule of the other? Then we could give editors access only the the articles (or whatever the editable content is) repository?

[hancush]

Wow that close button came out of nowhere!! Sorry, @jeancochrane!

[jeancochrane]

Thinking more about this, would it be possible to architect static sites such that the site code is separate from the articles, and one is included as a submodule of the other?

This seems like the safest solution to me, but it introduces some challenges in terms of CI that make me nervous. In particular, we'd need to maintain some sort of webhook that would notify the app repo that the content submodule has been updated in order to update submodules and trigger a fresh build. (This would need to work for both staging/production builds as well as branch/deploy previews.) This strikes me as a good feature for a service like Netlify or Forestry to provide, but as far as I can tell neither of them offer it -- the closest we get is Forestry documenting how to use submodules to manage your themes (TL;DR: git submodule update manually when you need to update your theme).

I've been working on identifying someone who's implemented this sort of pattern because I think they could help answer a lot of the conceptual questions I have. Will update this thread if I find anything!