Scaling WordPress with Next.js

Hey everyone, we're going to talk about wordpress and how we can scale it with next.js. So who am I? I'm Colby Fayok. I'm the one hugging BB8 and Kylo Ren over there. I work with the dev community as a developer advocate for Apple tools. You can find me pretty much anywhere on the web by just Googling my name as I'm the only one in the world. So let's start off by addressing the CMS in the room. It's 2021 and some developers would cringe at the thought of wordpress, but frankly, we're still living in a wordpress world. According to Build with Trends, if we look at the CMS distribution of the top 1 million sites, 40% of websites are using wordpress. I'm not quite sure how accurate this number is, but if you look at the number of detections on the built with site, it's over 800 million installs of wordpress. That's a staggering number. While we might not all want to use wordpress, it's realistically around to stay for the foreseeable future. So let's talk about how we can take advantage of the King CMS in a headless way and use it to power our static jam stack sites in 2021. So to start, what does headless actually mean? With our traditional stack, somebody visits a page in the browser. The browser reaches out to the server. The server will do all the work like request data from our database, where it then returns the html for the page and returns a response. And if we're lucky, it'll return that cache. Finally, the browser displays that response to the person visiting the site. With a headless approach, that request to the server is asynchronous on the client. In this particular example, the person would visit a page in the browser and immediately get a response straight from storage. Once that page loads in the browser, the browser will kick off another request to a server, which can load all the dynamic content. But I would imagine you'd be wondering, why would we want to make a client side request to a CMS like wordpress? And that's not necessarily the recommended approach. That's where static site generators come in to do the hard lifting before your page is the browser, which is what has given rise to what people now call the jam stack. Maybe you've heard of the jam stack on Twitter, or maybe it's completely new, but what exactly is it? At the core, jam stack sites are static html websites. This isn't a new idea, but it's a modern approach. Typically, they use javascript in the browser to make any request to your APIs that would provide dynamic data, or they can use those APIs at compile time and serve that dynamic content without an extra client side request. One example that we can imagine is building a react application. This would serve as our javascript layer. We would want to use the wordpress api to provide the content and the dynamic data. We would compile that down to a static site using next.js or another tool, which along with a lot of other features is a static site generator. Now, if this is all new to you, it sounds like a lot of work. Why not just use wordpress out of the box like we always do? The great thing about jam stack sites is they have a lot of compelling features kind of built right in. By default, we're living up to what aws considers a well architected infrastructure. These are features that we all care about, like performance, reliability, and cost. With most of the server based solutions like wordpress, there are a lot of options to help speed things up. For wordpress specifically, that includes plugins to cache or some custom work under the hood. But each page is still a server hit, which is prone to its ups and downs. On the other hand, serving a plain static html file is just going to be fast. Instead of spending time rendering on a server, you serve a static file straight from storage or a CDN. While you can do this with a default wordpress, it's often a lot more complicated. And some of the plugins that cache might serve an html file, but they still serve it from a regular server, not storage. With any server, we're typically paying for how much we expect our traffic to be. While most of the time that's predictable, we all hope that one day one of our posts will go viral. And if that happens, the people visiting our site will be the ones paying for it with slow speeds and timeouts. There are solutions like load balancing and auto scaling, but those aren't perfect solutions and might not always handle a certain traffic. Back to the fact that we're serving static html files, because we're serving files straight from storage or better yet, static files directly from a CDN, buzzword alert, that means our user-facing website is going to infinitely scale. That static site will survive the Reddit hug of death when your post goes viral. But managing servers isn't always cheap. While a low traffic personal blog can manage a few dollars a month, the more that traffic grows, the more that cost is going to quickly grow. While you have options again like load balancing and auto scaling, those services quickly add up and without it, you risk your site slowing down or worse, downtime. Storage is really, really cheap. We can maintain huge static projects on aws using S3 for really low cost. But even if we still manage a server, that usage is going to be much, much lower with only content managers or requests at compile time. While there are a ton of headless solutions or options out there, it is a headless world where wordpress still has a lot of features that makes it compelling to use. One issue with a lot of the recent solutions is they seem to be very developer-focused. And that's not necessarily a bad thing, but you have to know your audience. If the ultimate goal is for the CMS to be used by people who are non-technical, you're providing an experience that people might struggle to learn and use. wordpress is the most used CMS in the industry. That means most of our clients are already going to be familiar with wordpress. There's a huge ecosystem already thriving around wordpress. If you run into an issue, you're more than likely able to find someone who already ran into that same issue with a simple Google search. We can also take advantage of a lot of community solutions that extend wordpress. All right. So if it's so great, let's actually see what this looks like. Since 4.7, wordpress by default now supports a REST api. This means right out of the box, wordpress is actually available as a headless api. But taking that a step further, thanks to Jason Ball, who created WPGraphQL, which is a plugin that we can add right inside of our wordpress dashboard, we have the ability to query our wordpress data with graphql. So coming full circle, we can take advantage of this approach where we leverage APIs at compile time to produce static websites. Rather than waiting for a server request, we'll have our entire wordpress site available as html documents. And I've done just that with next.js, where I've created a next.js wordpress starter, which lets anyone serve up a new static wordpress site with react framework next.js super easily. I've set this up so that on our homepage, when we're compiling the site, we first reach out to get the first set of posts, kind of like we would commonly see on a blog site. Those are passed as props to the page that's built out in react, where then I can create the UI however I want. Because next.js won't know the routes ahead of time with a dynamic route, we need to figure out all of those pages it needs to create. So we grab all of the posts, and then we create new paths for each one of those posts, telling next.js to create a new page for each one. And with all that, and a little bit of glossing over, I was able to get together a wordpress site statically compiled with next.js. The goal here wasn't to get you all to jump ship over to wordpress, but to show the flexibility of it and why it's still a compelling option along with all the others. We can come up with some pretty powerful solutions that provide a great user experience, while still also making it performant and cheap. If you want to check out my work, next.js wordpress Starter is completely open source on my GitHub. And if you want to learn more about the jamstack, you can check out my book at JAMstackhandbook.com. And that's it. If you want to learn more or chat about the talk, you can find me everywhere at Colby Fayok. My DMs are open. And I'll also tweet out a link with some of the stuff you've seen here today. Thanks everyone.