Headless CMS - status so far

Announcements Minutes of Teams and Foundation Board
1

Continuing the discussion from Putting this on the radar:

Our first step will be to create an outline document of what we would like to accomplish. I gather that will be to create a distribution of Plone, repackaging and refocusing it as a logicful storage service, along with tools, documentation and sample front end clients.

Some folks involved so far (sorry if I miss any - chime in!): @ebrehault @pbauer @gabriellehp @polyester @sneridagh @pysailor @JohannaKookie @tisto @fulv @gyst @cganz @jean @ericof @ramon

We want to have at least one sprint before we meet at the Plone Open Garden in Sorrento (likely to be April 18-22, 2017).

Some related talks in Boston were:

We will have to get organized and call our first meeting. I expect most of us are still trying to dig out from under work that accumulated while we were in Boston.

2

just a friendly reminder to all the folks involved in this iniciative: Plone has today a small and mature community with very limited resources; so, again, festina lente or, as the great philosopher Dolly Parton used to say, I'm gonna hurry just, just as slow as I can


a few things you may like to read, share and discus:

Tjeerd Brenninkmeijer, CMO and co-founder of Hippo, in 7 Web CMS Trends for 2016 and Beyond

Headless CMS’s are Yesterday’s Silo

2015 saw the resurgence of the “headless CMS” idea — the idea that today’s content management system is one that doesn’t handle how the content it manages looks and feels in display. It simply manages the raw, structured content in a single repository.

But just because it’s a new capability for some, doesn’t make it a new idea. Every capable enterprise WCMS has (or should have) this capability.

It's a false choice. One CMS should be able to handle both: headless (e.g., for mobile app development or delivering content through an API to third parties) and a delivery tier to quickly roll out new personalized web channels.

A headless CMS often acts as an extra CMS for an organization next to the original CMS, which will create a content silo. Some remove this silo by moving all content to the headless CMS and creating a 'new’ one-off delivery tier on top of the headless CMS, but this guarantees future headaches. The marketer will ask for personalization, experiments, actionable insights, template and component management, etc. features ... And the development team is stuck with the maintenance burden of custom software while keeping up with the speed of the WCM software market.




The biggest, most meaningful trend of 2016 is how organizations can focus on creating meaningful digital experiences for customers, and get off the hamster wheel of producing more and more content. From our experience, those that pay heed to these trends — and focus on solution models that help them focus more on the quality of their content — will be the ones that succeed in the coming year.

Boris Kraft, co-founder and Chief Visionary Officer of Magnolia International, in A Headless CMS Won't Solve All Your Woes:

Where Things Get Complicated with Headless CMS

Headless CMSs raise issues of security, as it’s difficult to define which users get which access, creating a risk of delivering confidential content to non-authorized users. Delivering multi-language content requires a lot of development work to re-implement this feature. And with the separation of content and delivery, editors no longer have a way to preview the content they want to publish.

Another issue is personalization. Once you decide to separate the content from delivery, you need to rewrite a full personalization content engine. In many cases, form builders are also on the server, so integrations with marketing automation and other tools are lost as CMSs no longer have the capability to build the forms dynamically.

Today’s Solution May Cause Tomorrow’s Problems

In many cases, a headless CMS can result in increased complexity for developers and marketing teams. Your job is to look beyond the immediate attraction and think about the future.

It’s Not ‘Headless or Nothing’

The problems arise when companies decide that headless is the answer to everything. There’s no reason why you shouldn’t get a CMS that allows you to handle both headless content and the delivery layer.

The most important thing is ensuring that you have the flexibility to face the future, knowing that it’s impossible to predict.

Ted Schadler and Mark Grannan, from Forrester Research, in The Rise Of The Headless Content Management System:

Warning: Headless Content Management Is For Do-It-Yourself Shops

If you decide not to buy a packaged solution, you can compose one by adding content authoring and workflow tools, using different delivery tiers for different touchpoints, and implementing new kinds of content analytics. you may also have to push the pause button on WySIWyG.

I think we need a marketing team to help us visualize the future of Plone beyond technology hypes.

good night, and good luck!

1 Like
3

That's interesting, thank you Hector for sharing it.
I totally agree we need to provide both headless features and UI-based features, it makes a lot of sense (because headless CMS is not about replacing our current market with another one, it is about adding a new market to our current market).
And that's basically what Plone 5 is providing today: regular Plone is UI based, and plone.restapi provides a pure REST API (and plone.server + plone_client aim to do the same with a different stack).

What does not make sense is the following:

Headless CMSs raise issues of security, as it’s difficult to define which users get which access, creating a risk of delivering confidential content to non-authorized users. Delivering multi-language content requires a lot of development work to re-implement this feature.

