You. Hey everyone, we're going to talk about WordPress and how we can scale it with nextJs. So who am I? I'm Colby Fayock. I'm the one hooking bb eight and Kylo Ren over there. I work with the dev community as a developer advocate. For applause comes 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 I would imagine some developers still cringe the thought of using 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, almost 35% of those websites are using WordPress. That's a huge percentage beyond a little dip between this and last year. It's been steadily growing since its inception. Built with is able to detect that it's being used on at least 28 million sites. That's a staggering number. And 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 jamstack sites in 2021. So to start, what does headless actually mean? With our traditional stack, somebody visits a page in the browser, that browser reaches out to the server. The server will do the work like request data from the database. Then they'll render that page for the HTML, which will be returned in the response and if we're lucky, it'll be cached. Finally, the browser displays that response to the person with a headless approach. That request to the server might be asynchronous on the client. In this particular example, the person would visit a page in their 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 in all that dynamic content. But I would imagine you're probably 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 even hits the browser, which has given rise to what people now call the Jamstack. Maybe you've heard of the Jamstack on Twitter, or maybe it's a completely new concept, but what actually is it at the core? Jamstack 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 typically give you that dynamic data. Or they can use those APIs at compile time and serve 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 use the WordPress API to provide that content and dynamic data. We would then compile that all down to a static site. Bring something like NextJs, which with a lot of other features is a static site generator. Now if this is all new to you, that sounds like a whole lot of work. Why not just use WordPress out of the box like we always do? Well, the great thing about Jamstack sites is they have a lot of compelling features 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 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 a server hit, which is prone to its ups and does. On the other hand, serving a plain static HTML file is just going to be fast. Instead of spending that time rendering on a server, you serve a static file straight from storage or a CDN. And while you can do this with the default WordPress instance, it's often much more complicated. And often some of those plugins that you'll use might cache and service a static HTML file, but they still serve it from a regular server, not static storage. With any server, we're also typically paying for how much we expect our traffic to be. While most of the time that is predictable, we all hope to have a post one day go viral. And if that happens, people visiting our site will be the ones paying for it with slow speeds or timeouts. Now there's solutions like load balancing and auto scaling, but those aren't perfect solutions and might not always handle a surge in traffic. Back to the fact that we're serving static HTML files because we're serving files straight from storage. Or better yet, files straight from a CDN buzzword alert. That means that our user facing website is going to infinitely scale. That static site will survive that Reddit hug of death when your post ultimately goes viral. And managing servers isn't always cheap. While a low traffic personal blog might be a few dollars a month. The more that traffic grows, the more that cost is going to quickly grow. While you have those options like load balancing and auto scaling, those services also quickly add up and without it you risk your site slowing down or worse, downtime. Storage is cheap. It's really, really cheap. We can maintain huge static projects on AWS using s three for a really low cost, but even if we still manage a server, the usage is going to be much, much lower with only content managers or requests that compile time. While there's a ton of headless options available in a headless world, WordPress still has a lot of compelling features to keep us from using it. Keep us to using it. One issue with a lot of the recent solutions is they tend to be really developer focused, and that's not necessarily a bad thing. But you have to know your audience. If your ultimate goal is for that CMS to be used by people who are non technical, you're providing can experience that people might struggle to actually 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 and there's a huge ecosystem already thriving around WordPress. If you run into an issue, you're more than likely able to find somebody else who ran into that exact 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 four seven WordPress by default now supports a rest API that means right out of the box WordPress can actually be used as a headless APIs. But taking that a step further, thanks to Jason Ball who created WP GraphQL along with all the other amazing contributors, it's a simple plugin that we can add right inside of our dashboard where we then have the ability to query all of our WordPress data with GraphQL. So coming full circle we can take advantage of this approach where we leverage those APIs at compile time to produce static websites rather than waiting for that server request, we'll have our entire WordPress site available as HTML documents. The cool thing is this will work with really whatever framework you want to use, as long as it can hidden APIs to compile those parts, we're good to go. But I'm particularly here to talk about how we can use it with next js for the unfamiliar. NexTJs is a react framework, gives you a whole lot of features on top of react, including things like routing and data fetching. The two main data fetching methods are get serverside props and get static props, and they pretty much sound like what they do with get serverside props. The app is going to render on the server, populating any dynamic data and sending it back inside that request. But instead I want to use get static props, where instead of my visitor hitting a server directly, I want them to get their request from static storage. Any request to a server will happen at compile time, or at least as many requests as I can reasonably make happen. That way our visitors are spending less time waiting for that request, and I've done just that with a project that I've been working on called Next JS WordPress starter, which lets anybody spin up a new static WordPress site with next JS super easily like you typically manage or expect from a WordPress blog. The homepage is full of most recent posts. I take advantage of get static props where I request all those posts at compile time that gets injected into the page, and then I can build out the page exactly how I want with pagination and everything. Now of course we want to make sure that we have the routes for all of those posts so we can take advantage of get static paths, which is how we can tell nextjs exactly what paths or routes that we want to actually get built during that compilation process. And once we define those paths, we can then look up the data for each one of those parts as a parameter inside of getstatic props. I would imagine someone would typically want search out of their WordPress site as well, and the WordPress API actually provides search capabilities. But like I mentioned earlier, I'm trying to statically compile this. So then I would be hitting a server which is kind of against the point of what I'm trying to do. So I took advantage of NextJs sitting on top of webpack and I created a webpack compiler as part of this project that fetches all the posts at compile time. It would then create a search index with the titles and the parts inside of a static file. It then loads that into memory or asynchronously on the client, depending on what you're trying to do, and we can make those searches right to that index. And with all that I was able to get together a WordPress statically compiled with next JS. The cool thing is we can couple this with WordPress plugins like Yoast and ACF, and this gives us a lot of flexibility with being able to manage our content. These work out of the box with our next JS WordPress starter. So I know you don't all want to just see a bunch of screenshots of some code, so let's actually do a quick walkthrough. So here's what we're going to go through. I'm going to first show you how easy it is to spin up a new WordPress site with next JS WordPress starter. But that project is probably a little bit too much code to try to walk through in this little talk. So I'm going to spin up a second next JS site where I'm going to walk you through something that works the same but a little bit simpler. So let's dive in. All right, so we're going to start off with this pretty basic example of a new WordPress instance where here I grab a new site from WP engine where I just have a few posts in here that I added has sample content. Personally I like to use Fillerrama IO as I love featureama and I also added some pages. And really just the point here is I'm showing you this, a vanilla example of WordPress where I don't really have anything on here and it's brand new, right? So what we want to do is we want to first see how we can actually query for our WordPress data and we're going to do that with graphql. So I'm going to head over to add new under plugins and I'm going to search for WP graphql which we can see that I've already been searching for, where once that comes up it's going to be the first option and I'm going to hit install. Now once that loads I can hit activate and we can see immediately on the side here we're going to get this new tab for graphql where I'm going to select the graphical ide. Now what this is going to give us is a way that we can actually explore all of our WordPress data and actually see what's available here. Now what we want to do is we want to ultimately query all of our posts, right? So we can actually just scroll right down here and I can find my posts and I can start expanding this where we can see on the right here it's actually building that query where I'm going to select the edges and the node and we can see all the data that's associated with that post. And let's say for example we're going to want our id and we're going to want the slug and we're going to want the title of that and eventually the content. But now if I click play we can see that I'm already going to get all that information about all those posts. We can even see that if I scroll up here and I select even the excerpt and the content when I click play again, I get that right inside of that request. Now we can see here that this is showing as an HTML string, which is how we're going to actually render it into our page as WordPress is going to be the one who still constructs what that looks like when it's actually sending that over through the request. So now that we have a good idea of how we can actually query our data, let's actually take this and use it in practice to spin up a new website. So over on GitHub I talked about my nextjs WordPress starter where here we're going to use it to easily spin up a new next js site with WordPress. Now if we scroll down here we can see that the first step here is we're going to use yarn create next app which is going to help us pull this project down as a template and get it started. It install the dependencies so that we can get immediately started with it. So the first thing I'm going to do is I'm going to copy that line and you can use Npm if you want. I prefer to use yarn, but right inside of my project I'm going to paste that in and I'm going to also add an additional parameter so that I can set the name of the project. Or if you don't it'll ask you for that later. But I'm going to say my WP graphql conf 42 app. So what that's going to do again is it's going to grab this template from GitHub, it's going to pull it down locally, it's going to install all the dependencies associated with that project. It's even going to reset git history so that you have a fresh new start for working with your new project. Now we're just seeing this loading depending on your Internet connection. Of course it's installing all those dependencies. But once we get up and running we can see what's actually happening here. So now we can see that it's finished and it's even giving us the instructions where first we can CD into that new directory. And before we actually run the development server, we have one more thing. And if we see on the left here it's setting this new environment variable to the WordPress GraphQL endpoint because ultimately we want to fetch the data of our WordPress instance, right? So what I'm going to do is I'm going to copy this string and I'm going to open this up inside of my code editor where as soon as this loads we can see that I have my new project and in the root of the project I'm going to create a new file. And that file I'm going to call env local and that's the nextjs convention for the local where it's automatically going to load this in a local environment. Then finally I'm going to paste in that environment variable. Now of course our site is a WordPress site so I'm going to head over to my WordPress instance and we're bring to grab the location that WordPress has installed it. And for me particular it's spacejellydemo wpengine.com. So I'm going to take that URL and I'm going to replace the WordPress site.com with that. And we can also see the GraphQL endpoint here. Now that's configurable but by default it's going to be available with WP GraphQl at graphql and that's what we're doing. So we have my WordPress address GraphQl and we're ready to go. So now that have that saved I can actually open back up my terminal and I'm going to run yarn dev. And what this is going to do is it's going to spin up a local development server for us. Now I'm going to start that. So it kicks off the process. But in the background what's going to happen is nextjs is going to go through and it's going to start trying to build this homepage for us and it's going to do a bunch of things in the background where it's going to actually grab that data that we want from WordPress so that it can actually build it and inject it into that page. The compile time that I was talking but before. But also we can see some other things going on here where as part of the starter it's also adding some other cool features like it's automatically generating social images so that when you share it on Twitter or Facebook it shows an image rather than just some blank empty text. And it also shows the WP search which is that index we were talking about earlier. We also have a sitemap and an RSS feed. But we can see in the left here that the site already loaded and we have all this content right inside of our project and we really didn't do much here. All we did was plug in our WordPress address and we now have this basic example of a blog. We can even see that if we go to one of these parts that it's going to do the same thing as it did for the homepage where it's first going to start compelling that page in the background. But it's going to load in all that data specifically for that post. And we can see that we have our post, it's looking pretty great and readable and we have all this by default right out of the box by just plugging in our WordPress address into the WordPress, the next JS WordPress starter. Now again, I mentioned that it's probably a little bit too much to try to dive in all straight into this particular project because there's a lot of moving pieces since it is trying to really represent a full WordPress site. Right? So we're going to use another starter and spin up a second project and we're bring to use the second starter that I made. It's just a basic starter where it's going to have the same kind of thing happening in the background where it's going to request that graphql data, but it's just a simpler example so we can actually visualize what's happening under the hood. So the first thing I'm going to do is I'm going to cancel out of that server and spin up one and I'm going to grab this address just like I did with the NextJs WordPress starter and I'm going to paste that in and let's call this my basic conf 42 app. And what that's going to do, again, similar to NexTJs, WordPress starter is going to pull down this template. It's going to install all the dependencies associated with the project. It's going to reset the git history and really just start us off with a brand new application where we can immediately get productive. So now again, I'm going to CD into this directory and just like before, we need to set that WordPress GraphQL endpoint. So I'm going to first open up this new project inside of my code editor. Then I'm going to switch over quick to my other project. I'm going to grab that same variable data and I'm going to create that new environment variable file just like we did over there so that now we're ready to go and I can hit yarn dev. And just like before it's going to give me a new local development server I can exit out of that other one. And in the background it's starting to compile that site just the same way, except there's just a lot less features in it and it's just a simpler example. So it's actually going to load a little bit faster for us that we'll see. But once it loads we're going to be able to see that again. We have this simple example where we're still grabbing dynamic WordPress data and we're adding it directly to the page where we can then easily get started with a new simple blog using Wp graphql on WordPress and nextjs. But let's actually see what's happening under the hood for this one. So if we open up the vs code we can see that like a typical nextjs project, we have some default pages out of the box. Now Nextjs uses file system based routing, which is awesome so that we can see under source pages we have our index js which is going to be our home page. And if we look at the top here we can see that this export default function home, this is going to be our react component or page component that we're actually using to render that page. And if you're already familiar with react, this isn't really anything special. We ultimately just have this react component that's going to render the page exactly how we want. But what is special is if we scroll all the was down to the bottom of the page we have this get static props function. Now if you remember from the talk part of this, we actually are going to use this to grab all the data that we want and inject it into the page. And as we can see here, we're using Apollo client or Apollo GraphQl client so that we can fetch all that data. And we're using a similar query to what we saw right inside of our WordPress when we were playing around with the Explorer. We're also grabbing a little extra data including the title and description. So we were able to show that up top. But ultimately we're grabbing all that post data. Then we can see that as we go down we're going to filter and clean up the data a little bit. We're going to pass that right in has a props object so that we can grab that into the page. If we scroll back up to the top we can see those exact same props. But then again, ultimately it's a react component that we're passing all that data to and that we're able to render it out exactly how we want using typical react code. And that's what's going to give us that home page where we can see it's just a list of posts and the title and the description right up top. Now, on top of that, we also want to render a page for every single post, right? So this is going to be another approach where if we look at this post directory here, we have this other file called post slug. Now, if you're new to nextjs, those brackets might look a little weird to you. And what those are doing is it's saying that post slug is going to be a parameter where the value of it is actually going to be variable, where we want to be able to make sure that we have our post collection, but we're going to have a unique slug or path for every single post that we have available. Now when we open up this page, we can see again that similar to the home page, there's nothing necessarily special about it from a react component standpoint. But if we scroll, scroll, scroll all the way down to the bottom, we're first going to see get static props. But let's scroll one more time and we can see that we have this get static paths. Now if you remember, this is going to be how we generate all those paths or the routes that we're going to tell next js that we want to actually be available for the project. So the first thing we do is we get all those posts and we're going to turn them into can array of paths where if we see here, we see this post slug parameter and we can see that's exactly how this is going to align with creating that dynamic content where we're saying we have all these paths and each of them have this unique slug that we want to be used when rendering that page. Now, once nextjs takes that array and actually goes to build out each page, it's going to run getstatic props for each one and it's going to pass in that exact same parameter, the post slug, so that we can then use it and pass it in as a dynamic value when we query our post, so that we can use the post to buy and we can use the slug as that option so that we can get that specific post. We can plug that in again as a prop into that react component. We're at the top of the page, we can see that we have those props and just like before, we're rendering it as a page. At that point it's just another react component where we're able to really do what we want. In this instance we're using that content and rendering in right inside as HTML. And if we look back at the browser, we can see that's exactly what's happening where we have all this data coming directly from WordPress that we were able to dynamically set up as a page. So the great thing about this is we can still leverage the great editing experience of WordPress. We can also take advantage of WP graphQl where we can easily build all these data relationships, whether we want to include the author or categories because it's a complex relationship and rest APIs really kind of struggle at that. But what we can do is we can take that all together, pull it into our next JS application and we can still build a site on the jamsack that's going to be performant cheap and it's going to be amazing. So next JS WordPress starter is available on GitHub for you to check out. So let's recap really quickly about what we actually achieved here. We reviewed our starting point, which was a basic WordPress instance. We set up our next JS WordPress starter. We even set up a second next JS site and we dug in a little bit about how that actually works. Now the goal here wasn't to get you all over to jump over to WordPress, but to show you the flexibility of it and why it's still compelling. Along with all the other amazing options out there, we can come up with some pretty powerful solutions that provide a great user experience while 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 how to actually do this in practice, you can check out my course ecommerce on the jamstack on level up tutorials where I walk you through how to use headless WordPress with NextJs. And that's it. If you want to learn more or chat about the talk again, I'm available everywhere. Colby Fayock you can check out the resources Colby fayock.com 42 and thanks everybody.