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?"
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.
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.
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.
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.
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]?
Lessons learned and looking forward