Migrating from a conventional CMS to a decoupled technology stack!
How we migrated the main Comic Relief site over a 5 month period from Drupal 8 to a headless CMS and a more modern software stack (aka, JAM stack).
From “serverness” to serverless 🚀
Why move away from Drupal?👋
Initially, we thought we could iterate on our Drupal platform to move to the headless model. From Drupal 7 to Drupal 8, we have always been big advocates of Drupal and avid contributors to its community. After a long and happy relationship, we have decided to let it go and move on, despite having a very strong and capable platform, some of the constraints were becoming too much for us to keep the old stack.
“Regular core updates for security fixes, sometimes vital modules are no longer supported in the new version, or no longer maintained at all, requiring some bespoke patching.”
“Tied into the supplied template engine (Twig): flexible but often requires a lot of pre-processing and digging into render arrays to get exactly what is required for any one piece of work/design. Even simple fields provide a lot of stuff to the FE, which is customisable to some extent but still time consuming”
- Andy Phipps, Senior Eng.
What’s JAM stack?
“A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup”
- Mathias Biilmann (CEO & Co-founder of Netlify).
Why did we decide to go JAM?
Firstly, Part of our core strategy is to use Serverless technology wherever possible to reduce stress and the potential scaling issues that our night on TV creates. Read Caroline’s article (our Product Lead), to understand more about our approach “The real business value unlocked by going Serverless”.
Secondly, we wanted to focus on the core foundations of the web experience. We want to deliver a fast, reliable and accessible website to our users. Security, Performance, best practice and A11y are the attributes we value the most on every application we build. JAM stack provides us with all the tools we need to achieve that.
The cost was a big factor too. Our server cost was very high. To host our Drupal site, we were spending around £ 70k a year. Hosting static files in CloudFront, we are on track to reduce our costs by around 90% while improving reliability, scalability and performance.
Engineer Experience. The experience developing in a JAM stack is quite delightful. Our new setup is very attractive. We believe that to bring the best talent is important to stay relevant and updated with the latest technologies such as React and GraphQL. ( we are hiring 😃)
“Contentful is very user-friendly, without much overhead on development.”
“User experience improved a lot through serving less demanding static content.
- Mohamed Labib, Senior Eng.
Faster development time. Developing in headless CMS setup makes things easier and faster. Engineers do their work very independently and were able to add more components into the CMS than we previously achieved on the Drupal platform.
“Aligning the front end across our products and using Contentful has allowed us to give much greater flexibility for content management — tasks which previously had to be developed in code are now achievable for our content management team. This frees up engineering team time to work on improving accessibility and iterating on components to continually improve the site.”
- Caroline Rennie, Product Lead
New comicrelief.com 🎉
To manage our content we use Contentful as our headless CMS. To generate our frontend app we use Gatsby. To style our react component we use styled-components. To build our Component Library we use Styleguidist. To deploy our app Concourse CI / CD and to host our files we use AWS CloudFront.
Contentful. What once was different Drupal backends to manage content of our campaign websites. Now we have one content hub, very user-friendly, to deliver content to different applications across our organisation.
Gatsby. We wanted a framework to help us to focus on what matters the most to us, which is delivering content to our users in an interactive, clean and transparent way. And that’s what Gatsby provide us with.
Gatsby gives you easy access to features like modern Javascript syntax, code bundling and hot reloading, without having to maintain custom tooling. Build app-like experiences faster — with Gatsby.
Styled-components. Our CSS-in-JS library of choice made building our react components very fun. Once we made the transition from “modifiers CSS classes” to props we could be very creative and flexible with our components.
It’s very interesting to use props instead of classes to customise the behaviour of a component. All your styles are contained within your component so there is less risk to overwrite the style of other components. I really like the Jest integration and features like css nesting.
- Louis Tchamegni, Eng.
Styleguidist. To develop our react components in isolation we chose Styleguidist. It helped us to keep our code documented and tested. Easy way to share with the team and show our components variations and interactivity.
ConcourseCI. We have been using concourse CI for quite some time. We love to see our pipeline executing all our jobs, tasks, tests and notifications making sure our code is reliable and our site doesn’t degrade.
Tests. We use jest-styled-components to snapshot our component once it’s been tested. And in the app level, we use Cypress for our end-to-end testing.
CloudFront. Is our CDN (it speaks for itself).
Final thoughts
My experience in this project was great. I’d say if we were not using this selection of tools, frameworks and libraries we would not achieve what we did in the timeframe we had. Building our react styled-components in isolation on Styleguidist was a great way to keep us working in the frontend while we were still working out our backend integration.
Using GraphQL in Gatsby was so effective to pull the data we need and how we need it. Contentful and Gatsby work really well together.
Contentful richText field made it possible for us to use our “atoms” in our content models body fields.
And Gatsby just pulls it all together very nicely.
Our concerns were rapidly resolved. At first, we were worried about having to build our site for every content update but in the end, it meant we test every content that goes to production.
How did we migrate our content from Drupal to Contentful? We managed to migrate the majority of our content using contentful-migration. Having more them 3k pages, our initial build time was around 10mins. But with the latest Gatsby updates and some performance improvements that we made in our build process, we went down to 3mins.
Previewing content? Gatsby preview! It’s a quite recent feature, Gatsby team is doing an awesome job improving it almost day by day. Gatsby preview provides us with a temporary URL allowing us to preview our content changes almost immediately.
What’s even better now is how fast and smart we can deliver value to our product and it’s end-users. The team and our stakeholder are happy :)
That’s an overall of our new setup. I will be going in-depth on the use of each technology in future articles. Meanwhile, if you have any question about our tools and processes let me know! I will also be attending to React Summit in Amsterdam in case you wanna have a chat! Our friends can get 15% discount here 😃. Or to apply for Diversity scholarships for React Summit 2020 visit.
