I strongly believe that the path for innovation requires a mix of experimentation, sweat, and failure. Without experimenting with new solutions, new technologies, new tools, we are limiting our ability to improve, arresting our potential to be better, to be faster, and sadly ensuring that we stay rooted in systems, processes and technologies that are not current, or at least not as up to date as they could be.
As this three part blog will uncover, sometimes, progress is all about simplicity, and innovation can be delivered by not over-complicating the path to a digital solution.
So, on with part 1.....
Such a quest can be lots of painful, mostly because most of the times you'll fail, not that I consider it a failure in the real meaning of the word, but because you didn't achieve exactly what you were expecting. However, until you realize it as a failure you already won something, you increased your skills, you enriched your knowledge and, maybe on the next time you achieve completely your expectations.
But innovating can be also quite simple. For me, the simple fact of doing something different that you are used is already innovation.
Some years ago I was doing something in Photoshop and a friend of mine, designer, that was working with me, told to me: "Get up and get back a little and you'll see better what you are doing".
If you are a developer, its a bit of the same, sometimes just by switching to another language or experimenting with a different framework gives you some other perspective on the things.
Here at Appnovation, we are committed to our customers by providing the best implementations, by delivering in time, by fixing what is not working, but also to innovate, and share the results of such experiments. That's the purpose of my post, a journey that starts with a trending concept (Headless CMS) where I'm evaluating different solutions. Later in further posts, I'll add more detail by providing a practical example of leveraging Cockpit CMS and React.
Headless CMS
A Headless CMS is not an entirely new concept, however, only recently it gained traction with a bunch of interesting solutions. It's defined in Wikipedia as "A Headless CMS is a back-end only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device."
So, what above differs from the traditional CMS we are used? Basically that the headless solution is only responsible for the architecture of the contents, how they are composed and how they are related, not how they should be presented.
A typical Headless CMS provides an Admin interface to define the content structure and to create/edit/update/delete the corresponding contents, and a RESTful API used to expose those contents in a way they can be easily consumed by an application (e.g. Website, Mobile App, etc..). Resuming the presentation layer is discarded and the focus is on the contents. That approach can result in more freedom for the designers and frontend developers, as they are not limited by the typical constraints of the CMS. Moreover, it provides the ability to switch easily between designs or provide better UX across different devices.
Headless CMS solutions
There are plenty of solutions, in different forms and flavors, open source/free or commercial, self-hosted or cloud-based, simple or more advanced, it's like suddenly we shifted from half dozen well established traditional CMS to some dozen of new providers that promise to shake the usually "slow to adapt" CMS scene.
Some time ago, like any other curious web developer, I decided to take a look at those contenders and see what they are able. My purpose was mainly to have a high-level understanding of each one, to see how they deal with the contents from the conception of the content structure to the editorial part and how they can be consumed using a REST client.
My criteria were in fact very simple:
-
Quality of the project page, availability of documentation
-
Is free/open source or commercial, price?
-
Easiness of installation, availability of docker image, can be self-hosted?
-
Admin UI
-
How to define content structures
-
How to use the API to consume contents
I will not enter into the detail of the above exercise because is not the purpose of this article (maybe something for another post), for now only a few insights on some of the solutions that I analyzed:
Drupal - https://www.drupal.org
Well, having Drupal as the first option think it is a bit obvious, I work with Drupal for some years, I love it, and from my perspective is the most capable open-source CMS/CMF in the market, in fact, its better than most of the commercial and expensive solutions. However Drupal is not a Headless CMS, Drupal is a pure CMS/CMF where the presentation layer is part of the core system and cannot be turned off. Also, Drupal is not API only, it is an API first solution, as it is very well explained by Drupal creator, Dries Buytaert in his blog (https://dri.es/drupal-is-api-first-not-api-only). So we can see Drupal more as a hybrid, that can work for decoupled applications, by leveraging a set of modules or by using a Drupal distribution like Contenta (http://www.contentacms.org/) or Reservoir (https://github.com/acquia/reservoir). Both are promising, the power and flexibility of Drupal for shaping and editing the contents and a standard API for consuming the contents.
GraphCMS - https://graphcms.com
GraphCMS is the first headless CMS built around GraphQL, a modern and powerful data query language built by Facebook, that can solve some issues with a REST API like returning only what the client requests and nothing more, limiting the payload, what can be crucial on mobile apps. GraphCMS comes has a cloud solution, with a free (but limited) tier, setup is simple, a project can be created from scratch, from a template (Blog or News page) or by migrating from another solution (Contentful). The admin UI is built on React and Material UI and creating content types and fields is an intuitive process, most of the times in form of wizard/steps, however, the whole UI seems a bit clunky and slow to me.
Contentful - https://www.contentful.com
Contentful is another commercial and cloud-based solution, that fits in the medium/large level due to the price. A free but very limited version is available and the admin interface is very well conceived, we have 4 main sections, the Content model for modeling the content types, Content for managing the contents, Media for managing the assets and API to manage the project APIs. In overall, the interface is simple, fast and powerful, creating/updating fields puts Drupal in shame in terms of UX.
Directus - https://getdirectus.com
Directus is a full Headless CMS that is available as an open source solution (free) or hosted solution (pay). The admin UI is minimalist and the content types fields are shaped in form of tables and columns, something that I personally don't appreciate, when using a CMS I expect to define the contents using less technical concepts, for me a content type is a representation of some piece of information (e.g. page, product, etc..) that is composed of attributes (e.g. product name, product price) and therefore I'm not interested where it will be stored and how it will be stored, unless I'm a developer. That approach of database tables is yet more visible on the API calls like when retrieving contents - /api/1.1/tables/[table-name]/rows.
Cockpit CMS - https://getcockpit.com
Cockpit CMS is a small solution that was built from scratch with Headless in mind. Its a product of one person mostly one person - Artur Heinze. As it mentioned on his website, "Simple Content Platform to manage any structured content". It's a self-hosted solution based on PHP 7, Riot.js and SQLite (or MongoDB) that can be quickly installed using the docker image that is provided. The Admin interface is minimalist but intuitive, creating a new content type with a few fields is something that can be performed in less than one minute, something astounding when compared with other solutions. The REST API is simple to understand making the retrieving of contents an easy task. It can be extended by using the webhooks functionality or and since it’s an open-source and self-hosted solution by creating new add-ons.
If I was requested to choose one solution, as always I would ask for the business scenario and requirements, and probably would choose Drupal depending on the level of required customizations and dimension of the project. But let's imagine that we don't need anything fancy, we don't have the need for complex editorial workflows, we just need a simple website that will be managed by a few users and we want to build the frontend using a javascript framework.
In that scenario, my decision would be probably Cockpit and I'll try to explain why in the next post.
Share this Blog with colleagues
