« A Serverless alternative to WordPress

In all my career I always had to battle with a WordPress installation, first it was my personal blog then it was the public facing website of companies I worked for. 
It’s not in the scope of this post to elicit the flaws and fragility of the WordPress platform, but my main drivers as CTO of Labrador were:

Aligned Tech Stack

Everything at Labrador is done in Node.JS and React.JS not only, we leverage as much as possible Cloud (AWS), FaaS (Lambdas): WordPress was far from this model and nobody in the tech team had PHP or WordPress administration skills, and, to be quite frank, nobody wanted to gain those skills.

Aligned and uniform Process
Sure, there are ways to do continuous delivery and integration with WordPress, but again we didn’t want to invest into this, we wanted to use our favourite tooling and model also to promote changes for the public facing website: a local dev environment, a non-production environment, a production environment, a continuous delivery pipeline powered by our ConcourseCI server.

More power and easier integration with other components

The User Journey was broken down in two: you’ll be in a slow, server side rendered page on WordPress and then taken into a sign-up journey running on React. 
We wanted to offer a more streamlined web experience and no jumps between domains or pages. 
Not only, because now we own the tech stack of our site and we are comfortable with the codebase we will be faster introducing new features, such as dynamic content powered by our own APIs.

So what’s the new tech stack like?

We generate our content inside Contentful, Contentful is configured to call one of our lambdas when new content gets published, Gatsby re-builds the site from scratch, publishes to S3 and invalidates a CloudFront Distribution. 
We are also leveraging GraphQL (to get the posts from Contentful) and Styled Components for styling the site: no more SASS or CSS, it’s all JS. 
There’s another little component: in order to serve folders we wrote a tiny Lambda that runs at Edge and basically rewrites the URLs (/page/ => /page/index.html). 
As any of our other lambdas this stack is monitored with IOPipe and the lambdas are configured, packaged and deployed using the Serverless Framework.

Architecture Diagram

Is it going to cost us more or less?

I’ve done some maths. The current hosting from WP-Engine costs about 999$ a year, that’s 2.7$ a day. 
Lambda edge costs $0.0000006 per request, in order to render the homepage we make 43 requests, it’s 1.4KB.
CloudFront is 0.68$ a month, assuming that the current site will consume the same bandwidth (I am sure it’s smaller), S3 will be pennies as well. 
So we’ll need 4.5M requests a day, that’s about 100k unique views a day on our side before the Serverless Implementation will be as expensive.

So I think that it will cost way less, also, the older site wouldn’t cope with that traffic! And we’ll be really lucky if we really get so many visitors!

Was it worth it?

Well we learnt a lot around Lambda running@Edge, Styled Components and GraphQL, Gatsby is lovely and we’ll now make the site better and better day by day without having to swear on how slow wp-admin is and we’ll just write code instead of installing plugins. We’ll also have no worries about upgrading WordPress or security and the pages are now honestly blazing fast, like 3x times faster!