Bild des Benutzers nod_

One important point not mentioned in the article is accessibility. There was a lot of work to make Drupal frontend accessible, and I'm sure it will be swept under the rug once people do their own thing.

Bild des Benutzers Sebastian Siemssen

Right, absolutely! While Javascript and accessibility certainly don't contradict each other it's definitely one of the more challenging aspects of front-end development. It's another thing that you are basically waving goodbye when walking down this path.

And there are definitely more things than the ones listed. I do not claim completeness of the list of pain points / things to keep in mind. Consider them examples. I am going to add accessibility to the article though since I think it is one of the more important ones! Thanks

Bild des Benutzers Ryan Szrama

Looking forward to your future posts on the topic, Sebastian! I might push back on the question of chattiness by suggesting that an intelligent but abstract media type can reduce the number of HTTP requests required for a pageload, even for the front page of a site. That may be through the use of embedded resources or through a slightly advanced use of a HAL+JSON or Collection+JSON where you request a collection of entities and know how to follow references in the result set.

For example, in rendering a shopping cart in a mobile app, I need order, line item, and product data, but there's nothing preventing me from using a media type that knows how to embed full entities in another representation (kind of what I did in Commerce Services) or simply is type agnostic so that you can inspect the entity type and IDs to put things together in the right order client side.

That doesn't really "solve" the issue, as it just creates client-side engineering challenges that we haven't really addressed yet, but it at least removes the "REST is a dead end" blocker (imo) and refocuses us on building the tooling for and making use of more suitable media types.

Bild des Benutzers Jeff Eaton

Excellent writeup! It matches what we've found on a number of decoupled projects over the last 4-5 years. (We prefer that to "headless" for clarity purposes…)

Sites that have been dealing with complex multichannel publishing requirements (driving native mobile apps from the same source data as the web site, for example) have had to grapple with these problems for a while, and it's great to see someone else pointing them out. Decoupling isn't a quick fix for frustrating Drupalisms—it's a way to future-proof site architecture, and it comes with its own set of problems to solve. They aren't insurmountable, by any means, but the solutions aren't yet standardized and baked-in yet.

Ryan's comment above is a good example of that; consolidating the requests needed to build a page is a great way to reduce the "chattiness" of an API-driven approach to page building! But the tools to make that a reality aren't turnkey, just-install-and-go options the way something like page caching in Drupal is. It'll take time!

We're in the early days of Drupal decoupling, and the good news is that we're moving in the direction that the rest of the web world is (rather than fighting against it). We've enjoyed the benefits of fully integrated admin/management/delivery for years, and now we're having to figure out what a world with looser connections looks like.

Bild des Benutzers Sebastian Siemssen

Thanks for your comments, Ryan and Jeff! I am glad that you agree with the general verdict and it's good to know that you have experienced the same issues.

I hope I did get the message across that these problems are all but insurmountable. It's definitely possible to work around some of the problems as you pointed out. However, it's far from simple and that fact is constantly swept under the carpet (at least that is my perception).

I agree that proper design of the API and leveraging more advanced media types can improve the situation. However, I am still convinced that we can do even better. I want to reach a point where the API can be treated as an implementation detail. This is exactly why I am working on the GraphQL implementation (I am going to be in Montpellier next week and will spent most of my time there working on that).

Btw. I absolutely agree that "headless" is a horrible word for what we are talking about here. Decoupled is way more fitting. I actually saw a post on d.o arguing for this as well as your Tweet before writing this blog post. But since "headless" is more commonly used (I think?!) I thought it would be better to stick with it at least for this post to get a little more impact on Twitter. I am an attention whore, sorry :P.

Bild des Benutzers Wim Leers

Let me reply by quoting https://codeascraft.com/2015/04/06/experimenting-with-hhvm-at-etsy/

The second problem was how tempting it became for engineers to build lots of general API endpoints that could be called from many different mobile views. If you use too many of these endpoints to generate a single view on mobile you end up degrading that view’s performance. Ilya Grigorik’s “Breaking the 1000ms Time to Glass Mobile Barrier” presentation explains the pitfalls of this approach for mobile devices. To improve performance on mobile, we decided to create API endpoints that were custom to their view. Making one large API request is much more efficient than making many smaller requests. This efficiency cost us some reusability, though. Endpoints designed for Android listing views may not have all the data needed for a new design in iOS. The two platforms necessitate different designs in order to create a product that feels native to the platform. We needed to reconcile performance and reusability.

Either this or what you plan to do with GraphQL are the only solutions I see for the performance problem (i.e. "too many requests, thus too many round trips, exacerbated by high latency").

