Serverless CMS - an introduction

Posted by James on September 8, 2019

Headless CMS

Like a lot of people, some of my earliest forays into web technology involved WordPress. In fact if you have a dig around on the WayBack Machine you might find some early examples from a decade or so ago. In fact, WordPress is probably one of the things that led me to become a PHP developer. A while after that I was quite heavily involved in moving Cancer Research UK’s site on to Drupal. Since then I’ve worked with Drupal in a lot of different settings, including a former Beatle’s fan forum. Lately I’ve been working on a fully headless Drupal 8 install. The architecture is quite heavily layered - we manage the content in Drupal 8, then index the content into an AWS ElasticSearch instance. We then have a layer of Node.js APIs hosted on AWS Lambda/API gateway, and finally an Angular Universal front end, which uses a custom Angular component library, to surface the content on the front end. 

It’s quite a complex architecture, and it took several people a lot of work to set up, but it has many advantages. It’s highly resilient, highly performant, and very flexible. This series of articles is my attempt to surface some of the lessons I’ve learned while helping to build and maintain it. 

Why headless?

You might be asking yourself if it’s worth going to the trouble of decoupling a CMS (or using a decoupled CMS and building an entire frontend). The answer - just like with everything in tech - is that it depends what you’re trying to do. If you’ve got a fairly standard flat content website, it’s probably not for you. But if you’ve got a bigger, more complex site, or one that changes frequently, the flexibility is a big plus

DXP 

Lately I’ve heard a lot of people talking about DXP instead of CMS. It stands (sort of) for Digital Experience Platform. I guess the distinction is that a CMS allows you to manage your flat content pages, while a DXP allows you to manage your end user’s entire digital experience. This might include e-Commerce, personalisation, interactions on social media or on custom apps and so on. And this might be where you really want the flexibility of a decoupled architecture. If your front end is separated from your CMS back end then you can easily slot in an e-Commerce journey, or push your content out to an app, or prototype new web experiences in different technologies. 

I hope you’ll also see, as these articles go on, how you can develop a production-line type development process for rapidly introducing new components. 

Why Contentful?

As with any major tech vertical, there’s a bewildering array of different systems you can use, and they’ll all have their pros and cons. While I’m fond of Drupal, the node object is very heavily nested for reasons that mainly have to do with how it behaves as part of a standard Drupal build, and I feel like I spend a lot of time writing code to flatten it down so it can be indexed and used in the APIs. Contentful does a lot of that for you. What’s more, it’s a SaaS/hosted solution. Pair this up with AWS’s serverless offerings for your front end and you’ve got a site that can support a good deal of complexity without you ever going near a server. 

What’s next? 

There are five more articles in this series, and I hope by the end you’ll feel comfortable setting up and deploying your own serverless CMS/DXP build. They cover: