Since the very beginning of Drupal, one fundamental assumption has underpinned the development and evolution of Drupal: its monolithic architecture. Drupal was created in a time when web and CMS technology was burgeoning and when API driven applications were rare in this space.

Thanks to modules in the contrib space and major core initiatives such as WSCCI and API-first, Drupal has made formidable strides in providing interoperability with other technologies. Drupal today is now more accessible than ever to developers beyond PHP who are using Drupal to back their applications implemented in JavaScript, Swift, or even other server-side languages.

However, it's currently not possible to build a decoupled interface into Drupal that can perform all the available tasks through a standard administrative theme, as interfaces into several major subsystems such as Form API, configuration and layout are missing.

We believe it’s time for Drupal to be decoupled out of the box and to enable greater developer flexibility as a rule, not as an afterthought.

It’s time for the community to challenge our current assumptions and think about Drupal’s long-term future. Looking not just through the lens of our collective history and background, but also through the kaleidoscope of the many new available ways to consume Drupal and the larger evolution in our industry toward microservices, headless content management, and content as a service. In this core conversation, we’ll present a few ideas, points of discussion, and off-the-island case studies before delving into deeper discussion.

Here’s what we’ll cover:

What are people building decoupled sites with Drupal finding difficult
Summary of what APIs are currently available and what's missing
What are other CMSes doing
How can we architect a way forward for a more internally decoupled / microservices design