Anyone who has attended a Drupal event in the last few years has had plenty of opportunities to learn all about the technical details of implementing a headless Drupal site. If you haven't already been exposed to this concept the TLDR version is: Headless aka decoupled Drupal is the process of using your Drupal site as the backend for another framework, most typically a Javascript framework.
"The right time to add an abstraction to a design is at the point when you start feeling the pain of not having it."
- http://sam-koblenski.blogspot.com/2014/07/the-cost-of-abstraction.html
Every layer of abstraction in a software system comes at a cost, sometimes a very steep one. When I turn backend requests for data into an API call I implicitly add a requirement for a well-architected highly-available API (or its proxy) to my project. If a lone Javascript framework is the only thing that will ever make requests to this API, what is the basis for introducing a single point of failure to our project? We need to start thinking about the number of concurrent requests our Drupal endpoints can support, do we know how to set up a cache layer for our new framework we picked last week? We also need to think about how we want to structure all of our different API endpoints. Will we be following typical Drupal data structure definitions, or will we be trying to draw new lines to adapt to structures that our frontend expects? If the Javascript and Drupal teams are separate (not made up entirely of Drupal developers, or former Drupal developers) then these discussions about format and structure may add weeks if not months of planning to your project. We typically don't worry about these United Nations style meetings when everyone is speaking the language of nodes and taxonomy terms, but when we decide to go headless content isn't available until we expose it.
Before jumping on the headless bandwagon, it is important to look at our motivation. What business requirements drove the move to headless for our project? There is an understandable desire that many Drupal developers have to "get off the island" and explore some new tools. Nobody likes getting laughed at when you introduce yourself at the local Javascript meetup, but anxiety about using a modern-enough toolchain shouldn't be the motivation for your headless project. Over the last 5 years while PHP template engines have been mostly stagnant, the Drupal community had grown increasingly frustrated with the quality of the front-end tooling that Drupal ships with. While we were struggling Node.js triggered a front-end Javascript framework explosion that has taken the front end world by storm. These frameworks provide tight integration with modern build tools and lots of powerful tools designed to help you easily build out your modern frontend.
As a lot of Drupal developers were investing a lot of their time (and their clients) into learning Javascript frameworks, the Drupal status quo was shifting. Thanks to the hard work of a lot of individuals we now have a modern theme layer available to everyone in Drupal 8, and resolved a lot of deeper issues in our theme system as a result. TWIG includes a lot of the flexibility that these other frameworks provide, it silos off the PHP backend from the front end, and delivers all this in a Drupal native format without requiring a lot of extra work or complexity.
When are the risks of a headless project clearly worth taking on?
Is the Drupal backend one of many sources of data for the front end framework?
Headless is a great way for Drupal to be a good citizen in a world of API-driven applications.
Do you already have an Angular / React / Meteor / framework-of-the-week team that has no interest in learning Drupal?
By all means don't torture your Javascript devs by forcing them to learn Drupal.
Are other applications and services going to be using the data provided by Drupal?
If you are going through the work of architecting, providing and testing API endpoints, you might as well thoroughly vet them while you are building your front end.
Whether or not you are going headless, don't use this post as an excuse to postpone learning these new tools. The age of Javascript frameworks is here whether we like it or not, and you may be missing out on learning a powerful tool that is just what you need for your next project.
