Buytaert is also co-founder and chief technology officer of Acquia, a firm that commercially sells access to a platform to build and operate application services using Drupal.
Commenting on the fact that more and more developers are choosing Content-as-a-Service solutions (known as headless CMSs), Buytaert explains that that these content repositories offer no-frills editorial interfaces and expose content APIs for consumption by an expanding array of applications.
Not happy with the performance of the headless CMS, Buytaert bemoans these systems for their implicit functionality designed to separate concerns of structure and presentation so that front-end teams and back-end teams can work independently from each other.
The claim from Buytaert and team is that Drupal can work as a good CMS for editors who need control over the presentation of their content and a rich headless CMS for developers building out large content ecosystems in a single package.
Where headless CMSs (arguably) fall flat is in the areas of in-context administration and in-place editing of content.
“Our outside-in efforts, in contrast, aim to allow an editor to administer content and page structure in an interface alongside a live preview rather than in an interface that is completely separate from the end user experience. Some examples of this paradigm include dragging blocks directly into regions or reordering menu items and then seeing both of these changes apply live,” blogged Buytaert.
He further states that by their very nature, headless CMSs fail to provide a fully-fledged editorial experience integrated into the front ends to which they serve content.
“Unless they expose a content editing interface tied to each front end, in-context administration and in-place editing are impossible. In other words, to provide an editorial experience on the front end, that front end must be aware of that content editing interface — hence the necessity of coupling,” added Buytaert.
API-first is key
The Drupal team is adopting what it calls an API-first to make using Drupal as a content service easier (and more optimal) for developers.
In an API-first approach, Drupal provides for other digital experiences that it can’t explicitly support (those that aren’t web-based).
This could be an new way of expressing inherent openness and always keeping multiple deployment and use case options open — yes, we’re interested.