Isn't it amazing? If your CMS becomes insecure (or not able to manage multi-language contents) just because you expose its features through an API, it actually means your CMS is very badly architectured. It means its security and its logic are implemented in the presentation layer.

Plone is not like that, so our REST API is:

  • at least as secure as regular Plone,
  • very resourceful, providing all the CMS features we are used to (multi-language, workflows, etc.).

And as far as I can see, I am not sure it is the case for the other headless CMS approaches and offers.
And it is actually not that surprising if you consider that most of them are SQL-based, and in SQL world, REST API often means "I have connected my db tables to HTTP!!". So yes, then I agree it will be a lot of work to have a running website on top of that, your UI will have to rebuild the navigation, the page composition, even something as simple as the breadcrumb will be very painful to rebuild.

In plone.restapi, we have endpoints for everything we need in any page of our website. I do not think there is any better offer at the moment.

3 Likes
4

Thanks @hvelarde. Well put. The world is not about to turn angular everything just like all sites aren't flash or java applets.

@ebrehault so if the restapi is good shape what is left to do?

1 Like
5

Well, few things are still missing (@tisto could tell us more about than me), but it is already working very well, and I know it is already used in production.

6

If I recall correctly, @tisto thought it would be possible to just declare it a beta as-is and then get it into core.

7

Overall we would need to produce materials (documentation, training, sample code, download packages, marketing (web site content, brochures)) for this "new" product. "New" because it's a different focus of Plone CMS, with a different market and set of users.

1 Like
8

4teamwork, kitconcept and other companies already use plone.restapi in production. So we could declare the current version 1.0 at any time. Though, for now I would prefer to keep it in alpha to make it easier for us to make changes and not having to support multiple branches.

One thing that I would really like to see though, to make it easier for people to adopt plone.restapi is a browsable API, comparable to what Django REST framework has:

http://restframework.herokuapp.com/

The Django project did a kickstarter campaign to make this happen...maybe something we should think about as well...

4 Likes
9

I have some specific thoughts on what these critics bring up...

Right, we've been here before.

In 1999-2003, Zope-based solutions being full-cycle was largely outlier for systems focused on CMS. At IPC10 in 2002, there was even a presentation in the Zope track about this by CMS consultant Tony Byrne, who compared systems like Vignette to full-cycle systems like Zope. Most publishers at that time were using distinct CMS from delivery systems, with the former usually bought, the latter home-grown. Exception to that was home-grown full-cycle.

Not an issue, there's no reason Plone would be headless only.

I suspect that a "CMS" used for delivery and not touched by editors -- let's just say, for hypotheticals, a Wordpress site (pushed to from a central Plone) -- is actually a CDS, not a CMS, as configured and installed.

Not a difficult problem, in terms of creating preview services that get POST a JSON payload, return an HTML preview? Easy enough for average site developer to implement for most any kind of web site. Of course, this is easier for standardized content (say, NITF :slight_smile: , for which I was doing something like this with in early 2000).

That seems suspicious. Big sites will use solr or elasticsearch for indexes across both CMS and CDS, and construction of personalized searches is the job of the CDS; always has been. There is no advantage to putting personalization inside the means of production.

This is a legitimate case where a full-cycle system is easier than separated systems. But not by magnitudes.

Forms are moving client-side eventually. My organization is early in process of moving our primary stuff from z3c.form to client-side JS schema-implementation that uses plone.supermodel XML and renders widgets for said fields. Say you use PFG or easyform? You probably have some system to POST to the back-end, and use some Diazo-style solution (or better, a super-simple redirect) to make the user just "see" the front-end.

Sean

1 Like
10

Indeed, we're already doing this.

11

I'll be sending out a call for the first post-Boston meeting of anyone interested in helping move this concept forward. If you weren't at the Boston BOF for this (which overlapped a lot with the Plone Open Garden / Sorrento group) and would like to help, please reply to me privately (here, on IRC, Gitter, Slack, nguyen@plone.org)

12

We had two hangouts this past week (Monday and Friday) to try to include everyone. The headless CMS group is headless-cms@plone.org.

Here are highlights of the discussions:

  • The headless CMS is part of the (draft) Plone 2020 roadmap
  • The REST API will allow two different approaches to be compatible
    • Plone+REST is currently used in production
    • plone.server is higher performing and handles async IO but still under development
  • Naming, marketing, and packaging (documentation, sample code, training materials)
  • A sprint will be organized, probably in Köln at the end of February 2017
  • More work will be done at PLOG in Sorrento, April 18-22, 2017

See the full planning Gdoc

If you'd like to join the team, please let me know! (here or by email)

1 Like