Back-end devs don’t need to compile CSS front-end devs don’t have to worry about composer installs. Developers need only concern themselves with the setup and tooling specific to their part of the stack. In a headless strategy, the API can be tested easily, helping you catch potentially breaking changes earlier in the process. Back-end developers can introduce changes that break front-end functionality more easily in a monolithic application. Bugs are easier to locate when your platform is composed of smaller, discrete parts instead of one giant application. A CMS upgrade doesn’t have to affect the presentation layer, only the CMS. Decoupled architectures alleviate many of the problems that often accompany monolithic content management systems. This is, perhaps, the most important question. This opens the door for a broad gamut of languages, frameworks, and platforms to ingest and present your content. In this strategy, Drupal exposes an API (application programing interface) for other applications to consume. That is, there are no public-facing themes and templates, there is only content and the administrative UI. In contrast, decoupled Drupal - also known as “headless Drupal” - is a strategy by which Drupal is used strictly as a content management system without a presentation layer. In this sense, it is monolithic because your entire project sort of “lives” inside Drupal. In a conventional web project, Drupal is used to manage content and to present it. In this post, we’ll explore some of the questions to ask along the way. As with most things, the answer is more nuanced than one might think. Finally we'll take a look at some of the hosting implications and considerations you'll need to address when thinking about launching our newly decoupled project.īy the end of this series, you'll see how easy it is to expose data from our Drupal site as a JSON API, and be itching to try out the latest Javascript framework to build your own isomorphic single page application.“Decoupled Drupal” sounds cool and just about everyone else seems to be either doing it or talking about it, so it must be the best solution for you, right? Well, maybe. In doing this, we'll learn about isomorphic Javascript and clean up our custom Javascript application. Once our basic single page application is built out, we will take a look at a couple of methods we can use to improve our SEO and the experience of our user's initial page load. We're going to make use of a few new technologies that will also be at our disposal in Drupal 8, Backbone.js and the Twig template system. We'll start with a Bootstrap template and write a single page Javascript application to handle navigation between current posts and the blog's archives. With our API in place, we can turn our attention to a simple front-end blog demo project. We'll also take a look at what Drupal 8 brings to the table to help us build out a REST API without writing a single line of code. We'll take a quick look at writing custom code, using Views Datasource, Services module, and the RESTful module to expose data from a Drupal 7 site. Next, we'll look at a variety of methods in Drupal we have at our disposal to expose data from our site as an API. With the fundamentals in place, we'll then talk about making sure your API is documented and tested. Then, we'll start in planning our decoupled project by talking about the components that make up a solid API. Then we'll come up with a list of criteria that should be considered when deciding if pursuing a decoupled approach is a good idea for your project. We'll start out by talking about what it really means to decouple your website. In this series we're going to take a closer look at Decoupled (or Headless) Drupal.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |