Ask HN:Which is the simplest CMS to Integrate?

You are in total control of the frontend since the core doesn't output any HTML. You can use it with plain PHP templates (easiest) or headless. The admin panel is clean and totally customizable via an YAML configuration file. Content is stored in files, no DB needed.

I would suggest you look at CaaS solution like Contentful, Prismic.io or similar which would provide the editing interface as a service and simply expose the content through an API for your front-end code to use.

No issue with having to update and maintain the CMS, no issue with scaling, less security concerns, etc... If you are not in the business of hosting CMS, it's clearly the best solution for you.

Other than that I've had previous good experiences with: https://forestry.io/

https://www.netlifycms.org/

Without some solid requirements that dictate the need for custom code, I'd just point them at Wordpress and call it good.

https://developers.google.com/sheets/api

- free

- framework agnostic

- easy to integrate (IMO relatively easier than parsing a WP API, setting up proper taxonomy, etc)

- your user is probably already familiar with Google Sheets

- not ideal for sensitive info, that's ok because this is a portfolio site for public info

- not ideal for large datasets, that's ok because your user will have a relatively small, static dataset

Here's the sample frontend: https://developers.google.com/sheets/api/quickstart/js

If it was for a big client needing a business solution, sure I'd say you need to choose Wordpress as it is industry standard. But because it sounds like your client is an individual who hired you for their own personal needs, IMO Wordpress is overkill here.

Better yet, just hook up a YAML flat file, show them where it is in Github, and give them collaboration permissions :D

It's far from sexy, but you know it will still be stable in 9 months and the client has other avenues for self support.

One, in terms of integration, if you're considering headless you probably already are thinking of a decoupled solution (meaning frontend and CMS are separate anyhow). In that case, it might help to think about the CMS as just another generic API that your frontend has to speak to instead of "integrating" with via bespoke SDKs.

These days, many vendors offer GraphQL output for their content delivery APIs, and that's really easy for Gatsby or Next.js or graphql-request or node-fetch to consume. The resulting shape (object schema) you get back as a response is easy to map into component trees and iterables. Many (most?) headless vendors offer GraphQL endpoints now, and while it's not perfect, for most pages it'll be easier than having to join together multiple REST calls (like one call for posts, another for authors, a third for tags, a fourth for related items). GraphQL makes that all one API call returned as a nested JSON.

Among headless options, there were initially 20+ vendors to choose from (this site has a list: https://cms-comparison.io/). As the primary dev, I did a first pass and eliminated a few right off the bat that I didn't think would fit our needs. Then we asked the other stakeholders to participate in a pretty exhaustive weighted features comparison (https://airtable.com/shrDPlmk7R3B4ddO1), having each stakeholder compare features across each CMS, then weighing each feature by their importance to our project. While we didn't choose the final winner this way, it did help narrow our initial list of 20+ options down to a more doable 2-4 finalists. We built functional prototypes (choosing a complex enough page to showcase the CMS's capabilities) and demoed them to the stakeholders and began contract negotiations.

We learned a lot from that process for our own needs, and I'd encourage you to pick a few and run a similar analysis just for yourself and your client, based on their needs. For example, will they require deeply nested content models (like a page that contains a section that contains an accordion that contains a WYSIWYG that contains a paragraph with a CTA button that opens up a modal that they can define in the CMS).

Some of the options are better at handling that sort of thing (GraphCMS, Contentful), but that comes with tradeoffs in other parts of the editor experience. It seemed in our evaluation that the CMSes that were the most flexible in terms of nestable content models were also the ones that didn't offer as good a page composition experience, as in being able to visually drag and drop things around a page (move the accordion above the hero) in an intuitive way. The market is still trying to figure out how to best do their UIs and UXes. Some of them treat every field and model as equivalent primitives, meaning you build everything up from the deepest nested layer (usually something like a "button" or "image with caption") then add containers within containers on top of that. But that quickly becomes visually and mentally overwhelming for the editors, who usually think about pages not in terms of nested schemas but the functionality that they want to add. Some of the other options, then, purposely avoid the "everything is a model" design and break things down into pages, posts, blocks, etc. (DatoCMS, Storyblok, ButterCMS). In any case, it's worth poking around a few of them and trying to model a complex page or two in their schema builder (model editor) to see if the resulting page would be easy enough for a non-dev editor to use and edit.

Among open source packages, to my overwhelming surprise, Wordpress with Advanced Custom Fields (

If you want to use WP as usual and get a headless output in one click that even your client can generate, check out Strattic: https://www.strattic.com (Disclosure: I'm from Strattic).