 And this is a Reclaim EdTech session on headless WordPress development. I'm really excited to kind of be able to have Jeff Everhart from WP Engine here to kind of help us break this topic down and learn about it. And Jeff, you wanna introduce yourself? We'll talk a little bit about what we're gonna do here today. Yeah, sure thing. Thanks so much, Taylor. And a big shout out to the rest of the Reclaim hosting team and Reclaim EdTech for having me on. I'm really excited to be here. So my name is Jeff Everhart. I currently work for a company called WP Engine, which is a managed WordPress hosting company as a developer advocate. So my entire job is getting to go around and spread the goodwill about what we're doing in the headless WordPress space to developers like you all. And just to give you a little bit of background about myself, I've been working with WordPress for probably about 10 years. And I've got a really good full-circle story to tell about that as well, since I think it loops in Reclaim. And so my introduction into WordPress actually came on one of the first WordPress multi-site instances that Tim Owens installed at Longwood University back in the day. So it's really cool. And I've gotten the chance over the years to collaborate with Reclaim also at a previous role at VCU. So really excited to be here, done a lot of work with these folks. And I'm really excited to share with you all some of what we've been working on at WP Engine around headless WordPress. So the title of my talk today is Getting Your Head Around Headless. And so what I like to do in this session is just to sort of start off and I'm gonna introduce sort of an extended metaphor. I come from a background of learning and teaching. So I'm a huge fan of using extended metaphors as a part of the learning process. I'm gonna try and give you sort of a 30,000 foot overview of what headless WordPress looks like. And then I'm gonna jump from there into showing you a couple of demos about the products that WP Engine has. And then what we'll do to round off our session is take a look at some examples of headless WordPress used in a couple of different flavors in the wild so that you can get a good feel for how you might be able to incorporate this into your development practice. So to get started, the first thing that we should probably answer is what is headless WordPress? And so I like to say that headless WordPress is an architectural pattern and not a specific set of technologies. Okay, and I think that's really important. So the extended metaphor that I'm gonna introduce here is the idea of building a house, right? Because websites or web applications, for lack of a better word, there are digital real estate. And as such, how do we go from our raw materials like bricks, mortar, maybe wood, combine those things into reproducible blueprints or engineering plans and end up with a fully finished house. So that's the lens that we're gonna use to sort of examine this, but I think it's also a really apt metaphor because just like houses, just like homes, boats, dwellings, whatever you wanna call them, they come in all different shapes and sizes, right? We have our Spanish tile, missionary stucco buildings. We have our modern farmhouse. We have our log cabins and our handcrafted Amish buildings, right? So we have this whole spectrum of different looks, feels, aesthetics that are all built with different tools. And I think that's important to keep in mind as we start talking about headless WordPress because this is one of those things that offers you as the builder of these sites, a lot of flexibility in how you wanna assemble those raw materials into your blueprints and then ultimately your finished houses. So before we jump into what headless WordPress is, I think it's always nice to look at what traditional WordPress is. And these are the only two, so this is an architectural diagram and I've got one more and I promise you that those are the only two architectural diagrams that I'm gonna show you, but it is the easiest way for us to look at the differences between what traditional WordPress is and what headless WordPress offers. And so in a traditional WordPress paradigm, we have our WordPress CMS here hosted on your lamp stack server. When a visitor types a URL into their browser, maybe they hit a CDN and maybe they don't just depending on your setup, but either way that request for site.com slash page is forwarded on to WordPress. WordPress goes does its thing, it looks at this particular URL, decides what data it needs to show and then returns that result to the user, maybe back to the CDN to speed up your website. But the important part here in this paradigm is that both the developer and the person who's publishing the content interact with WordPress in the same way, right? I as the publisher go fill out my blog posts, maybe I add some custom fields, do things like that. And that's how I interact with WordPress, right? Now on the developer side, that's similar but also a little bit different, right? We enhance WordPress functionality with plugins, we style it with themes and all of our interactions for displaying this content to the user have to sort of go through WordPress in the way that WordPress wants to handle that, okay? So let's compare that to what we get in headless WordPress. And so at a first take, obviously this diagram looks a little bit more complex. And in many cases, I'm not gonna lie to you, it is, but it offers you as a developer a lot of flexibility. And the other thing that I'll point out is that there are lots of ways to achieve this. And so I'll try and capture that nuance as I'm explaining these various options to you. But let's dive into some of these differences, right? So I as the visitor can still interact with this person through, you know, interact with us through a CDN. I make my request for site.com slash page. And so that gets forwarded to a separate service, right? And sometimes that can be what's called a Node.js runtime. So this could be an application like Next or Nux.js. Maybe it's just an HTML page on a separate server. I think the point here is that what the user ultimately interacts with is not WordPress directly. It's some other intermediary. And this is what makes headless WordPress headless, right? We have some other application, whether that's a full blown site building framework, a mobile application or just an HTML page that is gonna request data from WordPress, right? That's what's serving this user request, okay? And now this page, whether it's an application or a page then makes a request of WordPress's API. It says, hey, WordPress API, give me the post with the idea of 137 and WordPress returns that data to that calling application, right? And then that application gets to decide how it's rendered and how it's ultimately shown to the user, okay? And so what we have similarly to our previous diagram, right? Is how the publisher interacts with WordPress. The person who's managing all of the content. That relationship stays the same and it allows the publisher to continue to publish in the WordPress admin interface, but it allows the developer to sort of break out of the WordPress theme concept and design a front end for a website using whatever tools they want. So in a lot of cases, in what WP engines products are pitched towards are full stack JavaScript frameworks like Next.js, NUC, SvelteKit, some of these things that I'm gonna discuss in a little bit more detail later, right? So that's sort of what WP engines product is around, but that doesn't have to be the ultimate client here, right? And some examples I'll show you later. We can have a single HTML page that just makes a request of this API and then displays data, right? This doesn't need to be a complex thing, although it certainly can be, right? This could also be some sort of mobile application. So an Android or iOS app that is using the WordPress content management system to source content, right? So that we can, as a publisher, manage our content in one place, but then we have the ability to use APIs to publish that content in multiple different locations. Maybe that's going to a website over here, you know, a landing page that's just an HTML page, and then these other separate Android or iOS clients. And so for us as developers, for me in particular, it allows us a lot of freedom, right? Because WordPress theming hasn't changed much in the past 10 years. And some people, especially those who prefer to write using JavaScript frameworks felt kind of left out. So this is a way that we can sort of incorporate the best of both worlds. It makes a lot of people happy because they really enjoy the content editing experience that WordPress gives them. And so given the complexity of this chart, right? So I'm not going to try and deny that this style of development is a little bit more complex or certainly can be if you manage it in a certain way. Why would we go headless? And so these are like some of the common reasons that we hear from people who are deciding to rewrite a traditional WordPress site as a headless WordPress site. Site speed and core web vitals is something that people talk about a lot, right? You have the ability to make headless WordPress sites really, really fast. With traditional WordPress theming, you only get to make so many choices about what resources are included, right? Like jQuery, some of these things are bundled and packaged for you. And if you layer on different plugins and things like that, those all add additional assets and resources on your site that tend to make them a little bit slower. So I'm not trying to say it's impossible to develop fast traditional WordPress themes because it certainly is, but it takes a little bit more care and a little bit more attention to detail. So we do see that headless WordPress sites have the potential to be a lot faster and to perform a lot better with certain core web vitals and usability, which means that they load faster on mobile devices and just have a better user experience when it comes to that. There's also a little bit of increased security. I know WordPress gets a really bad rap for security and a lot of it is somewhat unfair, in my opinion. We've moved on from PHP 5.1 and now we're at PHP and I'm sorry, my dogs are outside, I'm gonna need to pause for just a second to let them in or they're gonna scratch and I'm sorry. No worries, we can take a break while you get your dogs. I just needed to let them in the room, sorry. Oh, cool. Yeah, so we have increased security, right? Because the main mechanism by which our users interact with our website is now separate from WordPress, right? Maybe it's an HTML page, maybe it's a JavaScript framework, but it's not WordPress directly and because of that, we sort of get security through obscurity. If you can't really tell that we're using WordPress, it's difficult to have WordPress-specific exploits thrown against you. Additionally, another argument that we see come up a lot is the idea of developer experience. For people who have come into web development in the past five or six years, we're gonna focus primarily on using JavaScript frameworks to build websites, i.e. kind of like the Jamstack experience. A lot of those hosting platforms have really nice developer experiences. I push my project up to GitHub, this service builds it for me and beyond that, I don't really have to think about it. So we see a lot of benefits and improvements in that regard as well. Something I hear also from agencies and larger organizations in particular is the idea that we can do component-based versus template-based development. So when you're building a traditional WordPress theme, you have all of these different theme templates. You have your index, you have your page.php, and that's a collection of partials or other sorts of pieces that we're gonna build into this template. It says when I'm evaluating a particular route and I realize it's a page, all right, this is the template that I show them. And it's not impossible to do component-based development in that respect, but it is a little bit more difficult. And so what I'm seeing a lot happen at larger orgs, and this happened particularly at VCU while I was still there, is that some of these larger organizations are making these moves towards creating their own component libraries, right? Where I have a collection of buttons that I've created that everybody can use, or I have cards or list items, or these different common web components that are gonna be used across our organization so that everybody shares the same styling, everybody meets accessibility requirements, and all of that. And what Headless WordPress allows us to do using sort of JavaScript as an intermediate area is base our development process around those components. So it really does in some ways support those goals of larger organizations who are trying to standardize all of their buttons or all of their modal menus and things like that across an organization. The last thing that it allows you to do is the idea that you can write once and publish everywhere, right? So if I have one WordPress instance with an API, I can publish in there and then I can echo that data out to the web, to an iOS application, to an Internet of Things application. And so the possibilities of how you can really use that and what that data can do is kind of up to your imagination and that's really cool. So I'm really looking forward to seeing how people push that. You know, at WP Engine, we actually have somebody who's doing a lot of work with WordPress and the Metaverse. And so, you know, doing this whole 3D thing via the APIs and it's really, really sort of fascinating to see what the potentials of that are. That's really cool. One of the things that is really interesting to me in this is that I've often thought of Headless WordPress as sort of a solution to the problem of like, we don't want to do this in PHP or the reason of, yeah, of like, I don't have that skill set is kind of how that comes to me. Like I can kind of do stuff in static HTML and a little bit of JavaScript. So that's compelling to me. But to hear that like, large, large organizations have, you know, not similar reasons, but like a similar endpoint basically, the different reasons that get them to the same place is also really interesting to hear. Also, WordPress in the Metaverse is, wow. Yeah, so I'll definitely share some of that. Yeah, Anthony Burchell is his name. So yeah, I definitely go follow him on Twitter and all. I'll throw some stuff out there. Because it is interesting. And I think you're right. And that is interesting. And I wouldn't say that it's different because quite honestly, that's what we're seeing a lot is that is part of the reaction. People no longer want to develop using PHP or investing a ton of time in learning WordPress proper. So this allows them to leverage whatever skills they have in front-end development, right? Which is kind of JavaScript, HTML, CSS land to still build really cool websites using WordPress because I think, and I'll get to a slide here in just a second, but people love that part of WordPress, right? The content management aspect of it is nice. And I think people, especially marketers, people who manage sites still really like WordPress when compared to some of the competitors. Especially when you're talking about a team of people managing that content. I've been in plenty of conversations when people go, yeah, we just need a way to do this. And then when you really poke at that, it's like, well, we actually do need a system that allows for editors and authors and public, and all that stuff gets very complicated. That's why it can't just be a Google Sheet CMS. Yeah. So cool. So that sort of leads me to my next slide. Where does WordPress fit in here? And I've got a bunch of other logos from companies because one of the reactions that I get as somebody who's been a part of the traditional WordPress community for a long time, when I start talking about Headless and start sharing some of these things, they're just like, they're angry. Like, why would you do this? Like WordPress is not meant to be like this. And that's why I have so many caveats, right? Because it's not that you can't make fast websites in WordPress or secure websites in WordPress. It's just that the Headless idea makes some of these things easier. And I always like to frame this as well is that the idea of the Headless CMS isn't something that we just up and invented, right? So you've got sanity, you've got strappy, you've got contentful, you've got story blocks. All of these are giant multi-million or billion-dollar companies who are serving this content management system niche with a Headless-first CMS, right? And so I look at this in the sort of like Indie EdTech person in me says, well, like I want WordPress to be a part of this, right? WordPress is like the scrappy open source project. Strappy technically is open source as well and they've sort of built a company on top of it. But like when I look at these other SaaS-based offerings, that's certainly like what I want to see out there. I want to see, you know, the option for people to have like a platform independent way to do this style of development. And that's to me where WordPress comes in, right? So we have these other SaaS-based companies and WordPress gets to be that sort of open source community-driven alternative. But it's not like we just up and invented this style of development, right? There are people and companies who specialize in this stuff in a lot of ways that we're trying to help WordPress catch up to in terms of feature set, but it's happening and that movement is already, you know, has been going on for a while. So it's not like this is something that was invented with WordPress, right? We're just saying, I feel like WordPress should be a viable alternative to these other, you know, in certain cases, really expensive systems, like the price tag for Contentful is like thousands of dollars a month. You know, we're just sort of just for the CMS piece of that. So that's sort of where WordPress sits in this kind of landscape of headless CMSs. But I think it's also important, since it is like a somewhat new practice to sort of define where we are in the cycle just so that everybody's expectations of what's possible and what's on the horizon are sort of level set, right? So WP Engine as a company obviously has invested like a ton of time, effort and money into developing headless solutions in doing lots of market research about who's using it, how many people are using it, how many people would consider using it. And this has always been like a helpful heuristic for me to determine like where we're at in the hype cycle of a technology, right? And a lot of what the research that we've done at WP Engine suggests that we're still in this sort of early innovator space where it's primarily tech enthusiasts who are doing this style of development. And I'm seeing a lot of traction out there as I interact with the community and lots of people sort of just come out of the woodwork and be like, oh yeah, well, and I tried headless WordPress and then I made this thing. And it's a lot of these people who are sort of migrating from maybe they're a JavaScript developer or comfortable with front end development and they needed to make a new site and wanted to use WordPress but didn't want to learn PHP. So we're seeing lots of that play out. But I do think like this is important to contextualize where we're at because it still means there's lots of problems that still need to be solved. And I'll sort of like outline some of those challenges kind of in opportunities with you all as we dig into the individual technologies. But so hopefully, you know, we get to this early adopters phase soon. And as I said, like WP Engine is investing heavily and sort of making this a reality and making this a viable practice for lots of people. And so just to give you all some context about my experience with this, you know, I think like the WordPress REST API was merged into core maybe in like 2016, 2017, somewhere in that sort of timeframe. So I've absolutely been messing around with it since then. And like it's one of those things I would pick up and put down where I'd say, okay, can I do this API driven style of development with WordPress? I'd come along and, you know, make a code example and be like, yeah, well, I can do this, this and this but it's not really feasible for this other reason, you know, because of this, this and this. And as the years have gone on, that list of things that it can't do gets shorter and shorter. And the tooling around it just keeps getting better and better which I think is, you know, what I'll demonstrate for you here in just a second. So I'm gonna take us back to our building metaphor. And what I wanna talk about for just a second is are the raw materials of our headless WordPress site, right? So our bricks and mortar, our wood, our nails, the things that hold this stuff together. Because like I mentioned in that overview chart where we looked at headless WordPress versus traditional WordPress, basically headless WordPress just means like this is an API driven site. Like you're using the WordPress API, whether it's GraphQL or REST to power some sort of site experience, whether it's a full stack framework, whether it's just an HTML page or whether it's an iOS or Android application, right? So we have two main choices when we get to our API layer. And I'll talk about the REST API first since that is native to WordPress core and it is actually used by Gutenberg. So the block editor uses it extensively. And so it's not going anywhere. So REST architecture focuses on this idea of creating an endpoint for each resource, right? So we've got WordPress, you know, API slash posts, gets you your posts slash authors, gets you your author, can pass in query parameters to sort of drill down. But sometimes this means that we need multiple round trips to get all the data we need to construct a particular view or in some cases more data than we need, right? So if I get, if I say get me slash post slash seven, you know, posts with the idea of seven, you know, its default response is to give me back all this data. There are some mechanisms in WordPress for making this easier to deal with, like you can embed resources so that you can get a post in its author. And then you can also specify in some cases what fields you want returned. But if we're doing lots of queries, eventually we're going to run into what we call this waterfall of requests, right? So, or making multiple requests. Give me the post data with the post idea of 29. And then all of the pages written by the author with the idea of nine, right? Those have to be two separate requests based on the way that REST architecture works. So graph QL on the other hand is a declarative query language that turns the WordPress database into a graph via WP graph QL. And now typically there's one graph QL endpoint that accepts formatted queries. So basically I write a query and then I send that query off to graph QL and it returns me some data. But the benefit is that we can get data for multiple collections at once and that we get it in the format we specify. So it is shaped the way we want it to. It's not including all these extra fields. But so the barrier to this is added complexity and that it's not a core WordPress feature and that we've got to install an additional plugin to get that. So an example of this would be like I would send a query that says get me the post data with the post idea of 29 and all of the pages written by the author with the idea of nine, right? And that's all gonna return to me as part of one request. So one step up from that on our raw material stack are our frameworks, right? And I'm gonna dig into a little bit more detail in this in a second. And I don't know how many of you have experience with any of this stuff, but definitely if you're in Discord, watch and throw it in the chat. And if you use Next or React, Next or View, SvelteKit or Svelte, let me know or done any native app development. But these are typically what I see people build headless WordPress sites with. And I think that's also a function of working at WP Engine, right? We're a very agency-centric company. It is really focused on those types of publishers to see view and a little bit of react. Okay, that's cool. You know, and so we have these frameworks, right? So we have React, which I'm sure everybody's sort of heard of, probably View, which are JavaScript frameworks, right? They help us write interactive page components. But then we have also these frameworks that sit on top of React or View that help us build sort of fully-fledged websites, right? And I kind of liken that to a lot of what WordPress gives us as a part of its sort of traditional stack minus the content management piece, right? We have Nux that handles our routing and decides what templates to render and what data to go and get and populate into those templates. And so those are the mechanisms that we use to communicate with the WordPress API, get data back, and then sort of determine, determine how we want to display that to the user. Like I said, I always like to point out too that, you know, mobile apps are supported here. And that really might be one of the biggest examples of, you know, Headless WordPress where some of those early WordPress.com applications, the iOS app, which was done through, I think, like the XML RPC API, which is much less structured than the REST API. So even as far back as that, right? People were doing some sort of Headless WordPress development even though it was less structured and probably took a lot more time to spin up. And so I'd like to also point out that this stuff exists on a spectrum of complexity. Okay, because I think that's really important because especially when I start talking about Headless WordPress, there are a lot of options, right? It's not just PHP. We've got all of these different things that we could possibly use and all of these different options available to us. So it's easy to kind of get overwhelmed. And so on the right-hand side over here where we've got the most complex stuff, right? We've got some of those frameworks I just mentioned. We've got Next.js, we've got NUX, we've got Gatsby or Svelte. Then in the middle, you know, we can also do some Headless WordPress development just using React or View. And then over on the left-hand side, we've just kind of got HTML and JavaScript. You know, one of the examples we're gonna look at later, which I think is one of a conference program from a reclaim event, right? It's an HTML page with a JavaScript function that goes and gets some data from the API. And that's kind of as simple as you can get in terms of low barriers for entry. And this actual page people are watching on right now is very similar to that. So it's this page, watch.reclaimed.tech is a Headless WordPress site. Oh, okay. Awesome, yep. And I think that's just it. Like there is no, and that's again, going back to my extended metaphor, right? This is an architectural pattern. It's not a specific set of technology. So even though Headless WordPress, you know, in our product line, a WP engine is geared towards a certain bucket of those things, it's not all encompassing and it's certainly, you know, there's lots of ways you can approach this. And I think also one of the coolest things about this trend is that we get to take advantage of lots of really cool technology as it develops. And so like for me in particular, I kind of feel like, you know, the stuff on the right, it tends to get a little complex, right? I've got to be doing something of a certain size to really warrant using something like Next or Nuxt or Gatsby. But what that gives us is the idea that we can use this with anything, right? If there's a way we can get data out and render it in some way, you know, we can do that. So like one of the newer frameworks on the scene is called Astro and this is particularly focused on building just content-driven websites, right? Not applications, nothing behind authentication, right? Sort of focused on just really fast performant content-driven websites, but it lets you do that with view, react or spell. So it gives you a lot of options about how you want to create this thing. And I think my point being there that, you know, because we're just using WordPress as an API, we are not locked in to any one of these particular technologies and as stuff changes, stuff gets better, we can swap it in, swap it out, you know, start a new project with something else and try it out. So it makes it really flexible. And so two of the links that I've included on this slide, I think that just got thrown in a Discord is one about rendering patterns and headless WordPress. Because again, this is a concept that I do feel like people stumble on just a little bit because these frameworks tend to give you lots of rendering options. You know, with traditional WordPress, it's really just all server-side rendered, which means when I make that request and I hit that URL, WordPress combines the data with your template, generates me fresh HTML, maybe it catches it on CDN, but WordPress sort of does its thing every time. Some of these other frameworks give you additional options, right? Gatsby in particular, it's kind of like a static site generator. So what it lets me do is I, you know, give it paths to all of my WordPress posts and it'll pre-generate those all into HTML so that really there's no load on my server. If I just wanted to publish like a static HTML directory, it would support that and do that for me easily. So there's a lot of options there in terms of rendering patterns and that's just a helpful post that we wrote to help people in the community sort of discern what might be best for their use case. And then below that, we've just got like a headless WordPress tech stack options where it talks through a couple of these things in more detail. And so by now, like I've thrown a lot of things at you, lots of terminology, lots of maybe not lots of diagrams, but at least a few diagrams. And so what we found and what WP Engine found in their research was like people were interested in doing some of this stuff, but there's a lot of fatigue, right? I mean, there's a lot of things that I just threw at you, lots of concepts to digest, lots of choices to make, and then infrastructure issues that really didn't have a work around until something was built for it. And so me in particular, as somebody who did early headless development, right? I kind of always felt like the lack of tools that were specifically designed for headless, for the longest time, like ACF, for example, Advanced Custom Fields. If I wanted to specify Advanced Custom Fields and add those fields to the API, I'd like to install another plugin to do that. And eventually, they've got a little checkbox now that includes them automatically in the REST API, but it's just, that's a good example, right? It's taking time for people to realize that developers want to use these things via the API. So now you're seeing more and more plugins like that add functionality specifically for that, right? Gravity Forms, another good example, like they've got a really robust REST API. You can pretty much do anything you can through the GUI interface, through the REST API, including building your own front ends of the forms and just submitting data, it's really, really neat. Beyond that, there were no best practices for headless WordPress development. So people are still trying to figure out how to do a lot of this stuff. And because some of these tools weren't designed for headless, a lot of the things that worked in WordPress out of the box didn't necessarily work in a headless environment. So a good example of that is something like page previews, right? The concept of a page preview is a protected resource in WordPress. You have to be logged in to see it. So for a lot of the ways that people were doing headless WordPress development, it was kind of hard to hack together a way to accurately preview your page against what might be rendered by a totally different application, right? So WP Engine, there's a plugin that we built that sort of addresses that, for example, but I think all I'm trying to do is give you all like a good overview of these different pain points that people felt and sort of how the community came together and started to work through those. And then the last one was that hosting an infrastructure was just too complex to support. Now I'm just gonna slide back a couple of slides because I think that this is worth talking about, right? Cause like on this spectrum of complexity, right? If we're gonna host a headless WordPress thing, you know, and like we're doing it down here in this realm where we've got an HTML file, you know, like that's all right for most average folks to do. But once we get up here into where we're using these full blown, like a totally separate application as the front end of our website, that idea is really complex, right? At that point, you've got two separate servers. You've got your node server running this thing and then you've got your WordPress server over here. And so I think for a lot of small teams, you know, the idea of doing anything in this realm was sort of untenable at a large scale. And that's sort of where some of what WP Engine has put together comes in. And so just to sort of circle us back to our extended metaphor on building, I think it's important that we look at the idea that not all hammers are made equal. So I've got three different tools here and ostensibly, they all sort of do the same thing. But specifically, they're a little bit different, right? We've got this sort of run of the mill hammer over here. I mean, as far as hammers go, it's a really nice hammer. It's probably titanium. Like it's got the nice rubber handles, probably got really nice weight balance. Easy to knock in a couple of nails if that's all you're doing, right? But if you're framing the whole house and you're going for speed and accuracy, maybe you're using something over here like this middle to wall framing nailer. And then you look at the one on the right hand side and you're like, Jeff, that looks really, really like the one on in the middle. And you're right, it's a pneumatic nailer. But I think the idea is that this pneumatic nailer has a really specific purpose. And so this is called a positive placement nailer. And the whole purpose of this nailer is if you have like metal brackets that you're using to hang joists or fixed rafters and you need to shoot a nail through them, it's got a little bit of a tip right there that will help you drive that nail through that bracket. So the idea that we've got these tools that are focused in on this fulfilling this specific job is really important. And ultimately, you know, sort of what separates like the DIY sort of hammer down there on the left from what professionals are gonna use or what to use in the field. And so that's where WP Engine came in and really looked at the holistic of, I'm sorry, I got a cat attacking my mouse now. Where we looked at like the holistic problem of headless word press development and decided to invest in it, right? So how do we simplify tool choice and encapsulate or create these best practices and make headless painless to support? And so these are all of the different things that the company is working on right now. So at the framework level, we created a library or a framework called Faust.js which is a fantastic name. So I feel like we probably got some literature nerds in there, but when I was like, oh, this is great. And so that's based on Next.js which is a React-based frameworks and solve several of those pain points right out of the box. Like if you, so if you need authentication or you need page previews or if you need to your XML sitemaps, there's a bunch of stuff that this framework in the corresponding plugin solve for you without you really having to do anything. So I think that's the whole idea here and the strategy of this Atlas suite of tools is the idea that eventually one day we want this to be complete and performant, right? When you install and sort of spin up your headless WordPress site, you as a developer shouldn't have to make all these individual choices and a lot of this stuff should just come pre-installed because you need it to do what you're gonna do. So like I said, we've got Faust.js and for any of this stuff, we'll have some time at the end. So if there's anything that you all want me to do a deep dive into, I'm happy to when we can go look at the docs, look at some of the product demos and happy to show you all, right? So we've got that at the API layer, we're also sponsoring currently the development of WP GraphQL. And so that turns WordPress into a powerful GraphQL API and that plugin gives you a visual IDE in the backend of your WordPress site to compose queries. So it's really nice where I don't have to hand write my query. I can just sort of go in and select, oh, I want posts with this data, this data and this data. It's like a menu and it generates a query for me and then I'm able to just drop that query in my application somewhere and it requests that data. On the data modeling front, we have two tools at the moment and I'm sure you've all have heard of one of them. So Atlas Content Modeler and ACF Advanced Custom Fields. I was super stoked a few months ago when WP Engine acquired many of the delicious brains plugins. So including ACF, which they had acquired from Elliot, I think maybe a year earlier. And so what we're looking at now is these two groups are working on a strategy around what content modeling looks like for all of WordPress and then some optimizations to make ACF probably a little bit more headless friendly. And so what Atlas Content Modeler does is it's sort of like a mix up between custom post types UI and ACF where you can model the post types themselves and then specify these individual fields and then all of that would get added to the REST API and WP GraphQL automatically. So that's what those teams are working on right now is a strategy to sort of bridge and get the best of both worlds out of both of those plugins. And I'm sure that you all can see my face like one of those numbers is much larger of users is much larger than the other. So if one's gonna, Pac-Man chomp the other one, I'll let y'all fill in the dots about which direction that's gonna go but I'm personally super stoked about that. And then at the same time, we're also working on a search headless focused search plugin so that people can customize their search results a little bit better than they can in traditional WordPress and then also integrate that directly into the headless thing. So the last two are, so let's talk about the Atlas platform and that's what I'm gonna demonstrate for you here in just a second. So this is the sort of thing that underlies what I think makes a lot of headless WordPress development easier to do in this environment. So the Atlas platform is a hosting platform for both WordPress and Node.js based resources and then it integrates with GitHub for deploys. So I mentioned earlier that developer experience where most developers like, I wanna just clone down a GitHub repo make some changes, push it back up and then have that environment rebuild and that's exactly what that does. But so out of the box, when you sign up for this you get a WordPress site that's hooked up to this Node.js site that you can go and they're tightly integrated and you get this nice developer experience for whatever the front end of your site is. And then sort of on the bottom level of that we have our dev tools and local. I don't know how many of you all use local for your WordPress development but there's an add-on, an Atlas specific add-on that allows you to also create local headless sites. So if you're looking to do that sort of development locally and play around with it without signing up for an account I'll sort of show you how to do that here in just a second. So going back to our metaphor how do we move from raw materials and principles to a finished house and practice? And then this is where I'm gonna hop into a demo time and show you what we call Atlas blueprints. Right, so I'm just gonna pop out here real quick and log into the portal for WP Engine. Sorry, I'm gonna have to two factor in here. Maybe not, maybe it likes me today, which is always nice. Okay, so I'm just gonna come up here into my dashboard then I'm gonna open up the Atlas platform. And so what I'm gonna do is I'll just run you through the process of creating a new app from scratch. Let's make sure I'm at the right account. Okay, and so once we're here, we have two options, right? We have the option to start with a blueprint or pull from our own repository. So if we click start with a blueprint, what we've done is we've sort of tried to create these starter projects based around these different use cases. So just a basic website, a portfolio or a blog and basically what you as a user do is you select this we'll authenticate with GitHub and it's gonna clone that into a repository in your account and then deploy that website for you. And we can see that it includes all of these plugins for us out of the box. We get WP GraphQL installed, we get Atlas Content Modeler, FALSE WP and Atlas Search. And so we'll just do this basic blueprint and then we'll click continue. All right, so I'm just gonna select my GitHub account. We can just name our blueprint, whatever we want. If you wanna keep the repository private, we can do that as well. Like most other cloud-based stuff, we can select the region. I'm gonna select US Central and maybe it doesn't like my GitHub. Let's manage GitHub. Looks like it kicked me out of GitHub. It's one more time. All right, and so that's just gonna take just a second spin. We can see that it already created that repository for me in GitHub. And then now that we've done that, we are taken to just this Atlas environment page. And this is where it's going to spin up our site. So we can see here that it's gonna run through these different steps of the build process. It's gonna first provision us a WordPress site that is gonna be linked right here. Then it's gonna run through the different steps to build whatever sort of code repository that we've done. So in this case, the blueprint, it's gonna run through those and build those. Just like most other JavaScript sort of based hosting things. And I think what the idea here is that we want this to sort of be a comparable experience to either like a Netlify or a Purcell. If anybody is familiar with either of those platforms, those are really focused on this sort of Jamstack JavaScript hosting ecosystem. And so that is sort of what the goal is for us to be comparable to. And we're always sort of launching new features. And so just a couple of things that are gonna get pushed this week is the idea that we can do PR previews. So if we've got this, say for example, we've got this website or we've got this GitHub repository, right? Somebody makes a change, opens a pull request. It'll automatically spin up another environment so that you can preview all of those changes inside of that pull request. So if I'm making some changes to a content focus website and then I want somebody to look at them, I open up a PR, Atlas automatically detects that, launches an environment for you so that you can look at what that looks like in real time basically, before you merge it in back into GitHub. We've also launched a web hook. So some of these frameworks that I mentioned, and I'll pop back over here for just a second, like Gatsby and Next and things like that, things that publish your resources to static HTML pages. That means they've got to be rebuilt every time you add a new page, right? So we've added a web hook so that you can ping the Atlas platform or any time WordPress content changes. So this is gonna take just a second to build. I don't know if maybe now, if we wanna see if anybody's got any questions in the audience. Taylor, you got any questions or commentary? You might be helpful for people. Yeah, I'll just say first, if people have questions, throw them in the Discord, we'll see them and we'll bring them up now while this provisions the WordPress site. But one of the things I kind of wanted to do is set a little context. Cause I think we have probably like a bunch of different folks coming from different environments, either watching right now or later too. And if you're someone who is probably like me and is like less thinking about this from a developer perspective and kind of you know, the ed tech perspective of like, I'm helping, you say you have a faculty member or a department who's like, I want a site that does this and you go, you know, we could do this in WordPress but then they wanna do custom things like displaying data in different ways. You know, again, I kind of roll to like this site we're looking at right now where we have multiple sessions and a video player to do that kind of thing. Even if you aren't the developer that's putting together the final like the head of the headless site, right? Like the part that's the front end work. I think in my experience, what this allows you to do even if you're bringing in like someone to do some of that work is this stuff is much more readable and changeable and sort of sustainable in a lot of ways. Like we had that this site, that you know, this session viewing website or our watch site, you know, most of the work was done on that at this point a couple of years ago and we've been kind of tweaking the front end and the back end to our needs and the great thing about that from my perspective is someone who's not, you know, like a full stack web developer is I can go in and look at like, all right, I got two files, right? Like I've got this index HTML, that's pretty easy. I have a pretty good understanding of that. And I can look at the JavaScript and kind of see what's happening and what's going on. And that's totally separate from and divorced from our data, right? The stuff that is important that I don't want to break and is mostly built in in our case, ACF. So for me to do some of that was really simple to kind of poke through the code as someone who hadn't looked at this stuff in a way that I'm less familiar with WordPress theme development, right? So I really want to kind of, I know that this is sort of like talking around the thing, but I think that context is important if you're looking at this and going like, I'm not a developer, maybe this isn't for me. I think understanding where this has that place amongst your tool belt of things that you can suggest. Because so often I've been in the shoes of someone who's like, who comes with a project idea to me, I'm thinking WordPress at a certain point and then they go to a point where I'm like, all right, this is gonna be custom development. And they go, yes, but I want to do it. And then we have to have a talk about like, okay, well that's great, you can hire someone, but what about in three years? And this allows a lot less of the custom development to happen in a place that's going to break with every major version of WordPress. You know what I mean? Like in my experience anyway. Yeah, for sure. And I'll sort of underscore just a couple of things you said in there, because I think they are important. So I think the idea, what you mentioned, right? I can go into these couple of HTML files in this JavaScript and like, look at what's happening and that's totally separate from my WordPress environment, right? That's an important distinction. That's the benefit we get from decoupling is what we mess up over here has no bearing on what happens over here. Where when traditional WordPress, like, if I upload a bad theme with like one extra or I miss a semicolon in PHP, like the whole thing is shot. Yeah, your site's for everybody's down and so it's just like, you do get this sort of separation of concerns in a nice way and that's part of why I think you're seeing, like when I go back to that headless CMS slide, right? That's why these other companies exist is because you get this sort of technical benefit from that. And the other thing that I would say as well, you know, like, yeah, and I think one of the caveats that I want to make, right, is that WP Engine's built this product, right? Built it for a particular audience and that I think is these development teams of agencies and like larger enterprises and stuff with teams of developers doing this, you know, doing this style of development, which I think is really different from the indie hacker people, right? Even what I was doing before I went to WP Engine. And so I think going back to that spectrum of complexity is important because like, I don't want people to leave here to think that this is what headless WordPress is because it's not, right? This is a tool to enable certain people to do headless more efficiently, but like we have, you know, there are solutions all along that spectrum of complexity. And so if you just want to try this out with HTML on a LAMP stack, so like go for it and that's a totally valid, valid way to do that. Yeah, and it's really interesting for me because I haven't seen the Atlas platform before, you know, we've obviously talked before right now a little bit that you're going to demo this, but it's not something I've looked into too much. But it is really cool for me to see how, because I do have some experience using, what was the Jamstack one you compared it to? Netlify or Burcell? Netlify, yeah. I used to run my blog on Netlify for a while. But, and it is really interesting to, for me to see that comparison because I think that that is one of the things that it is occurring to me like at Reclaim that I'm going to put on my long-term to-do list of, no, we can't make an Atlas, right? But what I could do is make a custom installer that throws a basic Apache server, probably a full LAMP stack, maybe just Apache and PHP and a WordPress site with some plugins configured and say, here you go, here's two things, it wouldn't have all the same thing, but like you said, these tools, there's a place for a large spectrum of them between you got to go spin up multiple AWS containers and install MySQL yourself and all that stuff. Yeah, once we're in that land. You're right, that's going to take a while. But I do think that there's an interesting opportunity there for that. And again, anyone that knows me has probably heard me say this a million times, but there's a lot of power to understanding the building blocks here and what they can do and then going from there and saying, I don't maybe need a fancy solution or I do need a fancy solution for what I'm doing. But if you can understand here that fundamentally what this is is using WordPress, utilizing the WordPress database for your content, that idea is super powerful. And it's really interesting, even me playing around with this a little bit, like it's really interesting things that, when you have that concept available to, you can do things that are kind of amazing. Like I did some testing, just real basic, like what if I put three posts in a WordPress page, do this all on LAMP and have a headless site on the same account that just pulls and displays that text. It's as a demo, like is that faster? And it turns out, yeah, because like displaying, displaying my basic HTML site is nothing to, in this case Apache. And so there's, it, that's, I guess one of the things I really like about that technical flexibility, I guess is what I'm saying, is that you can do this in all kinds of different ways, all kinds of different places. Even local headless, which is, you mentioned that something had never even occurred to me, but that's really interesting too. One thing that I did with this display site we're looking at right now, if you're watching this, is because all of our data is in a WordPress site that we've been using for years at this point, this version of the headless site, I developed on my machine first because I didn't need to have a separate server for it, and then I could just deploy it as needed. So it's really cool stuff. It does, and it makes, yeah, it gives you a lot of flexibility. And so I think, and if you wanna pop back into pop the screen back up, it's been, yeah, done for a second. And so what we'll do here is I'll sort of just show you all how the rest of this platform works. And then I think I've got a couple of examples, like in the wild things we can talk about, that I think maybe for our audience to better represent that spectrum of complexity because nobody, I don't wanna say nobody, but the people who are gonna start here are the people who are the JavaScript developers. People who've already been doing this style of development and are just coming to use WordPress, where I think there are a lot of other ways that you can sort of get your feet with with doing this style of development that might better fit into your workflows. And so I think that's maybe a good point a good place to like orient folks. So here, we see that I've got this code repository created and my cat is being very aggressive right now, just really wants to direct the show. So I'm gonna go ahead and copy this to my clipboard and I'll just sort of show you all a quick example of how this would work in practice, right? So I've gone on to Atlas, I created a new blueprint based site, it's spun it up for me, created this repo in my GitHub repository. And so if I come in my code directory, we'll do, you know, clone this repository and we'll jump in here, open this up in VS code. And I'm not gonna dive too deeply into any of this. I think all I really wanna do is just come out here and we'll make like a, you know, a really quick change. We save that and we can basically use git to add all of that stuff back to our repository. So we'll commit that. And then if we push that back up to our origin repository on GitHub, what that does is that's gonna go and trigger a rebuild in the Atlas portal. So if I reload this, we should see that, you know, that's gonna go ahead and run certain steps of that build process again. And so in terms of like a developer experience for somebody who is doing this sort of JavaScript style based development, it's really nice cause like you mentioned, like I can just clone this stuff down. I can do all of my development locally if I want and run this project locally. And it's all hooked up to my WordPress site. And then if I, you know, wanna push something back up, that's all I do is I just push it back up to GitHub, Atlas detects that change and automatically builds that back into your live site. So if we go and just check out what that looks like, you know, you can play around with it there. And so if you are interested in like taking that sort of step and investing time in that, these blueprints are a great place to start cause they're sort of purpose made already. And so for you as a developer, like I always really liked having good examples to work from and that was the idea here, right? You can really quickly in 10, 10 minutes deploy a headless website and then go pick it apart piece by piece to see what it is, change the styling, you know, whatever you wanna do there. And then as I mentioned before, this particular blueprint is written using this FALSE.js headless WordPress framework. So if you're looking for documentation, that's got a bunch of stuff here and it's got, like I said, previews out of the box and sort of just installs a bunch of this stuff for you as a part of that blueprint process. And that's so cool. I'm assuming like a lot of the it's using because it set up the GitHub repository for you, it's got the hooks pre-installed to, or sorry, pre-set up to like a post-deploy probably GitHub hook to do that. Yeah, I don't know exactly what hooks would be there, but yes, I mean, once you authorize as, you know, a part of that initial process, the Atlas platform like the Atlas Bot or whatever, you know, does all of that is listening, yeah. And like I said too, it's also got those pull request previews. So if I were to open a pull request, like if I had a separate branch that I was working on and this is just, you know, maybe a little bit more advanced of a developer workflow, but like we've got our main branch, which is what's in production then maybe we've got a develop branch that is what we're working on, you know, and I open up a PR to merge changes from one branch into another, it'll rebuild you, it'll build you a new environment for that, which is also really cool. And, you know, good for a certain type of developer. Awesome. Yeah. So cool. So that's sort of Atlas. If there's anything else on this tool list that you all want me to go over sort of toward the end, just let me know, like we could do a deep dive in WP GraphQL, show you what ACM looks like, whatever we want. But what I did want to spend some time doing is looking at some examples from the while. And here are just a couple of the ones that I pulled out, right? And so, like I said before, and I've been talking about this whole presentation, we've got this spectrum of complexity that exists when we do this stuff. And, you know, what I would say, Atlas is maybe over on the right-hand side, right? We've got a full-on application that's running the front end of our website, whether it's no JS, you know, no JS-based, iOS-based, whatever, that's sort of the most complex thing we can do. On the other hand, like, you know, I think we've got the HTML CSS example that we'll look at here, and I'll sort of show you how you can, you know, break that down as well. But I also think it's worth mentioning that, you know, since headless development is essentially just using the WordPress APIs to get data and render it in a particular way, there's nothing to say that that can't coexist with traditional WordPress-themed development. And so I'm gonna give you this example, and this is one of the last things I worked at while I was with VCU Online was redoing their website. And I'll sort of give you a little bit of context for the history of this website and why we decided to do it the way that we did. And then we'll look at sort of the headless features in particular. But one of the things that I mentioned and the reasons why people tend to go headless is because they get to do this idea of component-based development, right? If I'm using something like View or React, it's all sort of centered around the idea that I'm creating these discrete components that I can then reuse across a page or across an application. So that's great. And for larger orgs, that's awesome. And what VCU had done for a couple of years before we redid this website was they spent a lot of time and effort into creating their own component library called Compass. And so, you know, if you're ever used Bootstrap or any CSS frameworks like that, it's kind of the same thing, right? We've got different buttons, you know, and they've got classes on them. We've got different cards that we can use. And there are all these different components that we have that they've created, right? That we want a way to import into our website. And so, we undertook the redesign of this website sort of to refresh it, number one, but then to also incorporate this Compass component library. And let me see, I'm already in GitHub. I'm gonna probably hop back out and see if I can find that VCU online Compass. Yeah, and I'll just pull up just a quick example of a headless feature. No, sorry, back program. All right. And so, what we did here is, right, this is a traditional WordPress theme. And for most of this stuff, we sort of copied and pasted the HTML of these different components into our theme to make it match, make it compliant, whatever you wanna call it. But there were a couple of features that we just felt like we couldn't do justice without using a little bit more advanced JavaScript and thus requiring us to use the WordPress REST API. So one of them was this degrees and certificates filtering page. So you can see there that when we load that page, this initial piece is blank. The page loads, it makes a request out to the API, gets a bunch of data around the different certificates and programs that we offer, displays it in this grid format. And then we get a bunch of this different filtering here. So I wanna filter by certificates. I can do that. And as I do that, this is gonna filter down the certificates. We also get all of these different filters over here that we can toggle on and off or clear entirely. And I'm gonna open up the web inspector real quick and just show you all how sort of we arrive at that. And so if we refresh the page, we can see that I'm just, I filtered this down to just XML HTTP requests or fetches, right? And so this is what we're going out to get. So we make a request of this URL. And if I open up this in a separate window, right, and that's just the WP JSON, WP V2, that's the WordPress REST API we're getting the degree post type. We're saying get us 99 per page. And then we only want the published degrees. If I copy that and do another one, you'll see just this is the data that we get back. And then we use that data as a part of this small little JavaScript app to do all of that advanced filtering, right? So we fetch this particular URL and then we use that data to sort it and then apply all of those different dynamic filters up here. And what that allowed us to do was to sort of like break this down into actual components where we've got this card component down here that we're using and it allows that to be reusable. And it let us make something that was super flexible that we probably would have had to get kind of hacky with to get the experience that we wanted if we were to try and replicate with a traditional WordPress team, right? Because at that point, each one of these things have particular classes that are applied and to really like parse through the HTML of whatever plugin we had would be kind of hacky in some ways. So sorry, and now we've got a question in Discord. And is this contained in supplemental tables within WP databases or a call to an external DBU whose data is folded in? In this case, this is contained within the WordPress database. This is a degree custom post type with ACF custom fields, right? So if we look at this, the post type right here is degree. We get all the WordPress stuff back that we get with any other request. And then down here, we get ACF fields that have all of that special stuff that's on those particular cards. That's a really good question though. I'm sorry, I got lost in my tabs. That's a really great question though because I think that's also kind of another benefit of the headless methodology is that we can do that, right? We can combine data sources really flexibly. And so I'll give you a good example of that, which is our own WP Engine developer relations site. So definitely check this out if you're interested in anything that I've talked about today. We've got a ton of tutorials right here. One call out that I'll make is that we've got this headless WordPress developer roadmap. So if you're kind of interested in some of the stuff that I've shown, like you're like, oh wow, one day I wouldn't mind trying that, right? This is the, these are the steps that you kind of might need to take to get there. And we start with answering that basic question of what is headless WordPress all the way sort of down to like building a simple headless WordPress app with Next.js and WP GraphQL. And so we're gonna kind of keep building that out, but that's sort of a step by step. It's the most comprehensive thing that I could point you to if you're interested in that as a target. But what this does is this actually combines a lot of different data sources, right? So we have a WordPress site where we publish all these posts. So there's our post type. We have a video post type that categorizes all of our videos. We've got a plugin post type that does that. We run a podcast. And so our website here integrates with that podcast API and then the application produces this page. And then if you come down and I'll head back to our homepage all of our developer documentation for the Atlas platform actually lives in GitHub as markdown files. And so we've got sort of one Next.js application out here that is combining data from a WordPress website multiple different post types. It's combining data from this podcast services API. And then it's also combining markdown files from GitHub all into this one sort of really complex site that offers us one place to work on it. So that's kind of a decent example of doing that where you sort of knit together all of these different sources. And again, that can be as complex or as simple as you want it to be. This podcast feed is literally one REST API endpoint that gives us back all the podcasts. And so you could treat that the same way you did you would in any other HTML file. That's really cool. And I wanted to just kind of circle back and ask a question then in terms of like for the scenario which is I think most of the examples we've given so far of we're using WordPress as the single database and back in for your content. Mentioned ACF a few times and that's for folks that aren't familiar that's advanced custom fields. It's a plugin that lets you create post types and sort of custom taxonomy. Well, I don't think it lets you create post types yet. I think you have to create the post types. And then you can, okay, yes. Yeah, maybe I'm wrong, but. No, I think you're right. I've been messing with it, but I'm pretty new to it. And some of it is, I probably did manually as a custom. Well, yeah, not on a sport. I won't like commit to any sort of feature release but I wouldn't be surprised if that shows up soon. And then you've also mentioned Atlas content modeler which is sort of WP engines take on that. Is my understanding? Yeah, yeah. And let me see, let me hop into there actually. Well, and we could go and look at that. Yep. And so I'm gonna hop back into my Atlas environment. Yeah, let's take a tour of that because I do think that's worth mentioning. So let me hop into here. Then I'm just gonna, you know, when we spun up that Atlas app it created me the separate WordPress environment. And so we'll just pop in there via WP admin and I'll show you all what that looks like. Yep. And so like I said, that is centered around the idea of these custom content models. Okay, so let's just create a project one. I'm over here. So we're creating a new custom content model and we'll say, I want that to be public. And choose an icon. And then we don't need a description. And so that's created us a new post type. You can see that it's added it to our WP admin dashboard there. And then we can come through and add additional fields to it. So like, you know, just call this name. We can do some repeatable fields. I'm gonna use this as the entry title. And then single line, you know, just sort of like ACF you get to make some of these decisions as well. And then we'll just go ahead and add another number one. Maybe this is like the description. And we'll just leave it at that for now. And then I'm gonna come over here real quick and we'll just create a couple. So like ACF, you see, as you sort of create that content model and modifies that post editing page to contain those particular fields. That's pretty slick though that you can make that custom post type right in there if any Atlas content modeler as well. It really is. I mean, and it's kind of one of those things where I was like, why did ACF not do this before? But like I said, and I'm trying not to give away too much but like there's a lot of overlap between ACF and ACM. And I think what we'll see is just like the things that ACM does well, just sort of maybe folded in or subsumed by ACF, which has a lot more community support, if you will. And I think a lot of people would be kind of happy about that, yeah, hipstripsum is my go-to thing. Sorry, that's not what I wanted to do. I wanted to add new. So go ahead, publish this. Cool, all right, so if I go out here, so just a couple of things. So we get this preview that's gonna come out here and go to the front end of our website. No, but what I wanted to show you, yep, so that's Atlas content modeler. So we can do content models, we can also do custom taxonomies. So if we wanted to categorize or tag those using specific things, like we can do that through ACM as well. But where ACM makes headless development easy is that it automatically adds it to both the REST API and WP GraphQL. So I'll open up WP GraphQL and just sort of show you all what that looks like. And let me just make sure my settings are what I want them to be. Yeah, should be fine. All right, so GraphQL is, like I said, a declarative query language. It was invented at Facebook and it's got a lot of nice features. And so if you're gonna come to the second section of this series, you know, I'm gonna dig a little bit deeper into the REST API and GraphQL. So this is sort of just a preview because I think the query composer is kind of a nice feature. Because when I say write queries, people are like, oh my gosh, like I don't wanna write. Like they think about right now a SQL query and it's not really like that because most of what we hear from WordPress developers is that they'll actually use this IDE feature to do most of their GraphQL development. So like say I wanted to come in and I wanted to get my projects, right? So I added that project post type. You know, I can come here and let's say, I don't know, let me open up this link into your tab. And I'll say as someone who's only used the REST API so far, this is already a lot simpler. Because... And I suppose a background too, you mentioned it already but just to reiterate, the REST API is built in WordPress. GraphQL is a plugin that you can install and then makes it... Yeah, yeah, WP GraphQL is a plugin that will basically turn it into a database. What would I call this description? Yeah, all right. So yeah, say I wanna write that query, right? Like I wanna get this post and these fields on that post, you know, I come in, I use the query composer, it sort of tells me what fields I have available. But like one of the nice things about GraphQL is that everything's kind of linked, right? So it tends to be a little bit cleaner in some ways than using just the built-in REST API, right? So if I wanna make one request for this project and the author's, I don't know, name, which is gonna be me. Like I can sort of compose that query here, like run ID, make sure you set the proper ID type. That's a good call. Thank you. And it'll even give you helpful errors when like me you don't know what you're doing. ID type down here. And then yeah, I think we want database ID. Yeah, okay, cool. So yeah, and it'll return that. And so basically what developers will do a lot is they'll come in and say, all right, you know, I've got this page and I need this data and they'll take a second and stub out their query using this query composer. And then for me, I would just copy and paste this query in my application somewhere wherever I was making that query. So like I don't have to write it from scratch. You get this nice tool and then you can kind of just drag and drop this stuff there as well. It's also really nice because it gives you this interactive explorer. And so like I know the shape of my data. Yes, that's you. And it's a lot simpler. Yeah, and so there are some ways that we can do that with the WordPress REST API. Like I mentioned, there's a underscore fields thing. So like if I go get posts, like if we go and we look at this example, right? This is me getting everything on this. And I don't know that we're getting embed data, you know, but we've got a ton of stuff here, right? And we're not using half of it. So it's just like wasted data transfer where GraphQL, you kind of just specify what you want the object to look like. It returns you an object that is that shape and all that stuff is kind of clean and neat. And you get a lot of that toolkit, what you were just showing is your request and that's the JSON you get back. And I think you may have like a Chrome extension installed to actually make that pretty and like you can fold the stuff. And not that that's big deal. People can install a plugin, but like if you're new to this, what your experience probably will be is you form your URL as a, you know, your REST URL, basically your endpoint. And you're gonna get like a crazy amount of text on the screen. You're like, okay. Yeah. So that's a much nicer onboarding, I guess, is what I'm getting at is the GraphQL stuff. Yeah. And I think that's kind of what we hear too. Like there is, and I don't want to downplay it because like you are learning, you're learning sort of a new pattern, right? And that it's, this is just a URL. Like I type in a URL, I get some data. Like I can kind of understand that. So there are definitely trade-offs there. And the other thing I don't want to downplay is like usually to use this, you might need a JavaScript package. Like it's kind of hard to just send this query in a post request as is and have it work well. So like there is some added complexity in where you put that that might not be there in REST if I just want to use like Fetch, which is in the browser, like that's easy. That's a super easy thing for me to do where making the request might be a little bit harder. But yeah, I look at this and I'm like, man, I can only think about when I was getting started, how often I would get lost in traversing this JSON data structure. Be like, oh, what is this? It's like, oh, content.render is what I need instead of just content. And so there's a lot of intricacies to this data response from the REST API that I think GraphQL does a little bit better of a job, like managing for you. But like I said, so that's the sort of a preview of what I hope to talk about in session two later this week. We're going to sort of deep dive into a bunch of that stuff. So if you're getting for that, I definitely love to have some of you all there. I think we've got a couple more examples that we can look through. Taylor, unless there was anything else in here while we're in here, that you wanted me to sort of run over. I mean, I think we're good for now. Like you said, we'll dive into some of that stuff a little bit more next time. I definitely am really interested to see more about integrating the GraphQL side of things, what that looks like. I personally am going to look at ACM a little bit more just because I have used that. And so that's going to be cool. But yeah, I think we're good if you want to show a couple more examples and we'll probably wrap up pretty soon then. Okay, cool, cool. Yeah. And so the other one that I wanted to talk through too is I guess that this is really your all's product. This domain's schedule. Cause I think that this is just really like a fantastic look at, you know, where headless shines. Cause I know that you can see up here, right? We've got just an HTML file. And I think that's awesome. Cause again, like the Scrappy web is the best web for me. And so like the idea that you're putting this out there and you know, like I read back through Jim's post about why you all decided to do this. And I think that this is a really good use case, right? Because when you're loading stuff via WordPress, like in a traditional way, WordPress is shouldering all that responsibility. It's generating your HTML. It's making a new database request every time somebody hits it. Like unless you have a CDN or some layer of caching in front of it, you know, but even then like it's, and then it's sending you all of the JavaScript you need. Like, and it's responsible for all of the things. And so what that means is that pulse load things tend to bog down sites really quickly, right? If a bunch of people are using a WordPress site all at once, like that has the potential to overload the site very quickly. We see it happen all the time. Like even though you may put steps to mitigate that, you know, it's still definitely possible. And so this is a great example of that, right? This is the idea that this is a schedule that you're gonna have a ton of people on this thing all day looking at it. And you want a better, more performance solution that's really never gonna go down, right? Cause even if this page loads, like we go from, and this is a good example. So I'll open up the inspector tools to you, right? You know, and I always like to look at the size of, you know, whatever it is that we're transferring. And wow, I mean, so right there, the amount of data that we get back from the WordPress API is less than a megabyte, right? 734 kilobytes and we got that in, let's see how quick did that come in? You know, like a second or two, 1.12 seconds, right? So that's a quick load time. But overall, I mean, the total page weight of this whole page is 1.3 megabytes. So that's a super, super tiny footprint when we compare to what that would be if we were loading a traditional WordPress theme and we were having all of these other things loaded on top of it. You know, so like, I feel like this in particular just results in a really fast performance thing that's gonna support the type of load that you all anticipated during that event. And this is maybe a small thing too, but I think, and that wasn't part of this website, but like the creation of this or anything, but I'm a little bit familiar with some of the requirements that they had and what they're looking to solve and all that stuff. Another kind of cool thing was because we were able to put the data, you know, the WordPress site, the WordPress backend, wherever, it really doesn't matter where it is. In our case, it's running on Reclaim Cloud. But because the headless, the front end is just an HTML, we were able to integrate that into like single sign-on really easily with Alt's single sign-on system basically. Because we didn't have to have like, all right, we're gonna authenticate you into a WordPress site. It was like, we really just need to make sure if you're able to visit this one page. Not that it couldn't be done, but it made that problem pretty simple and you could host it anywhere. Like in our case for Reclaim EdTech stuff, when we have a new series, like this is one of them, this headless WordPress site, but we just got off of a Docker course. I copy a file, change the name. Like, and I added a couple things about it, right? Inside the thing. It's very simple for me to spin up a new site. Like it used to be that I spun up a site in a real way and now it's I copy a file because it's all pointing to the same data source, we're just asking it to give us different sets of data. In our case, we've got one WordPress site that's pulling in every event. Like it's where we enter our events and then we just have it filtered by category. So I could say, oh, let's do this category now. And I think Tom Woodward is gonna be on next session to kind of show that in more detail. But I do think it's a somewhat relatable example, at least, especially because you can look at it, you're looking at a version of this right now if you're watching this. And it's, in our case, what's in WordPress is this event information, the title, the speaker, that kind of stuff. Yeah, and I think maybe another feature too of this one and maybe I'm wrong, but I feel like part of the reason that it was done headlessly was so that I wanna say that it displayed like the time relative to the person viewing its locale in their browser. Yes, it is. This was an international conference, right? So I'm just like trying to think about how you would do that in traditional WordPress and it's like, oh man, you do a geo lookup and then on their IP address and then go get this, do all this time zone conversion, which is terrible to do. And I think, I remember reading a write-up, yeah, time conversions is multiple simultaneous tracks. Yeah, and I feel like that's just so much easier to handle when it's like, the person's machine is telling me it's this time. Like, you shift everything around that. In our case, it's made easier because we were able to just put it in WordPress and like, I think UTC for this particular conference. Yeah, yeah. Because everything was like 15, 10 or something. And then they're using a JavaScript framework, they integrated a JavaScript framework they found that can do that time zone conversion locally on in your browser. Which again, could you do that in a WordPress theme? Yeah, but it would have been a very large, a lot more overhead in a bigger development challenge and it required you to do that. I think you would have ultimately done it through the API anyway. Yeah, probably. Like, you might have done it in like the partially headless kind of methodology. But I think that brings up one other interesting point and that is like, you know, and it's sort of like this tension I see sort of between PHP and JavaScript, right? And like PHP and WordPress for better or worse, like they've got some tools, some ecosystem, like obviously the plugin market is huge, but in terms of like composer packages versus NPM packages, like the size of those two ecosystems is just not at all comparable, right? Like there's so much more stuff and so much more current work being done in JavaScript than I think there is in PHP land. And so like, I do see that trend, I don't know if it's like causing it or a symptom of it, you know what I'm saying? But like, there are more helpful libraries like that than in JavaScript now than there are in PHP. And so that is just sort of another reason for me to like be able to do some of the stuff in JavaScript. Cause like, yeah, that's a terrible problem to solve like time zone conversion, but especially if you're in Arizona and like you're the one person who like hasn't mod, like that's, it's crazy. And so it's just NPM install this solution and then well in this case it's not even that, right? Because it's all browser side or client side done, right? So I did link to that. And it's not just Luxon, Luxon, but it's leveraging this with some other stuff is my understanding. Not having dug really far into the time code, but having looked at it more and kind of hacked it up to some of our reclaimed ed tech stuff. But it is, you know, it allows you to use the tool that you A, you're comfortable with and B is best suited, right? If what you're trying to do is solve time is situations to do that server side is kind of insane. And PHP wants to do it, like that's what PHP is for, right? So that's really hard to do in that case, because now you have to do all those time calculations every time you go through requesting and delivering the page to the browser. Whereas you can just say, look browser, you know what time zone you're in. Like I will tell you this, you do the math to figure out what makes sense for you. And obviously I'm oversimplifying it by a million time problems are hard. But it does, if you think about it for a sec, make a lot more sense to say, why don't we have your computer figure out what time zone you're in? Because it already knows what time zone you're in and figure out what that means for displaying this. And it's easier to do in JavaScript. I think the same thing as my most comfortable language is probably Python, which isn't like a ton of web stuff happening there. I mean there's like flask and there is, right? But for me to do like things like, well what if I wanted to do a not a web application but I wanted to request data from like an API that we make. I can do that with WordPress as the back end and then use the Python tools I'm familiar with to manipulate that data and do something with it. And this headless concept just allows you to have, look at your tool belt and decide this is the one I want to use, not the one I have to use. Yeah, for sure, for sure. Cool. That is very true. Yeah, and so then the last example that I'll sort of show, let me just close out a couple of these tabs. And this is just, I mean, a giant site. So the other thing I wanted to leave you with again, like, so now let's navigate back to the right-hand side of that complexity scale. And so this is probably one of the largest, most visited headless WordPress sites like in existence maybe, Android Authority and they're sort of one of the ones that run on our platform. And they've done a bunch of like white papers and things like that, talking about all the benefits that they got. I mean, but so my recommendation to you all just go click around this thing. Like it's Android related news but I think you'd be surprised at how quick and how performative it was. Sorry, performant it was based on the size of the website. And so I think like a lot of people too, if we're looking at this trend in development again, like on that hype cycle and where it is, like what does it need to become more solidified, more accepted, better supported? I think having these really large things exist as proofs of concept are important. And I've heard of a number of different sites like this one's one of them. There's another one that is focused on like e-gaming, Excerco, if you're into video games at all, you may have been to this site either way. This is also a giant headless WordPress site with like a multi-lingual thing layered in. So there's a French version and Spanish version as well. I mean, but some of these things are serving 60 million page views a month. And it's just sort of astounding to me that they're able to scale to that size. But it's really, you know, because they've chosen to opt into some of those like optimizations that I think headless gives you. So like I said, there's some things at the right-hand side of the complexity scale. If you're interested in sort of thinking about like how far people can push this, there are people doing really complicated, you know, enterprise level things with headless WordPress right now. And it's just now that we're sort of like learning more about some of the ones that already exist. And I'm always stumbled on people like, you know, being like, this is a headless WordPress site. And I'm like, what? I didn't know that because they are hard to detect. My understanding is whitehouse.gov is a headless WordPress site. I don't know a white house. I know whitehouse.gov is at, let's see. I know they're leveraging WordPress and the REST API, but that can mean things that aren't exactly headless WordPress as we're talking about right now. So that could be wrong. Well, we can see. And I always just come up here and if there's a bunch of like, yeah, I'd say probably not. Because we're still loading the typical theme. Oh, okay. So it's probably just a CDN in front of a WordPress site, essentially. Yeah. And it wouldn't surprise me. I mean, if they were lever, if they were doing sort of what I demonstrated with that VCU site, where there are certain features that are powered by the API, but the site itself is still driven using a traditional WordPress theme. Which, I mean, you see a lot of people do because it is just in some ways, like, you know, if I go back to that course filter and example at VCU, you know, I probably could have done that in PHP and or like a plugin, but it would have either, you know, I would have had to layer a bunch of stuff on there or it would have taken me a lot longer than to just do it in JavaScript. And I think like to your point about the maintainability of some of that stuff, like I feel confident that that thing will work for five years without anybody touching it, you know, but if I would have used a plugin, like I'd be less sure of that. So I think that's also why you see a lot of people do that. Kind of depends on where your skill sets are, like the team you're working with or the team that you want to hire or build or whatever. Like you may have design folks who can do some of that design in WordPress using some WordPress tools. You may not, you may have someone who's like, I'm going to design this in Photoshop, I'm going to give it to Jeff and that's the team, you know. So that depends sort of on where, what types of people, everyone has different slices of these skill sets, you know, that make up the whole person, right? So that always is different depending on what project you're on. For sure, for sure. So I think I'll just leave y'all with some, again, some resources. So definitely check out developers.wpengine.com. We've got a ton of headless focus content. We do a podcast, we do tutorials, things like that. I'll also plug, we have our own Discord. I think we're edging on like 700 people right now. So if you're interested in just talking with other people who are doing headless WordPress things, definitely join us there. I just joined Reclaims Discord, so I'll be hanging out in there. And if you have any questions about headless WordPress or anything of that nature, like ping me on that platform, but definitely drop by there if you are so inclined, I really look forward to maybe talking again with you all on Thursday about WP GraphQL, the REST API and really deep diving into that stuff. Cause I do think that is like the basis for headless stuff. Like the client, it can be whatever you want. It can be an HTML page. It could be an application. It could be an iOS app, but undergirding that is really this fundamental understanding of transacting with WordPress be the API. So hopefully a bunch of folks find that helpful and interesting. And so there are any questions, any other questions Taylor, you got? I don't think we got any more in Discord. I don't think so. But yeah, I wanted to thank you and helping us kind of break this down and understand that this is really cool stuff. I'm excited for session two. Awesome. Well, thanks again for having me. Super, super pumped to be here. All right. We'll see you and we'll see everybody else next, or sorry, next session, which is Thursday. Awesome. Yeah. Looking forward to it.