Bild des Benutzers Sebastian Siemssen

Thanks for the link, Wim. Good read!

Crafting view-specific resources is certainly a lesser evil, but surely not the final solution. Maintaining view-specific resources comes at a high cost. Once you do this, you are again tightly coupling your front-end implementation with the backend. This drastically slows down development. Every change you make on either side of the application requires you to fiddle with the other side as well. You are going to slow down even further once the application reaches a certain complexity. Your application will also become more error-prone. It's a band-aid solution imho.

Bild des Benutzers Wim Leers

Oh, absolutely, this comes with a very high cost!

I wouldn't go so far as saying that any change on the back-end will need the front-end to be updated, but surely many kinds of changes would require that.

Related, but speaking more generically: all these downsides of decoupled (headless) Drupal/any CMS point to the appeal of an integrated solution like Drupal: the system is designed to be aware of changes in the configuration made by the site builder. I'm certain we could make the front-end (the JS) be aware of configuration changes in a similar way, but that'd require a lot of abstraction and code on the front-end. Which means more code to load, worse performance, and … not so much of an improvement. Most of the appeal from headless/decoupled Drupal is actually in the fact that as a front-end developer, you're completely in control again. Liberation from Drupal's concepts, coding patterns, coding standards, conventions, from all of it! But… all of that "baggage" actually is there for a reason: to have a translatable, overridable, customizable, configurable, accessible, *able system. You also said this, but I think it's worth stressing even more.

Right now, from what I can tell, the headless/decoupled Drupal "movement" (if that's the right word) is the effect that the "JS renaissance" has triggered with Drupal front-end people. It's an understandable reaction, coming in a large part from the typical frustrations front-end development in Drupal causes. But let's not forget why Drupal's front-end is the way it is: because it is designed to support site builders, who just click & configure everything together, without writing any code.
In other words: this is another instance of the everlasting "better code vs. configuration" (for developers vs site builders) and "better markup/CSS/JS vs. configuration" (for themers vs site builders) debate/tension. It is incredibly hard to support both configuration and simple/elegant code (front- or back-end) at the same time.
There's no reason why "regular Drupal" and "headless Drupal" cannot co-exist, and there are use cases for both. But it's definitely no silver bullet.

All that being said: I am hopeful that better solutions/approaches will arise from headless/decoupled Drupal :) At worst, we'll learn valuable lessons! This is a very interesting problem space to say the least.

P.S.: I think headless/decoupled Drupal in the forms that it exists today can be captured in a much simpler description: "Drupal as a structured content repository". That IMHO clarifies the extent to which Drupal itself is still involved in sites built this way.

Bild des Benutzers Wim Leers

One more thing: AFAIK almost every site out there that uses REST APIs doesn't solely use REST to build pages. It uses REST on the back-end, to talk to all the services necessary to build pages. And the JS on the front-end may very well use REST to perform certain actions, but usually not for the majority of content/interactions.

I wonder if you have counterexamples? Or do you agree with this observation?

Bild des Benutzers Jeff Eaton

Wim, I think you're definitely correct about the influence of the JS renaissance on the decoupled/headless movement. It's also important for folks with narrow use cases (the best ones for fully decoupled sites at the moment) to remember the range of use cases that Drupal's highly-coupled front and back ends are intended to cover.

In our experience, UI localization is one of the biggest adjustments: it's something that many Drupal front-enders have literally never had to deal with because of the supporting structure the tightly coupled solution provides. There are per-framework solutions, but they all mean that the front end team will end up taking much more responsibility for the nitty gritty of stuff like pluralization. (Yayyyyyy!)

Aggregating and pre-assembling assets per page-type (i.e., 'give me all of the stuff needed for an article page') is really effective, and doesn't have to be treated as a "re-coupling." I tend to think of it as just another component in a decoupled architecture. The "editorial and storage" layer supplies content and metadata for the "assembly" layer, which supplies efficiently-packaged resources for the "presentation" layer.

Finally, it's worth remembering that decoupling portions of the content management and delivery architecture isn't a new thing at all. Rather, it's a pendulum-swing in the decades-old evolution of digital publishing and content management. Drupal was one of the young upstarts that rose to prominence as the "decoupled era" was losing steam: the approaches made a lot of sense when web publishing was an adjunct to the "real" work that happened in print publishing systems. The dominance of the web made strongly-coupled systems more palatable, but today the growing important of multi-channel publishing is putting a lot of strain on web-first systems like Drupal.

That, I think, is where a lot of the interest in decoupling is coming from on the technical/tactical side. It brings lots of challenges, but they're challenges that mobile app teams and business API teams were having to grapple with on large projects anyways.

