In our first post that announced the new Mediacurrent redesign, we looked at the evolution of Mediacurrent.com over the years and talked through the over goals of the relaunch. Now let's take a look under the hood to see some of the cool stuff we did and discuss what our development team learned along the way.
Let's talk architecture
Now for the fun part, the technical architecture of the new website. First, the back end was upgraded from Drupal 7 to Drupal 8 - that will probably not be a huge shock to anyone. The more interesting aspect of this build is that we have now implemented a fully decoupled front end. We accomplished this using a static generator called Jekyll which has been integrated with the Drupal back end. More on that in a bit. First let's answer the question, "why decoupled?"
Why decoupled?
A decoupled architecture provides flexibility for constant evolution, opening the door to a variety of potential programming languages and design philosophies to accomplish your website goals. There are any number of articles that discuss the benefits of moving to a decoupled approach. For this post, I want to focus specifically on the points that were deciding factors for our team.
Security
While we do have full confidence in the security features that Drupal offers, we have to acknowledge that a static public site does offer some advantages that make securing the application easier. First of all, we have the option to make the back end CMS completely walled off from the public site. It's not a hard requirement that the Drupal admin is made publicly accessible. Second, there are simply fewer vulnerabilities that a static front end will be susceptible to in comparison to a full PHP application. For example, it's harder to DDOS a site serving only HTML/CSS/JS and there is no server side code running that could be hijacked by a SQL injection attack.
Performance
Decoupled sites often have a performance boost over a fully Drupal-rendered site because the front end is more custom and lightweight. This is certainly true in our case. The static front end requires no processing at the time of request so the page is served up immediately with no server-side execution required.
Hosting
One of the things we liked about this particular solution was that it made the hosting architecture pretty simple and inexpensive. With only editors logging into the CMS and the static site being served by Gitlab, we were able to have a fast, reliable stack up and running relatively easily. Up-time is great in that you aren't as vulnerable to a production error or traffic spike bringing the site down. That being said, all platforms are subject to downtime each year.
Eating our own dog food
As many other agencies will attest to, when you work on your own website it's a good chance to try something different! We looked at what some competitors had done and we wanted to try an approach that would be a good fit for our needs without over-complicating the end solution. This endeavor was a way to take some risks and learn along the way.
Dividing the work
The great thing about decoupling is that you break apart the work that needs to get done. The front end team can focus on the front end stuff without being tied too much to the back end work (although there will always be some overlap). Our agency spends a lot of our day delivering solutions to our clients so being able to break apart some of the work streams was an advantage. We like that in the future we don't necessarily need to do a big redesign and Drupal upgrade at the same time. With a decoupled approach, we have the flexibility to tackle each separately.
Technical Overview
Now that you've seen the "Why" behind this approach, let's look at the "How." We have kept our Drupal CMS in Bitbucket, which gets deployed to a Pantheon server. That piece is still the same as its been for many years. The new wrinkle is that the public frontend is served on GitLab Pages. If you haven't heard of Github Pages (which run on Jekyll), Github, GitLab and many other services allow you host Jekyll source files which they can auto-compile into HTML pages and host for you for free or cheap. Pretty neat huh? We ended up going with GitLab Pages because GitLab allows you to add more build customizations than Github. We have also looked at potentially using Netlify in the future as the host for our Jekyll files.
The question you might be asking is how does Drupal content make its way to GitLab? Put simply, we translate node content to markdown and push to the GitLab API on every node save. For user files, we actually still use Drupal uploads and reference the path within Markdown files. If you are familiar with Markdown files, these are the "content" files that Jekyll compiles into pages. The diagram below illustrates the basic flow.
The concept is pretty simple: have Drupal manage your content, write to Jekyll markdown files and deploy those files to a static host.
Why not [Insert favorite Node framework here]?
You might be saying, that's all well and good but why go with a static generator over a server-rendered JavaScript framework like Next.js or Nuxt.js?
The short answer is that we reviewed several options and concluded there wasn't a framework we felt was a fit at the time we were planning development (around mid-late 2016). Going with a JavaScript-only framework was ruled out for SEO reasons and the options for Isomorphic (server + client side js) frameworks weren't as stable as we would have liked. Jekyll was the most popular static framework (and still is) with a variety of plugins we could utilize. After doing some POC's we opted for Jekyll in order to keep the page rendering lean, simple, and speedy. The overall complexity of the integration was also a deciding factor in choosing Jekyll over other options.
Trade-offs
One of the fun challenges with a static only site is that you need to learn how to get around the lack of server side rendering. The files are of course static, thus if you want anything dynamic looking you are limited to mostly JavaScript-based solutions. A couple quick examples are forms and the site search. For forms, we were already using Pardot hosted forms for marketing automation, so that wasn't a big trade-off. For site search, we went with a pretty cool solution that leverages https://lunrjs.com/ to handle searching the site. Essentially we have Drupal push an index file that Lunr.js can search against using only JavaScript in the browser. For RSS, we still generate the RSS feed from Drupal and push to GitLab.
Lessons learned and looking forward
Now that we have the new site up and running, it's time to look ahead. Would we recommend taking this exact approach in 2018? I would say not exactly. While we are still intrigued by the power of static generators serving as a front end we think something like Gatsby.js (Node/React-based) might have more upside than Jekyll. Further, we aren't sold on this type of static-only being able to scale in comparison to Node-hosted solutions. The options for server-rendered JavaScript frameworks increase by the day and many have matured over the last few years. Mediacurrent.com will continue to be our place to try new approaches and share with you everything we've learned along the way. Thanks for joining us in this journey and enjoy the new site!