![]() Though key functionality like in-place editing and layout management are unavailable, fully decoupled Drupal is appealing for developers who want greater control over the front end and who are already experienced with building applications in frameworks like Angular, React, Vue.js, etc. In this scenario, the CMS becomes a data provider, and a JavaScript application with server-side rendering becomes responsible for all rendering and markup, communicating with Drupal via web service APIs. Up until this year, fully decoupled Drupal was a single category of decoupled Drupal architecture that reflects a full separation of concerns between the presentation layer and all other aspects of the CMS. The progressive decoupling paradigm lies on a spectrum the less of the page dedicated to JavaScript, the more editors can control the page through Drupal's administrative capabilities. This JavaScript might be responsible for nothing more than rendering a single block or component on a page, or it may render everything within the page body. In progressively decoupled Drupal, a JavaScript framework is layered on top of the existing Drupal front end. In this case, a decoupled approach becomes required. Sometimes, JavaScript is required to deliver a highly interactive end-user experience. Because the benefits are real, this is still how most new content management projects are built. ![]() ![]() This is Drupal as we have known it all along. Traditional Drupal remains an excellent choice for editors who need full control over the visual elements on the page, with access to features such as in-place editing and layout management. In traditional Drupal, all of Drupal's usual responsibilities stay intact, as Drupal is a monolithic system and therefore maintains complete control over the presentation and data layers. The different flavors of decoupling Drupal exist due to varying preferences and requirements. As I've written previously, the three most common approaches to Drupal architecture from a decoupled standpoint are traditional (or coupled), progressively decoupled, and fully decoupled. I want to revisit some of the established ways to decouple Drupal as well as discuss new paradigms that are seeing growing adoption. (At the end of this post, there is also an accessible version of this flowchart described in words.) Time to update my recommendations for 2019! As we did a year ago, let's start with the 2019 version of the flowchart in full. In the time since my last post, the surrounding landscape has evolved, Drupal's web services have only gotten better, and new paradigms such as static site generators and the JAMstack are emerging. In response to the trend towards decoupled architectures, I wrote blog posts in 2016 and 2018 for architects and developers about how and when to decouple Drupal. As a result, we've seen headless or decoupled architectures emerge.ĭecoupled Drupal has seen adoption from all corners of the Drupal community. The pace of innovation in content management has been accelerating - driven by both the number of channels that content management systems need to support (web, mobile, social, chat) as well as the need to support JavaScript frameworks in the traditional web channel. This blog has been re-posted and edited with permission from Dries Buytaert's blog.ĭo I build my website with Drupal's built-in templating layer or do I use Drupal's decoupled or headless capabilities in combination with a JavaScript framework?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |