 Thank you all very much for having me speak today. WordCamp Dayton in 2015 was actually my very first WordCamp ever. At the time I was the happiest engineer for automatic and budding front-end developer and was just kind of getting thrown into how great WordPress was. And this event in 2015 really was a turning point to realize exactly how important the community is in WordPress and how much the community drives the future of the web. And it was a life-changing event without hyperbole. So thank you all very much for having me in the community and I'm really excited to now get to speak at this great event. So my talk today is Blazantly Fast Freedom, which is a very silly phrase that I've been thinking about for several months. Which is basically using headless WordPress and GatsbyJS. If you want to follow the kind of folks that like to go along with everything you can go to wcdatant2019.alexjagustin.tech. It's these exact slides. That's what I'm running off of. Hope it doesn't crash. Let's see how it goes. Essentially what we're going to go through is discuss what this idea of running headless WordPress with Gatsby is. Doing a quick setup of what it will look like in the end. A few pointers on how you can get started with Gatsby once you have that project running. And a lot to consider that you can then just take this on your own projects going forward if you want. Can I just get a quick show of hands in the room? How many folks in here would identify as a developer? Good. This is definitely a topic that we could do for six hours instead of 30 minutes. And I'm not going to be going that deep into it. This is going to be a, hey, if this sounds like what you want to get into, hopefully it's a good starting point and then you can go off to the races yourself. And if it seems like it's not for you, it's probably not. This is either something that it's been polarizing for a lot of folks. Either it's like, this is a great opportunity and I really want to learn how to do this. Or it's a, you know what, not for me. And we'll see who you are at the end of the talk. But we'll just get started with this. So first off is just what is this blazingly fast freedom? And in short, the freedom part is WordPress. And that's why we're here. That's why this is a WordCamp talk. There's a reason why WordPress is a third of the web. Because when you and I and the rest of the community contribute to WordPress, we're doing it with the idea of freeing up and empowering content creators in mind. WordPress always should be made with the idea of allowing freedom across the web for everybody. The mission of WordPress is democratizing publishing. And Matt recently published that an update to what that mission means to him in 2018. It means that people of all backgrounds, interests and abilities should be able to access free as in speech software that empowers them to express themselves on the open web and to own their content. So long as we are developing sites with that freedom in mind, I think it is a great thing for everyone, and it's certainly among the goal of WordPress. Interesting, though, there is nothing here that says, by golly, we should use PHP templates. There's nothing here that says, by golly, it should all be in one WordPress repo every time, and that's the way it should be done. That's not what the point of WordPress is. The point of WordPress is freedom and empowerment is not about any particular technology stack. With that in mind, there is a tool that, as I was learning JavaScript deeply, I kind of fell in love with, and a lot of the JavaScript community is falling in love with, called Gatsby.js. And of the Blazingly Fast Freedom, Gatsby is the Blazingly Fast part. If you go to gatsbyjs.org, they say Blazing Fast Sites. I like adverbs, so I go Blazingly. That's just the way I go. But all Gatsby.js really is, is a static site generator. You can use any kind of data you want. You can even use markdown files on your local computer, but you can develop a site with Gatsby, and it will fetch data. It will do transformations. You can use NPM packages. You can do whatever you want. But in the end, it's going to spit out static files. And if you think about it, if you had a quest to make the fastest site possible, you could. If I say you have to have some JavaScript, some CSS, but you have to give you a website, what would you do to make it as fast as possible? Well, one, I might try to make it as small as possible. What if I could just have an index.html file that has some inline script tag at the bottom that does a console log. It has an inline style tag at the top that just has a tiny little bit, and it will run. Great. Now it's really stinking fast. I can put it up on a server. I can put a CDN in front of it. That one static file doesn't take hardly anything from our web server to load, right? We all agree there. Static file is pretty awesome. As soon as you have 500 of them, man, static files are not fun. And that's why we've kind of gone through this evolution over the last couple decades of CMSs, of all these different frameworks of making, letting servers generate these pages for us as opposed to managing files. Gatsby is kind of this play of what's now being called the Jamstack, JavaScript, APIs, and Markup. But this is a server-side-reader approach. We're going to that Jamstack application, but all we really want is a bunch of static files at the end. So if you're using Gatsby theoretically, you could just run it all on your computer, run Gatsby build on your computer, push all those files up into any server you want, and it's going to work great. But if you stop there, it's what are you going to do whenever you want to add more data? You're going to have to open up your project again. You have to be a developer to do this stuff. That is not empowering. Knowing that you have to be part of a JavaScript community, that you have to be identified as a developer, you have to use a text editor, and get and all this stuff, that's not empowering at all. So even the Gatsby folks, when they were looking to make this tool, the reason it came about was they looked at three things that on the web were evolving very rapidly. Headless CMSs, modern development tools, and the need for website performance. As more people around the globe need to access websites and they may or may not have great connections to do it, the need to be able to load the website fast and more valuable to them, and therefore more and more valuable to the people that are needing to serve them. There's more and more developers that are trying to create more and more sites. We need a great developer experience when we're making them. And there's still content creators that need to edit that content, that need to be able to manage it, that don't have the technological expertise to be making the sites the way a developer does. So what's in the middle? And Gatsby is trying to be that tool that is helping all three of them connect. This is Dome Little World. It's a completely different community from WordPress, but I think WordPress fits very nicely on the Headless CMS side of this stack. There's a lot of people in the Gatsby world will go to things like using Sanity or Contentful, and there's something wrong with any of those. I uniquely feel that WordPress has the motivations of content creators in mind more than anybody because of that mission of freedom, that mission of empowerment, that when changes are made to WordPress, I'm making sure content creators are getting the best experience possible. And if that means that I have to develop my modern tools in a way that adopts for that, great. I want that burden on me as a developer. So that's why I started thinking about this stack has blazingly fast freedom because I get all the blazingly fast stuff of Gatsby. I get the freedom of WordPress and I get to spread that message around and something I really believe in and something that I think is really great for the world. But in the end it boils down to using WordPress and using Gatsby. That's blazingly fast freedom. So now we're just going to do a simple what this basically looks like. If you're of the camp that wants to follow along I've already got an example site up that's running it's not beautiful. The intent was not to be beautiful, it would be like what you can get at in one session if you want to start running this up yourself. But the goal of this setup is Gatsby is basically your project that you're going to be working on and it's going to talk to a live WordPress site. And that WordPress site is meant for holding data. It's meant for your content creators to go in and add a blog post, edit a blog post, add a page, edit a page, delete a page. If you want to do all that stuff that we do in the back end of WordPress but we're not going to use the theme template hierarchy. We don't have to use the theme at all. We're going to use Gatsby to make that front end instead. So start with you're going to want to install WordPress. You can do this on your local machine for the sake of an example or somewhere. For ease of making sure this is all wrapped up in your mind, I like putting it on a subdome. So my example that I've got is going to be on wp.widget.pet Widget is my dog. She loves WordPress too. So right now I've got the site up and it's just running 2019. It's just stock. It's got some blog posts. It's got some pages. Nothing crazy going on there. But I'm just going to use it for the data and I'm just going to talk to it through the rest API. You can host this WordPress site anywhere. Put it on any server you want. You can do WordPress.com even. I would avoid using any plugins until you start getting rolling, particularly if it's not about storing data. So the way you will in plugin I would allow is or you can do whatever you want to your site. I don't have to allow anything. But advanced custom builds is pretty useful with doing this stuff. And I'll show you something that you can turn off. You can use advanced custom builds. But then something like a form builder is maybe not going to be as useful. We're not using the WordPress right then. So I'm probably going to set up a form on my own in my Gatsby project. So step one, set up WordPress. Host it somewhere. Step two is getting your Gatsby development environment running. Node, MPM, and Git. All pretty standard for doing development work. If you've not gotten used to using Node, MPM, and Git, this is not the talk to walk through that. If you click this documentation link, though, that will point you to the Gatsby CLI section. It's actually part of a long tutorial of all of this. So if you've never installed Node, never installed MPM, you can still walk through that. Essentially, there's command line tools to get things running on your computer. And then Git is version control. But you're going to want running because we're going to use a Git repo in the cloud. Gatsby CLI, though, probably not everybody has going. So there's a couple of ways that you can use it. One is to install it globally. You can get it off MPM, Gatsby, and CLI. Or you can use MPX, now that that's a thing. And that's going to give you a couple of new command lines, commands. Gatsby new, Gatsby develop, and Gatsby built. That's to create a new Gatsby project. Kind of like how you might create a new Create React app project. To start up your development environment where you get local host hot reloading and it'll do all your queries and it'll update, as you update data, it'll go ahead and update your development screen for you. It's pretty sweet. And Gatsby built. That actual process of making all your static files that you can then push up to a server somewhere. Once you have all four of those running, the same way you might need to pick a theme in WordPress, you're going to pick a starter in Gatsby. It's not quite exactly the same thing, but this is all your boilerplate code. It's just what gets you going. There are starters that do nothing but print hello world out to the page, and then you can do it all yourself, but the file structure is there for you. This is a good starter to go with just for this talk. That's what I use for my example site, only because they have already printed a lot of stuff out of the box that will talk to your WordPress site if you just give it the URL, grab all the pages, grab all the posts, grab all the categories, do all that stuff for you, and it's a great example of how to get started with this stack. So let's even look at this for a moment. This is the Gatsby starter library. So in the end, once we get this all rolling, you're basically going to end up with a site like this, where it's going to grab all the pages from your WordPress and spit it out into a navigation. It'll grab all your latest posts and put in a blog-like layout. The way you would get it going is running Gatsby new. Again, that's after you have Gatsby CLI installed, the name of your project, and employing the source of this starter. You can choose any starter you want once you're comfortable with all this. This is just a good starter for now, and it's what I've got my example site using. One nitpick for the starter, though, is on that WordPress site you set up, you have to make sure you have at least one post, and at least one post needs to have a tag on it. I don't know why the tag thing, but just the transformer they built, you can do that. Make sure you leave the starter post on there and add a tag to it. Then when you run the starter, you'll be gold. Once you have your development environment set up, you're going to open up one of the files in the root directory called gatsbyconfig.js. Kind of like WPconfig in a standard WordPress site. This is all the stuff that Gatsby needs just to even get running. When you add plugins, what to talk about in a second, you're going to add those in here. The way this starter already has a bunch of plugins running already, it definitely changes the base URL. In this case, I put in my WordPress site to wp.widget.pet. You put in wherever you've installed your WordPress site. If you're hosting it on WordPress.com, just set that to true. If you're using advanced custom builds, set that to true. The starter will then kick off from there. The config is something you're going to be editing as you add more plugins and new features later on, but this is just to get you started. Once you have that, you're here at that point. You can run gatsby develop. All the build processes will kick in. It'll give you a local host URL that you can work on. Just look at this example. After that, you want to put it up to GitHub. If you want to, you can get a bit bucket of those fine too. In this world, GitHub is kind of the standard. A lot of the hosts that specialize in helping with gatsby tools have a lot more integrations with GitHub. Just kind of the way to go. If you want to check out my example site one, it is there. You're going to want to have a continuous integration. Here's what I mean by that. If you were to just build all the files on your computer, you could put all of them into an Amazon S3 bucket and just storage. You can point your domain to that S3 bucket and it'll all work. It'll be great. What happens then if you make a new blog post on your WordPress site? You have to open up your computer. You have to run gatsby build. You have to push all those files back up to S3 again. Ain't nobody got time for that. The right way, which is we're going to tell a server, hey, whenever I tell you to run this gatsby build, push all that and we're going to serve all that stuff out. Every time we need to change it, we're going to change it. You can do this in an infinite number of ways, an infinite number of services. You can roll your own if you want. The website of this example site is using a host called Netlify, which is basically a host and continuous integration bundled all in one. They give you a webhook where you can trigger that build process from anywhere you want. It'll also connect to a GitHub repo, so any time you change that repo, it'll update. With that in mind, on your WordPress site, you're going to want to add a deploy plugin. Some way that your content creator can make changes, trigger a deploy, and it will tell your host to run that gatsby build process. This is the wild rest right now. There's maybe a dozen or so plugins, if you search around on GitHub, that will accomplish something of this nature. I don't like any of them. I like building my own, and I don't like any of those either, so I'm not going to recommend them to my own. This is the one that I actually use when I'm doing this, particularly because it works really well with Netlify. It kind of follows the give you a big button approach. Whenever you're in WordPress and I add a new post, or I edit a post, or I add a new page, or I delete something, after I've done all my stuff that I want to do, I can just do one big deploy, push the build site button, and it'll hook up to my Netlify after I give it all my information. So with that in mind, let's actually just give it a try for a second. So this is the current build. Oh my gosh, it's not what to look at, because this is just what the starter gave me. I didn't add any extra styles or anything like that. I changed out all the names of the developer that created the starter just to make it good dog widget, the name of the site instead. But you can see that it's loads really snappy, and that's really the advantage of using gatsby, is this quick performance everywhere. But then on the WP side, it looks completely different because this is running 2019. I could port over all those styles into here and try to make it match as close as possible, but the point is it really doesn't matter what's running on your WordPress site, because we're not going to use this front end at all. In a real production situation, I'd actually just adjust my theme that if anyone ends up looking at this site, I'm going to forward them onto my real gatsby site. But just for trying out something, let's add a new page. Cool, so I published this page, nothing's going to happen yet because I have to deploy this out. So I'm going to go to my deploy, and I'm going to hit build site. I've already done all the stuff that will connect this to my Netlify hosting, and it's currently building. So on this side, I've found it's taking about a minute or so to build. So while that goes, here's what it would look like on the Netlify end. So if you use a different host, or if you roll your own, obviously this could look a little differently, but the idea is, I can trigger any number of deploys I want from WordPress, and on my hosting it'll update. It'll run that gatsby build process to serve up the new files instead, purge all the caches, all that stuff. If I did any change to my GitHub repo, if I changed the template, I added a new class, and I was watching on a massive branch, and it was rebuild then. So any time either developer or content creator is making a change, it's just automatically rebuilding all the site for me. Pretty cool. So I get all the advantages of that static build just by adding some processes, isn't it? Cool. So now that was a success, so that took a little less than a minute maybe, and let's just refresh, and there's how you work camp dating. New, big deal. Right? Now, that is still not a zero amount of time, and as the site gets bigger, it might take a little more. I would say on a typical WordPress site, if you're thinking just like a blogger, we're going to have updating a new blog post every day or so, it would not be strange to me if this build time gets more to five or six minutes instead of a minute. On a really quick site, if you're hitting a private API and it's really nicely made, it might be more like 20 seconds. But that's going to be one of the determinations of whether or not this stack is actually a good fit for you. If you're running TechCrunch and you're having new articles come out every 30 seconds from a billion different authors, that rebuild is going to take longer than it takes to keep updating the content. All of a sudden, it's not worth that time. I'd rather have that 30 seconds of the article being up than waiting for it to rebuild again, because I've got other tools too, right? There's other stacks available. But this is one of the quirks of GACPy is having to trigger that rebuild, but you get all the performance benefits afterwards. My general rule of thumb has been, if it's something that's going to update irregularly or only a couple of times a day, this is a really great thing to reach for. But yeah, that's essentially what we're looking at. So I was using Netlify as the host there. You can really host these GACPy sites anywhere. They're going to run fast on anything because it's just static pages. It's hard to make them run slow, really. So what you're going to want to make your choices of where to host is, is based on that continuous integration. How much of that work are you excited to do on your own, versus how much do you want another host that's kind of in this world to do it for you? And it's kind of developing. This is going to look like the Wild West kind of area right now. So this is a lot of great docs. I think a lot of people are kind of going towards either Netlify or to doing AWS, if you're going to be doing a lot of other Lambda functions and stuff like that. That's just kind of my read on the situation. Okay, so we have our WordPress site. That's running that we're just using for holding and fetching data. We have our GACPy site that's reading all that stuff. What is it actually like to be working in this? Well, if you're used to making a React application, it kind of feels the same. So for example, this is the template that's going to run for any given page. Whenever GACPy builds, it's going through and fetching everything in the API. It's going to create a new page for all pages it finds. And it's going to throw all that into the context of this template. And this is a very simple template because it just does in class names, but this is just a very typical Reacty feel of JSX. So anything you want to do in Reacty, basically you can just go for it at this point in GACPy. But I want to go through some of the kind of GACPy quirks and fundamentals. So when making a React application, you're going to be used to using Yarn or MPM to add in modules all the time, right? And for the most part, you just do MPM install, Garn install, and then follow documentation of what it says of how to implement it in your application, appropriate place in your application. The quirk about this in GACPy is, so many of the things that GACPy will do for you for these performance applications happen during that build step. So when GACPy does push up the file, it comes with a React runtime. So you can use almost any module you would use in a React application. But if it's something that's going to be about transforming that data or working with the data, you want to look for a GACPy analogous plugin to go along with it. So for instance, if you're using React Helmet, there's also a GACPy React Helmet that you want to configure into your project. And the way that it looks like is, in that GACPy config file, you'll find an array of plugins. A lot of the plugins are just going to be those one-liners naming what the module name is, and then you get that module's features. Great. Some of them are a little more complex, but you also have to pass in options. So for example, that GACPy source WordPress we were looking at, it's not enough just to have that one line of GACPy source WordPress, we have to resolve that, and then also pass in the object of options for the base URL, whether it's hosting on WordPress.com or not, whether it's using advanced custom fields or not. Different plugins are just going to have different amounts of complexity there. But that's something you're going to have to get used to is as you find a new module that you want to use, make advantage of it, is adding into your GACPy config if you're in your local event, development server, trigger rebuild, watching for it when it goes to production. There are a couple of phrases when you're looking at plugins that you're going to find, source plugins. It basically just means this is a plugin that's intention is to fetch data from somewhere. So GACPy source WordPress is a plugin, but it's a plugin that's meant about getting the data out of the WordPress API. A transform plugin is a plugin to be used usually in coordination with some particular source plugin, where after we've gotten that data, how does GACPy expect it to be formatted and put it into all the magic that it's going to do? To be honest, there's great documentation on how to author source plugins to transform plugins. It is not something I've gotten into very much yet, so if you're expecting to have that magic revealed, I'm sorry, I'm just not ready for it. But that's something you're going to run into a lot as you're searching through plugins. If you find source or transform in there, that's all it's referring to. So GraphQL, again, another topic that would be great for a workshop or a few hour long talk. We're not going to get too much of the weeds on it, but you're going to see it a lot as you're going to GACPy because it's the query language that is actually how GACPy is managing data. We'll talk in a second how you don't actually have to use GraphQL, but most of the starters that you're going to be downloading are going to be using it. So for example, if we keep looking at that, paste the JS, this is actually at the very bottom of the file. But this is our GraphQL query. The idea of it is it looks kind of like JSON, but it's not JSON, it's just how GraphQL query language works. But the goal of this is to, when I run my query for a WordPress page, I want the title and the content and only the title and the content. When we're working with the REST API, we're hitting our endpoint and we're going to get back way more information that we need and then it's up to us to kind of map through it and find what we want and spit it out. The goal of GraphQL is to have no over-fetching at all. And it works really well during this build process because we are essentially doing that over-fetching first when it's not affecting our user at all. It's doing over-fetching during the build, sorting down to exactly what we want, and then it's easy to make the templates work nicely. So you're going to run into those GraphQL queries and you might be asking yourself, well that's great, it looks for something straightforward to get a WordPress page, buy an ID, and receive its title and content, but how in the heck did you know to make that query like that? Well the good news is your Gatsby project ships with GraphQL, which is an ID for how you can search out and find these GraphQL queries. Once you have your source plugins running and it's fetching this information, you restart your develop server, one of the links that Gatsby develop will give you is a link to your GraphQL where as you try out queries on the left panel, you'll get the definitions of how those queries work on the right and then you can test them out and see examples of what you'd get. So for example, if I just started off with a query that's looking for WordPress page, I would get all these definitions on the right for WordPress page and I would say, oh I don't have to just get title and ID, I can also get the date, I can get the type, I can get the content, the excerpt, its parent, its ping status if I want to check for that, and I can put all those in my query. So then I updated my query on the left to not just be title and ID, but then date and slug and status and type. On that page.js, it has, there's kind of a context to this template of passing an ID into it, so when it's running this query, it's looking for only a WordPress page where its ID is equal to the ID we're passing. So for the heck of getting a nice result here on the right, I passed in the exact idea of that about widget page. I can see exactly what we can get. If I want to query data on my template, I know what happens when I go to data WordPress page title ID date and if I ever just want to never have data, I can keep my code really clear by never querying for date. So again, GraphQL kind of its own budding world that Gatsby just makes use of. You're going to run into it a lot though as you try out a bunch of different Gatsby starters or make use of source plugins. That's kind of the default in Gatsby world. But if you don't want to use GraphQL, you can always use unstructured data, which is basically just a fancy way of saying you can fetch data however you want it and there's an API for creating pages. Normally in Gatsby, if you have a file in the pages directory, then it'll create a page for all of those. But whenever we're fetching from outside of Tor, so we're using this create pages API to pass a context to a template and spit it out for as many pages as we need. And with that in mind, why can't we do that with the WordPress API? That's what this starter is actually doing. It's actually doing the REST API and turning it into GraphQL so that you can use a GraphQL query. You could have just as easily skipped that GraphQL stuff. You can query the REST API on your own and just get an array of posts and map through them and use this create pages API on your own. So whenever you're working with a private API or if you're just wanting to get used to Gatsby the first time and not learn GraphQL to use Gatsby, unstructured data is a really great way to do that. And this page is a really good approach for it. It uses the Pokemon API, so it's a lot of fun to work through. Links. One of the great things about Gatsby is that it does prefetching based on intersection observers. So whenever it will not prefetch a pages link to until the link is on the page and even then it has like a hierarchical sense of which links are more important. So something that waits until you're actually hovering over. But it's really great that as soon as the user is hovering over a link, it starts prefetching that page because it's a good chance you're going to be loading that page soon. One of the ways it does that though is with this link component. Anything that's internal to your site instead of using an A with an href, use a link with a capital L and put it on the route and Gatsby will do some magic with this. If you use an anchor tag like normal, it will still work. That's what you should do for external links. But Gatsby does some great stuff with link. So yeah, from there on out, just treat it like a React app. You can do components, do nested components, you can do modular CSS, you can add in packages. Gatsby is just React at the end of the day. It's static files with a React runtime. So treat it like React app, you won't go too wrong. A few minutes just on pros and cons. So like I said before, if this sounds exciting and it sounds like, ooh, I really want to learn more about this, this is for you and I hope you'll learn more about it. If this sounds like, oh, this is not like what I'm wanting. This doesn't seem like it solves my problem. Great, it probably doesn't solve your problem because it does come with it instead of problems. That rebuild can be annoying under some circumstances. It's very JS heavy on the developer side and if you're not wanting to have that JavaScript feel, it's not going to be that great developer experience. And the whole point is to have a great developer experience, a great content creator experience, and a great site visitor experience. And you can get that in any number of stacks. So the idea that it doesn't feel like WordPress is only because we're keeping WordPress for the content creator that it was going to get the most valuable out of it. But if you really like the way that WordPress Tempani works or you really wanted to focus on PHP, great. So long as we're all agreeing that we should be making sure that all three of those stakeholders are having great experience, that's exactly it. I would say the biggest reason that most people are going to find a problem with getting this is because the hosting setup feels really complicated. And I think we're going to see more and more hosts like Netlify that are trying to make this easy out of the box. And that way you can have more options than just Netlify or just a particular AWS app that you can roll on your own. But it's hard to convince a client, necessarily, that this isn't their best interest to have a twice as complicated hosting setup once to get all these benefits in the future. Especially when a lot of those benefits from the hosting side end up being for the end user and not necessarily for them. Even the idea that now you're going to have to push a button twice, or you have to push the deploy button after you make all your changes feels like a hassle even though you get all the good stuff from it. So there's lots of pros and cons to weigh. I would follow your intuition. If you really like this idea of doing what WordPress does best with that content creator experience in WordPress and then getting to use React, if that is like the selling point for you, this is absolutely a thing to look into. If getting to use React sounds horrible, it's not going to be fun because it is React to the core. So at the end, some advanced stuff, if you really want to go deeper and deeper, if you like the GraphQL side, Jason Ball has been doing WP GraphQL for a little while now. It's still officially embedded, but there's a lot of production sites using WP GraphQL. That starter is hitting the REST API and transforming it into GraphQL. WP GraphQL lets you just make a GraphQL query directly to your WordPress site. It is running its own, it's like a completely separate API from the REST API. So if you really want to get into the GraphQL side of things, that is kind of the plug-in to do right now. I mentioned that starter and theme is not exactly the same thing because a starter in Gatsby is kind of like create React app on the React site. It's just a bunch of boilerplate code that you're going to use that one time built on top of it and you're going to fire up a whole new one next time you start. Gatsby has started working on what they're calling themes. The idea that it's a starter, but it's also going to have update capabilities you can use across multiple sites more in the way that we treat kind of WordPress themes. And on top of that, Zach Gordon recently announced that they're starting a project of porting a bunch of WordPress themes into Gatsby themes. So like 2019. This is a very exciting thing. It's still developed. None of these are actually released yet, but it's something to absolutely watch. Not least because, remember where I said we're not really wanting to look at that WordPress site for the front-end? Well, if your Gatsby theme matches up with your WordPress theme, all of a sudden now you can use WordPress Preview and it's okay if the conductors are just working on the WordPress side and you're just working on the Gatsby side. If we can have Gatsby themes that are running in parallel with WordPress themes, then every time a WordPress theme becomes popular, that Gatsby theme becomes popular and that's now another tool you can use if this building approach is useful for you. So a lot of potential there, but still kind of growing. I recommended using your WordPress site on a subdomain and your Gatsby app on the main domain you're using, which is actually probably most fun if you're willing to get into the weeds a little bit, is having a mono repo where you can run your WordPress site out of that same GitHub repo, but you can then make use of your functions file and add plugins, whatever to do, AJAX request, whatever you need to do and have that available to you as a server option, so you don't have to go to using Lambda functions or anything else. If you want that server side capability, you have that server running and it's on your domain and you can do that by just hooking up your engine X to look at different ports. That's a really fun way to go about it, but it requires some management. Again, on the hosting side. The hosting side gets more complicated, but it pays dividends in the long run. Cool, so that is my Blazingly fast talk on Blazingly fast freedom. If you have any Blazingly fast questions, we've got like five minutes. Yes. So, a bunch of... So the static... Okay, static generators for WordPress, the idea being something like a simply static or a WPG static where you add a plugin to your WordPress site and it will go through and run that build step similarly, where it just says, I'm going to look at all my category views, all my tag views, all my author views, all my posts and generate static files that you can then push up. The reason why Gatsby is cool is mostly because of that React aspect. It's the idea of I want to do my layout in a React-style way and I want to manage my files in that React-style way. And also on top of that, because that's where there's more of a developer-focused community on that side, we're getting those really cool continuous integration tools. I'm not saying there's not continuous integration tools on those other static site plugins, but they're not really moving as rapidly as the Gatsby system is. And as much as there's a, the whole concept of the content mesh that the Gatsby community talks about came about because this rapid development tooling is happening. Gatsby couldn't exist without the fact that there is so much momentum behind these tools coming. So that's what makes it cool. That's why it's maybe not the best fit for everybody. If you're, especially if you're sitting here saying I'm not a developer, I don't want to do React, but I do like this performance aspect, absolutely. A static site generator that just runs out of a plugin is a really great way to go. Any other questions? Yeah. Man, once you get, there's still going to be a scaling at that build step, but all the more reason why that continuous integration is kind of the way to go because then you're letting a cloud provider worry about that scaling problem. But another reason why that scaling problem is less likely to come up is because of that GraphQL notion of we're only fetching exactly what we need. So when I fetch that post, I'm not necessarily getting everything out of the post the way that PHP is. I'm getting just its title, just its content, just its type of whatever exactly I need. So I'm not going to say you're never going to run into a scale problem, but you're way less likely to run into a scale problem for sure. Yeah. Yeah, yeah. Yeah. Not necessarily with a starter. The issues I run into with Gutenberg now is that because blocks are, they are rendering things way more complicated than short codes ever did, and short codes themselves are still the problem. So what you can imagine is when I'm hitting that recipe and I'm trying to get the content, what I'm actually just getting is a bunch of HTML, which might include a short code, which might include some asynchronously loaded JavaScript tag, you know, all that stuff now, when I'm running that through dangerously set HTML in my React template, it's just stuck there. Right? So it now puts the onus on me that if my content creator wants to use a block or a short code or anything in that Gutenberg's give me that isn't just the content, is now on me to make sure that I'm transforming that or giving them some other way to do that. And honestly, what I've ended up doing is basically getting just not using the blocks as they are, not providing metafields or creating a block that is essentially just metafields. So as opposed to like, say, an OMB of a tweet, rather than using the OMB block for Twitter, you know, still getting the URL for the tweet and then I'll render out the tweet through my build step. That sort of thing. And so it puts a lot of onus on me, the developer, right? But I'm still giving them the way to embed the tweet. Yeah. So that's the unfortunate side, right? Yeah. I'm not seeing anything where Gutenberg itself is inherently conflicting. It's only the matter of the same content issue that is there always is still going to be there. Now, I mean, I should say also, the thing where Gutenberg does maybe throw off is because it becomes harder, or at least I haven't seen any of those deploy plugins that are trying to like watch for a save because of the auto-save stuff, which is before Gutenberg even, when it's really getting that right. But I think it's because a lot of people doing these are not actually WordPress people. They're gas people trying to make something for it. Myself included. I've not done this right very well. That's been harder. But I'll take full blame for that as well because I'm part of the people trying to fix that. So that's the one thing I have seen.