Bild des Benutzers Jeff Eaton

One last thought — it was mentioned that "editorial backend integration" was hard to accomplish with a decoupled system. I've actually been chatting with a group that built some fascinating solutions to that problem. Instead of killing themselves to tie the two layers together, they just passed the NID of each article to the front end, stuck it in a data-attribute, and installed a Chrome extension on each editor's machine that looked for the data attribute and enhanced their view of the public front page with editorial links derived from the nid. It was a really elegant solution that worked great for them, but it required getting out of the "slam it all into the HTML payload" mindset that strongly coupled systems make easy.

Bild des Benutzers Josh Koenig

Great post and great discussion. Amitai and I were just talking about this and want to represent this as part of our presentation at DrupalCon LA. Hopefully nobody minds if we lift some quotes? ;)

I realize the title is meant to be provocative, but I don't think you can call it a "lie" when people have been doing decoupled work with Drupal with great success for several years. However, the idea that this is a simple, straightforward thing is clearly not true.

To me the biggest benefit is that decoupling mandates that clear and effective decisions are made at a technical level about what a site is doing, and for whom. The architecture enforces the "separation of concerns", and pushes a ton of complexity to the front-end.

That can be a disaster if you can't/don't make the right decision, or if your front-end isn't up to the job. It's also a disaster for anyone to whom "there's a module for that" is frequently used to solve the growing needs of sites.

However, there's a reason the whole internet is moving in this direction: it makes amazing things possible, and it allows amazing developers to collaborate in ways that are not possible (or at least extremely difficult) when working on monolithic architectures.

Bild des Benutzers Sebastian Siemssen

Thanks for all the great comments so far. I am a bit busy right now due to some work related things that need to be solved before DevDays. Will join the discussion again during DevDays!

@Josh: Hey! Yes, this is definitely meant to be a provocative title. "The Cake is a Lie" is more targeted at the overall hype and the misconception that it spreads that "It's all fluffy and easy now!".

Of course it is possible, but people seem to forget that it is still extremely hard!

I had some weird nightmares after I overheard a few people at a local event talking about how they are planning to use Angular with Drupal 8 instead of Twig.

People seem to really think it's just that: Plug & Play. Nope.

Bild des Benutzers Yann

Hello, nice article. However there are some points i don't get…
- "Mutilingual" : yes we still can take advantage of drupal multilanguage system because we can serve differente resources depending on the language prefix in url, and we do have access to the "t()" function when generating resource.

  • "All modifications you make to your data schema or user interface are most likely going to require changes to your code on both sides of your application"

Your output is formatted json, so even if you database changes, you may ouput the same json to keep compatibility. And if you have normal drupal html, you do have to change both html and controllers if you are relying on a field name … so what's the difference ?

  • "It’s unlikely that you will have any linking between your backend and frontend making editorial tasks cumbersome."

You can request only published articles, non-blocked users, what you want and need; nothing complicated here, and so drupal backend become a strenght here, coupled to angularjs or Ionic.

"Application size and complexity"

This is true for both php & js, there is some things to learn but Drupal was not an example until there : he was juste loading ALL the php files (except include attributes in hook_menu), and have until D8 a awfull, awfull autoloading system (registry in database causing some very bad troubles and white screen of the death)

"however, this means that you are now relying on the browser for the rendering of your application. This is bad. Browsers change and so does Javascript."

I really don't get this one ! :) So is the html : we all are relying on browser to render drupal front-end html, and html is changing, and that's great, so what's the point here ?

I think one of the big point your are missing is that html-only front-end with some jquery is not sufficient anymore to build User interfaces today : user are expecting more and more all parts of the page to update automatically, and that's far more complex / time-consuming to build those kind of interfaces with htm / jquery today than in angular Js or such.

Web has so much changed, nobody calls it "web 3.0" but that's where we are and html / jquery is no more the more efficient way to achieve this.
In fact, javascript has so much changed that mots common methods of jQuery are NOT needed anymore.

Today websites looks more and more native OS applications, that's the whole point, and that's why weed need more and more stuff like angular JS, active, react etc …

Bild des Benutzers yann

"Also, security. Being left handling raw field values on the client side means you have to re-invent formatters in JS"

Or you may still use drupal formatters if you want to (in ouputted json)
Or you mat use sanitizer library from your client library js, or type "bower install blabla'", nothing to reinvents here, there are plenty of valid and easy solutions, using drupal or not for your goal.

Kommentar abgeben

Get in touch

Jetzt liegt es an Ihnen!
Nehmen Sie mit uns Kontakt auf.
Wir melden uns garantiert.