Decoupled Drupal: Ashday.com has gone React!

Decoupled Deschmupled

Like many folks in the Drupal space we've been closely following the Decoupled Drupalconversation for the past few years, and occasionally a part of it. And, again like many folks in the Drupal space, until recently we had felt that it was somewhat in its infancy and a lot of tough questions still remained as to whether it was even a good idea. The SEO implications have not been entirely clear, the impact on estimation has also been very hard to nail down, which decoupled framework to go with has not at all been a consensus, and what Drupal’s exact role is in the decoupled site has not been clear either.

Choosing a JavaScript Framework: React vs Angular vs Ember

So likeStryder shuffling through the grassand reading the signs of what had happened to two of his favorite hobbits, we started to sense in the past year that maybe Decoupled Drupal was becoming suddenly not an odd-ball proposal but possibly a truly beneficial solution with a backbone. A key component for us?React. Heard of it? Probably. It’s been around fora few years now. The critical difference for us with this was momentum. After all, if you want to train up your staff on a whole new technology you better be certain it’s not dead in 12 months.

Let’s take a look at some Google Trends.

This is the last two quarters of 2017 Google Trends for the termsAngular, React andEmber, which were the three most talked about decoupled js libraries/frameworks atDrupalCon Baltimorelast year.

(blue = Angular, red = React, orange=Ember)

Result? Angular is solidly in first, React is reasonably behind in second, and Ember is a distant third. Hard to know where things are headed exactly, and coupling that with the fact that the theme in Baltimore was that Angular has the most attention, but people seemed divided about whether it was the long-term solution because React and Ember (and others) were growing trends. 3 distinct trending choices? Not sure which is best? And many were unsure this was even a good move, as were we. Better hold off a bit.

Now let’s look at the trends for 2018.

(blue = Angular, red = React, orange=Ember)

Notice a difference? Look at that little red bar now. That’s React. So even though just a year ago Angular held a reasonably strong lead, it definitely held true that some newer frameworks were gaining momentum, and React has already caught up with Angular. And further, Ember has fallen further behind. When you factor in how much of Google searching is people looking for support for something they’ve already built, which heavily favors the 5-years older Angular, that makes the React climb even more impressive. Does it mean Angular is dead? Far from it. But React is exploding.

Then there’s this:https://dri.es/drupal-looking-to-adopt-react. Yep, those chiefly interested in and responsible for Drupal are favoring React as well. Further, the general feel on the interwebs was that across all web technologies, decoupling was growing as a plausible solution in leaps and bounds. Great ideas were being kicked around about specific solutions to the hard decoupling problems. And above all, we’ve been looking for an excuse to give it a whirl. Well that just about solves it. If we’re going taking the plunge on this decoupling adventure, let’s just roll up our sleeves, install React, aggregate and distill our two years of thoughts on the matter, and cannonball into the deep end of Decoupled Drupal.

React and SEO

When you decide to decouple - even if you’ve already picked a js foundation to build it on - you quickly realize that the solutions are as varied and complex as they are on the back-end of sites. If you’re going with React like we did, then thatfortunately becomes much simplerstill requires a lot of investigation, learning, experimenting and decision making. In order to not be plagued with decision paralysis, we decided our top priority was ensuring that none of what we were about to do was going to hurt ourSEO. The flare and flash could come later. This was probably the one real deal-breaker for us in this endeavor.

SEO these days is rather complex and somewhat arbitrary, but there are some easy-to-overlook SEO principles when it comes to page rendering that must be addressed in a decoupled architecture. No one wants to tweak the heck out of their site and push on content editors to make sure everything is SEO friendly only to implement an architecture that keeps people from finding you. While a bit oversimplified, let’s look at three key principles that are to be followed when delivering page content if you don’t want to be punished.

The content needs to be delivered to search engines and users even without JavaScript.

The content needs to be delivered to search engines that do run JavaScript (i.e., Google), but won’t wait for asynchronous APIs to load.

The content delivered to search engines needs to match closely what site visitors receive so that we don’t get punished forcloaking.

There are a few approaches to this problem. And while “I quit” was certainly on the table for us, we pushed through and are glad we did. So let’s take a look at our more courageous options.

Client-side Rendering

This is effectively the coolest part of React, but you have to be careful of the implications, especially when content is dynamic. So for example, you can load your whole front end “shell” in React nearly instantly and then let things like dynamic header menus, page content, footer content, etc all load asynchronously as soon as it’s available. This creates some neat opportunities to improve user experience. The problem is the SEO implications. As stated above, you really can’t do asynchronous rendering and have it delivered that way to search engines, so now you’ve got a problem. For us, this meant choosing to use client-side rendering approaches where it benefitted actual user interaction and leave the rest to the server.

Pre-rendering

In this approach, your site is rendered statically on aNode.jsserver somewhere and the pages are served to the end user with no JavaScript required for initial page load. This leads to blazing fast pages as it’s just raw HTML/CSS/JS and no API calls on the fly, but it also leads to some significant downsides depending on your requirements. For example, in pre-rendering you are caching entire pages so if you have thousands of them, perhaps with varied caching control on various pieces of the pages to optimize performance, you now have a very heavy pre-rendering load. This means the task of updating your pre-rendered pages whenever any element of that page might change can become substantial and also complicate your CMS. For us, this wasn’t an option because even in building Ashday.com, we wanted to work with an approach that we felt could be adapted to our biggest clients.

Server-side Rendering

This is ultimately where we landed for ashday.com and we’ve been quite happy with it (so far). With server-side rendering, your pages are still “live”, but they are generated on the Node.js server when requested so that search engines and users get the same experience. It also allows us to handle the caching of various API calls separately so that we can get great performance. It’s not going to be quite as fast as pre-rendered, but then again we also don’t have to tackle the complex task of figuring out how any element of the site might affect a rendered page and be sure to appropriately - and in timely fashion - re-render all of those pages. So on a site with 50,000 articles, a change to a menu link in the header would mean re-rendering every page when using pre-rendering, but with server-side rendering, it just means a cache reset on a single API call to get menu links. It’s a fair trade off, we think.

So with all of that, we decided to build a React app usingNext.js. It’s not all that different from straight React, but it offers a few bells and whistles, notably the added synchronousgetInitialPropslifecycle method, that make server-side ren

dering a snap. Other approaches, such as using the defaultFacebook React app, seem much more suited for static non-API-based websites because you really end up needing to implement your own server-side solution where you separate your server configuration from your client configuration. Given that there are already so many new problems to solve and new concepts to learn, we settled on Next.js for now so that we could move forward and get our hands dirty without killing our Google juice.

As a side note:We’re pretty stubborn about wanting the best experience here though so we’re actually hoping that either the upcoming version of Next.js that includes React Router or else another evolving React-based solution will make it much easier out-of-the-box to build a React-solution that both renders server-side for initial page loads and lets the client run the show after that. As of yet, it’s a bumpy road to get there with existing tech and you have to evaluate the cost and overhead of trying to make that work.