Well, let's dive into WordPress. Maybe let's start actually, like I was going to start and say like, what's WP graph? QL? Which we should get to. But even let's get a baseline of like, if someone hasn't used WordPress, like the three of us have, which is awesome. What is WordPress? Like, how do we even define that? Let's start there. Yeah, I

Jason Bahl
mean, yeah, WordPress is a content management system. So it's a, it's a web based application, right? It's where users can log into it. And they can publish content, it's powers, somewhere in 45 ish percent of the web right now. So pretty much any there's a good chance on a daily basis, you're visiting a site that is powered by WordPress, some of the top sites, you know, publishing sites, like NASA actually just relaunched on WordPress, like NASA, on their science website, things like that. So yes, it's a open source CMS, so developers can download it and extend it and write code to do whatever they want. There's a massive plugin ecosystem for it. So you can kind of turn it into whatever you need it to be for your project. But yeah, it's all web based. And yeah, lets users read content and publish it to the web. Yeah. And

Ryan Burgess
I think that's a big thing to what you hit on is like the plugins, it's it's extendable. You can write themes, you can download themes, you can download plugins, integrate it, write your own. I think that's what's been so powerful with it. It just gives a lot of flexibility for people to do what they want with it. Yeah, so it's, it has I'm surprised I didn't realize how much of the web is taken over by WordPress. I mean, I'm not surprised but like, didn't really realize how much is being used by WordPress. But I've seen it leveraged for so many things. Even just there's things that I've had to do with it over the years that I didn't even think possible like it was Why are we extended WordPress so hard? But it's cool to see what you can do with it. On

Cole Turner
that note, I guess, let's say it's me and I haven't used WordPress in a while. What is what are some typical use cases for a developer to choose WordPress over something else?

Jason Bahl
Yeah, so I think I think access is a big one, it's First off, it's free, right? So if you if you have limited resources, or whatever, like, you can just go download it and start using it. It's very, like we talked about there's a massive plugin ecosystem. So you can extend it to do almost anything you can imagine, like, it can do isn't necessarily the best job. Maybe, maybe not, I don't know. But like, it can do it. Almost certainly. So access is a big one. Cost is a big one. They say it's free, like a dog, right? Like you get a dog given to you, but there is cost associated with it still. So it's not like, it's not like, truly free. But like the software itself is you can start prototyping with it with with no cost to get started. But uh, yeah, I think those are some big ones is the access to it. And literally, you know, reduce cost of getting started with it. So that's a big thing. And then yeah, like 40, some percent of the web is using it. So there's lots of examples out there of like, oh, I want to accomplish this. Can it be done on WordPress? Well, here's an example. Yeah, of course. So. Yeah, yeah. Yeah, I

Ryan Burgess
mean, it's been around for years to like the adoption is high. It's, it's grown significantly in, you know, battering, making it a lot easier for people to leverage, you can have it hosted for you, like a lot of hosting platforms have it available for you. Obviously, WordPress itself is available to just have it online and leverage that. But you can also host it yourself, you can move it, migrate it wherever you want to put it, which is pretty cool, too. And really flexible. Yep,

Jason Bahl
I would say the community and documentation is huge, too, right? Like, so if you do feel like you're stuck. Like if you're, if you're working on some custom application for company, and they're the only company running that software, if you get stuck, it can be hard to get out of that, right. But with WordPress, high chance somebody else has run into the same situation you've encountered and can help you right. So the community documentation is massive, I feel like it's one of the most documented pieces of software out there, in my opinion, both good and bad, because there's outdated docs too, and can kind of send you down the wrong trail sometimes too, or there's, you know, bad docks or whatever. But it is very highly documented. If you're searching for something, you're gonna find somebody else who has written about it. So that's, that's a positive. I think,

Cole Turner
I love that. Because I think about where I started in my career, I did a lot of WordPress very early on, because of exactly what you're saying, Jason, where if you're running into use cases you've never built before. They could be old, they could be new, they could be all over the place. But it's good to have options. And it's good to have other people's work to influence your work. And I think that is where WordPress is a great tool for many people who are across different skill sets. Because you can do that customization as you need to see it fit. Or potentially, maybe you don't need all that and you get a lot out of the box for free.

Ryan Burgess
Yeah, great points. Well, let's move to WP graph. QL. Like, alright, what is WP graph? QL? And how does it differ from like, traditional API's from WordPress? Yeah, so

Jason Bahl
So typically, when you think of WordPress as being a content management system, it's what the word monolithic is thrown around a lot. So it does everything right. It's one piece of software that does the content management, but it also does the presentation of the website for you. It has a template system and all this stuff, right? So it's monolithic, meaning one big application. And a lot of organizations find themselves, you know, investing in training folks that produce content. And they want them to continue using WordPress, because that's a big cost, right? Like, I used to work for a newspaper publisher, and we had hundreds of people trying to publish content in WordPress. So switching off of that would be a massive investment. But the front end all like the what's present, what's presenting the content on the front end. WordPress doesn't always make sense to do that, like we had native iOS and Android apps, for example. And you're not running PHP on phones. So like having a WordPress template as an iOS app doesn't make sense. So you need to get the data from the CMS. So we have the folks trained to publish content. But we need it for the web, of course, but also for native iOS and Android apps, but also for print. Like it's a web first world, right? We're publishing stories on the web, and then preparing it to print. So having having access to the data outside of how its rendered for the web, was an important thing. So WordPress has a REST API, which is rest API's are like an endpoint per resource is kind of how it works. So you would hit an endpoint like, you know, your WordPress site slash posts. And you would get a list of posts or slash post id one, you know, and give you an individual post. So WordPress has that RESTful API built into it, since I think 2015. And we use that when I was working at a newspaper, like I said, and we were using that pretty heavily. But we ran into a lot of problems, trying to scale it. And that's largely because if you think of even just like an individual newspaper article, right, and that's a lot of resources to make one article, you have like, an image, which is a separate resource, you have the author who wrote the article, which is a separate resource, yet the categories and tags that it's categorized in, you possibly have image galleries, which are another lists of resources, you have comments, maybe on the article, which are different resources. So just to publish one article page, you're talking like lots of resources and hitting an an API for each of these resources. Typically, restful API's will give you a full resource, and then IDs to related resources. And so you have to wait for the first resource to come back. If the IDs, make references back to the other resources, sometimes get IDs to other resources. And so you're making this like, what they call maybe callback hell, right, like, and so like, we were using REST API's to do stuff, like I said, our native iOS and Android apps, but also to like syndicate content to other we had a network of like 50, something newspapers across the US. And, you know, so if Denver Post, for example, published an article about, you know, the Broncos winning the Super Bowl, or whatever, then, you know, maybe some other cities wanted to subscribe to that news. And so we were sending data from one site to another or pulling it from one site to another. So those systems were getting pretty complicated to scale using the resource based API's. And so around that time graph, QL was open sourced by Facebook, when I was working at a newspaper, I was like, Oh, this looks like it might solve some more problems. Because Graph QL, you can, you can build it in a way where you can consume multiple resources in one request. And I was like that, that would solve at least some developer problems, right? Like, of us consuming all these API's and having to wire it together on our end as the consumer. So if we could do it on the server, and then each of our applications could specify what exactly they need, our iOS app could ask for exactly what it needs in a request where it makes sense. So So I started tinkering with it. And she, you know, proven it to some colleagues. And then we went ahead in production with it, not not too much later, and replacing most of our REST API usage. So that's kind of like the story of it. But yeah, so graph kill differs from rest, and that you can, it's a type based system. So everything in your, in your application is described as a type. So a post, for example, in WordPress would be an object in graph, QL, and object type. And it would have fields like the title and the date. And it can have what's called connections to other types in the graph, right. So a post can have a connection to author and images and categories and tags. And so as the consumer, the person building the iOS app, for example, they can write a query a graph, QL query, and they specify exactly what fields they want to be returned. And so the client has full control over what they get. And they can do a lot of, you know, connected resources in a single request. And so, from a client perspective, the consumer getting the data, it usually has a much more pleasant experience. And when things go wrong, which is software, things will go wrong with rest, you just know something on that endpoint went wrong. And there can be 1000 fields on that endpoint. It can be little tricky to debug, sometimes with Graph QL. Since you specify exactly what fields you need, it can be a little bit easier to identify when something goes wrong. Oh, it's that exact field. And you can start doing things like tracking how fast each field responds and things like that and start figuring out like, the granular details of your application, so solves a lot of problems, I think. And yeah, hopefully that

Ryan Burgess
covers it. I like that a lot, actually good explanation of it. And I mean, it makes a ton of sense. It's a similar thing with anything that we've seen with REST API, right. It's not scalable. I mean, it is I shouldn't say it's not scary. But it's like, yeah, Graph QL has just made it so much simpler and more scalable, and more customizable, like right, depending on like the iOS client that, you know, Android client versus the web. It's like you really get to choose but use that same data set, which is huge. And it's funny hearing you talk about like rest even being introduced to WordPress. So I came here, like you said, like 2015 or something. I was doing something similar at Evernote. The task was I was supposed to integrate in the Mac client, the iOS and Android. And I think the web, but they wanted a lot of the content. It wasn't like all obviously all of Evernotes content. But some of these, like notifications and content was coming from WordPress. And that was before rest even existed in WordPress. So there was a lot of hacking on our end to get that to work. And just seeing how much it's evolved is amazing. And the fact is, is like, well, Graph QL didn't exist at that time. But if Graph QL existed, it would have made it a lot simpler for each of the clients to decide really, what was the information needed. So I love your explanation on that. I'll also add,

Cole Turner
I love that we're talking about rest versus Graph QL. But in the context of WordPress, and newspaper type websites, or other type websites like blogs, even Evernote and newspapers are kind of similar in the sense that it's a lot of unbounded content of different varieties. So you have like text, you have images, you have media. And this is supposed to flow in between the actual website itself. And so mixing these different mediums is a perfect use case for something like Graph QL, because different clients can take out parts of those mediums that is more useful to that client. And in the case of like the New York, the New York Times or some other newspaper, when you want to make sure that your experience is performant. Using something like WordPress and Graph QL is a great fit, because it is one request resolved in many different varieties of subjects. And to have that do of arrest could be, for example, 100 different REST calls. And if one of those calls fails, the rest will just kind of topple over. Because as Jason was saying, you don't have those connections anymore to infer on with something like Graph QL, you have less of that performance issue where you're resolving one big batch of requests, and you're not making multiple round trips between the server and the client. So in many ways, it makes sense that Graph QL is a great fit for this type of user experience where it allows you to really optimize your performance and tailor each client to its needs. I

Jason Bahl
will say there are trade offs, right, like, so rest when we talked about rest not being scalable, quote unquote, it is obviously we know it is but it can be frustrating for sure. But uh, what one upside rests has is that since it is resource based, it's easier to cache, right? So like, if you have an endpoint for one object, well, whenever that object changes, it's easy to invalidate that endpoint. So Graph QL being an open one endpoint to access everything. Like, that's a lot more difficult to cache right is like this tricky. So there are trade offs to stuff like that we do have solutions. So like I maintain a plugin called WP graphical smart cache, which you can add on to WP Graph QL. And then a lot like my host, the my employer WP engine we we support, like edge caching for Graph QL requests. So you can you can query whatever you want, whether it's posts or users or taxonomy terms, or images or whatever you want. And smart cache plug in what it does it It tracks those IDs and tag it sends back had headers in the request, or sorry, in the API response, it sends back headers that identify what was asked for the request and what was resolved. And then that can be tagged in the cache. And then it listens for events in WordPress, like editing a post or publishing a new post or deleting a post. And then it can purge any Graph QL query response from the cache if it was impacted by the action. So it brings back some of the benefits of caching the REST API. But you get the benefit of the flexibility of Graph QL. So it brings back some of the stuff that if you research like caching graph, QL, have you read a lot of arguments on like, oh, you can't cache it, whatever. It's more difficult. But there are solutions. And we at least have provided some on our side. So

Ryan Burgess
yeah. And Jason, my assumption there to the fact that it is a plugin is it's probably pretty straightforward to integrate into WordPress. Am I wrong to say that? Yeah, yeah.

Jason Bahl
So it's a yes, free on the wordpress.org repository, just search WP Graph QL you can activate it and then immediately what happens when you activate it, you get a graphical IDE, if you've ever used Graph QL, you're probably have played with the graphical IDE. So it's just an IDE where you put a query on the left side and click the Execute button and get the response on the right so so you get that in WordPress admin to start playing with. But then you just get a Graph QL endpoint and then it's up to you to do something with the data, right? Like, it provides the API for you but it doesn't It doesn't do anything with it, right? It lets you do something with it. So it's a, it's really a developer tool. More than like, a lot of WordPress plugins or like you do some, you know, it's like, it adds some UI where you can drag and drop something or whatever written, this just adds a way for you to access data in a different way.

Cole Turner
I was just gonna say I love that, because thinking about my experiences with WordPress, I always remember installing plugins, and it was never just like plug and play, you install a plug in and you spend hours tinkering with the settings, making sure it matches your environment or the different needs that you have. But even just reading the documentation in here, what you're describing JSON. WP Graph QL is well documented, it handles a lot of use cases, like all of the different entity types that you have to select from. I'm even seeing it handles authentication and authorization, debugging. And so just have a solution that you plug and play and you can actually get started to use it. I think a lot of developers listening to this can consider WordPress and W grep. WP Graph QL as something that they can just get started with and start building with versus here's another plug in here's yet another solution that might even like lock them in.

Ryan Burgess
Yeah, I

Jason Bahl
think one of the one of the most common use cases we're having like abusers right now is, so I came from unique story, like at the newspaper where you're syndicating data and doing all sorts of weird stuff. I don't think that's like the common use of Graph QL. Like, but the the more common, like with frameworks like next becoming, you know, on the rise, it's already popular, but it continues to get more popular. And then, you know, you have your spelt and you know, nuxt with view and all these all these frameworks, everybody wants to build stuff in JavaScript, and components, right components make sense to I think a lot of people's brains, right. And especially if you're on big teams working on big projects, it's like having one component that can do everything it needs to do usually, that's what includes styles, markup, and interactivity all in one component. So a lot of folks are trying to build component based websites or applications. And so Graph QL lends to that very nicely. We have a framework like I mentioned that WP Engine is called fast Jas, you go to fast gs.org, that's FAQ S T. But it's a it's like what we call like meta framework built on next. And it allows you to build next sites, but it and it works with WP Graph QL. But it does a lot of cool stuff that you lose when you go headless with WordPress. So WordPress has like the template system built into it. But it's all PHP based, right. And so for folks that do want to take advantage advantage of like component based architectures, they can build their React components coupled with a Graph QL query, or what was called a fragment and Graph QL. You can specify like, just the fields that this component needs. And and then you can write your markup and your styles or detail when classes or whatever, whatever you're doing. And then you can, you know, bring those components in with other components. And then Graph QL goes and gets the data for all of your components at once. So it's pretty, pretty cool experience for folks. But I think that's the most common use cases, folks building component based front ends right now. And I think it runs very, perfectly to that.

Ryan Burgess
I'd also be curious, like, we'd mentioned that, yeah, it's a plugin. So that's awesome. It sounds like you can integrate fairly easily can like existing, like blog sites or whatever, like someone using WordPress for five years, and like, they have a lot of data. Is it hard to integrate? Like, do they have to do something different? Or is it pretty much like, well, you have all this data now you're just going to be accessing it a little bit differently?

Jason Bahl
Yeah. So I would say it would depend, right? Like, if you're a, it is a developer tool, right? So if you're not comfortable interacting with API's, or making fetch requests to get data from API, there, there's going to be a learning curve for it. A lot of folks are coming from the JavaScript ecosystem, and previously, maybe have said no to WordPress based projects. But now they can say, Oh, I don't, I don't have to be a PHP expert. Right? I can. I can set up a couple plugins. And I can get the data out into JavaScript component architecture, with probably not having to write much or any PHP, there's going to be cases, depending on how Customer project is like you, you're probably going to have to extend it might have to know some PHP or get somebody who does to help you or whatever. But there's a lot of folks that can can write 100% JavaScript and be very successful using it now. So you don't have to be a PHP or WordPress expert in every case, but it is very much developer to have like the small business owner who just wants to click and drag and drop stuff. It's probably not for them. Will it be maybe someday Maybe, maybe under the hood, it'll be used by tools that do that. Right, like, you know, Page Builder type of tools that are built using components that have Graph QL. You know, associated with it, but the business owner themself probably wouldn't be the one using Graph QL unless they're very tech savvy person.

Cole Turner
I have a question. Jason, would you describe what we're talking about right now is sort of a server driven UI approach? Yeah,

Jason Bahl
yeah, I would kind of I would call them, I would call Graph QL. Like, you have the front end and the back end, like would call graph to like the middle end, right. It's basically what it what graph kill does, you have a schema, and you describe all your types. So you say this is all the types of data that are possible. But I don't describe like the graph. QL schema doesn't describe how the things should look. And it just says, here's, here's the data that's possible. So the front end is still the front end, whoever is building the components still ultimately decides what the UI looks like. But they can see what's possible to populate that UI with by using tools, like graphical to see what's in the schema. So a lot of a lot of organizations I've seen do what's called like schema first development. So like, you'll have your front end developer and your back end developer come together, or your product owner, whoever it is, they'll come together, and they'll, you know, have a rough design and, you know, whatever figma, or whatever software, you're using the design these days, and they'll say, this is what it should look like, does the API support that already or not, if it does, cool, they can start building and you can start mocking it out, right? Like you can just populate your component with with mock JSON data. And then your back end developer can go, you know, add fields as needed to the schema, to actually populate it. And then all you do is get away the mock data and put your Graph QL query in and it's working. Right? So. So it's like this kind of meet in the middle approach, where you say, like, do we already have this data? If not, okay, back end developer, you need to go out that support front end developer, you just need to make sure this, this shape of data works with your components, right? Jason,

Ryan Burgess
that's been huge, too, right? Like, that's something that we've found, like being at Netflix, that was something we were using a lot of Graph QL. And that was something that was really beneficial in that, like, Let's build those contracts between back end and front end. And being able to, you know, agree upon that and understand each other what you need to do. And you can kind of go off and create what you need to create. And as long as you follow that, it works really well. And so I've seen a lot of benefits to like almost, you know, productivity gains, where you can actually collaborate a lot easier between the back end and front end. So I'm glad you called that out. Because I think that is a true benefit.

Jason Bahl
Yeah, and what what, like what I mentioned, we have a lot of JavaScript developers that are, you know, attracted to this. And you mentioned Cole earlier, maybe before we started recording, but advanced custom fields you've used in the past. And that's a very popular plugin, which my employer also owns WP Engine. Talking about that, too, but But it's so that's because it feels a really cool plug in with WordPress where you can, you can create what's called Field groups. So you can define field groups that you know, text field, or email fields, or whatever text area fields, or image upload or gallery field, like all sorts of different types of fields. And you can just with clicking buttons without having to know PHP, you can build UIs, in WordPress, for how to manage different types of content. And recently, probably, since you've used it, they added the ability to register post types and taxonomies through advanced custom fields as well. So like, WordPress has posts and pages out of the box right as, but if you want other things, which most sites need other things, right, like houses or cars or, you know, products or, you know, whatever shoes or whatever you're managing, you know, advanced custom fields allows you to say like, I want to manage cars, or I want to manage houses, or I want to use WordPress to manage X, Y, or Z other type of data. So you can add those types just by clicking a few buttons. And now I've maintained WP Graph QL for ACF, which which ties the two together. So you can have WP Graph QL. And then it figures out what fields you have via advanced custom fields. And that brings support to the Graph QL schema as well. And so it's pretty cool experience. So you can with Graph QL, you can have like these fragments, like I mentioned, which are like pieces of a query. So like, if you had a restaurant, for example, and you needed to have list of types of food, you can add support for managing food via advanced custom fields. And then you could add your fields that you need like a price and a picture and the calories or whatever it is, you know that you need to put in the ingredients. And then just just by clicking some buttons and then you could go see that in graphical, you know, I'm consumed with Graph QL. So JavaScript developer can do all this without having to know any PHP and then they could go build their front end with components using Graph QL fragments to say like wow, A component that shows a list of ingredients, right, and it has a fragment that knows how to query for list of ingredients on a food type in the graph. And so you know, so you can start piecing all this stuff together without any code. So like WordPress is getting to a point where it's a low code, headless CMS, right. So you as a front end developer can can do your front end work, you still need to be a developer on that side, at least right now, I don't know of any tools at the moment that would allow you to be completely point and click yet to do both sides. But

Cole Turner
yeah, I mean, supposedly, there are tools where AI can generate from web applications. But I'm, I'm still skeptical as you were Jason. I do love what you're saying, though, in terms of the plug and play nature of all these tools, because you already have a great platform like WordPress, which can do so much. And a lot of developers who are listening to this have used WordPress. And so now it's great to know that they can just add on these plug and play tools like WP Graph QL, advanced custom fields bounce Jas to get an even bigger, more richer platform. And I love how we're talking about even just like schema first development, because as Ryan was saying, and Netflix, that's how we've gotten back and engineers and credit engineers to speak the same language. But as you're describing the ways in which these API's just unblock you, you don't even need to be a PHP expert, you can work in the languages that you're comfortable with, and evolve your platform with these plug and play tools to do even so much more. And I love that I think like for a lot of people figuring out where to start, or how to build that next website, that's even more richer tools like this could really help. Yeah,

Ryan Burgess
I also liked that you brought up the front end aspect of it too, because you're not necessarily having to learn how to build a full back end for someone like say, if you're just building like a for a client, or whatever that may be, and you don't have the resources to have a dedicated back end engineer, something like WordPress gives you so much control. And then also on the admin side, for that, you know, client that's like, I need to add, you know, different shoes to my website, or, you know, restaurant needs to add different types of things available to the for customer to order. And it's like they can do that they have that control. They don't care like about the technology side, they just want to be able to, you know, be flexible on that. But then you if you're the front end engineer, you're like, yeah, that's taken care of, for me, and then I can really focus on, you know, scaling out the front end, making it a little more custom for that client. I gotta love that. It's really taking the tooling to that next level.

Jason Bahl
And I think, I think some of the upsides to, like I mentioned, part of the reason we even started that was some more frustrations with rests, and like when when things went wrong, not knowing what was going wrong. I mean, that's a big part too, especially like a component based development these days, when, when something in your application fails, you don't want to know, just like, Hey, your application is failing, you're like, Well, what part specifically right like that, that makes your job easier if you know exactly what is failing. And so being able to like break down things to the component level, or components, ask for specific things. And, and then Graph QL returns exactly what you asked for, when something does go wrong. In my opinion, it's a lot easier to troubleshoot and identify it and fix it. So for the front end developer who maybe isn't a WordPress expert, stuff will go wrong. Like that's just software that the, you know, there could be a plug in update that breaks something like it could be WP graph, QL, plug in Update, there could be another plug in Update, you know, so like, something is gonna go wrong at some point. But if you're, if everything's broken down to individual components, often is easier, in my opinion, to to identify what it is and get to real resolution

Cole Turner
quicker. Also, even just to pull back to something you said earlier, Jason, is that almost half the internet is running on WordPress. So if something does go wrong, chances are you're going to be able to find out what went wrong for somebody else. Yes. And I think back to my experience with WordPress, I think as soon as you start seeing become more custom, back in the day, used to run into a wall. But with tools that you're describing today, it sounds like these are paved paths that help users almost coalesce to each other's use cases. But I also think about like, even the maturity of some of this stuff, where, you know, I think to the past where I was encouraged not to use WordPress because people I was working for were afraid that my software would look like someone else's software and they'd be able to attack my software. But what you're saying is no, it's matured to such a point where there's clarity there is observability into some of these issues, and by componentized our software development, it makes everything reusable, it makes things more predictable. And I love that. I think that's awesome. Yeah,

Jason Bahl
there's, there's a lot of we have, I don't know if I can share any other sites but there's a customer that uses WP Graph QL and they headless Knucks tights which is like the view version of next Jas but and they're they have a bunch of Webby Awards for like, they're like these super creative like, almost makes you think of like The Flash days where everything was animated and stuffs moving. And you know, like, you would never ever guessed that they're WordPress sites, you know what I mean? Like they're completely custom. But all the data is the people publishing the content still want to use a CMS they're familiar with, right? They don't want to get trained on some new system. But the front end looks completely different than anything you've ever seen, you know, so

Ryan Burgess
I love that you just called that out Jason like it is that too is because so many people are using WordPress, they may have like from the publisher side of things, their use of that their use of that editor, having to learn a new tool is frustrating. And also if you want to completely overhaul the site and make it more interactive or do something that doesn't change for the admin side of things that doesn't change for them publishing. That's just data that continually get published. But you can completely overhaul and change things from the developer perspective and what the user actually views when that data doesn't change. And I think that is really cool to call that out. I think just wanted to highlight that. Yeah,

Jason Bahl
when speaking of that, the concept of having like multiple front ends for the same back end, like like when I rebuilt my front end for WP graph ql.com. For example. At one point, I was just on a traditional WordPress site, because I needed something up fast, right? So I was like, I'm a API, but I'm, I'm just going to build in a monolithic WordPress. But on the side, I started building a front end at the time I was working at Gatsby. And so we were building a headless front end and Gatsby, which pulled in data. So I could have my traditional WordPress site rendering. On the side, I'm building a Gatsby site that's pulling in data from my WordPress. And then when I'm ready, I just flip the DNS, right? Like I can have two sites rendering the same data. And then when I decide to change from Gatsby to next, same thing, my Gatsby site is still being served to users, I start building on the side my next site, right, I'm not changing a single thing with how I published my work, you know, so like, my WordPress, CMS is unchanged. Normally, like if you're going to do a rebranding for a site running on WordPress, it's a chore you gotta like, typically, you migrate the whole database somewhere else, you activate a new theme, you know, you do all this work, and like, and then there's some day where you're like, Hey, guys, don't log in for 12 hours, right? We got to do a content free as well, we switch everything over. So you don't have to do that anymore. Like, you know, to the second you change the DNS, people could still be logged in publishing content. And your front end, developers are just building their components over here. And when they're ready, just flip it, you know, from pointing the freemen to WordPress to pointing to a next site or a svelte site or whatever you're building in? Yeah,

Ryan Burgess
I think it also makes it a little bit easier for managing data across environments to like, if you have like a local environment, test environment, staging, whatever, all the different environments, it does make it easier. I absolutely remember having to change plugins or themes or completely overhaul a WordPress site. And you're dealing with people that are still there not stopping their job, right, like you're doing this trying to do it behind the scenes. And you're right, it was not necessarily easy to do that. And it wasn't the hardest thing. Because there are ways in which like, you can develop a theme and just like switch the theme. And, you know, as long as everything works, it was pretty seamless. But I'm 100% with you is that if you can abstract that even more, it makes it that much simpler. And just, you know, you don't have to have those downtimes because businesses don't want downtime. They're like no, I want to keep going. And also, as a developer, you don't want to go oh, well, I can do it on the weekend. Or I can do it late at night. Evening, because no one's working. That sucks to like that both kind of scenarios don't work that well. Yeah.

Jason Bahl
Another cool thing, too, that we've been seen in like the JavaScript front end ecosystem is like, like WsL. For example, if you deploy something to resell, like it'll deploy every time you open a pull request your code base, right. And then what's cool is you can go look at that preview URL like that, you can look at your website at that state. So like, you can have like two different PRs, like one changes your site from blue to purple, and you can look at your blue side and your purple site or whatever. And then you can do cool stuff, like, you know, add comments to individual pages and stuff like that. So it's like, there's some really cool stuff that you can do that, like normal WordPress, you can't look at what your site looked like yesterday, or the day before. Right? But like these headless runtimes are building static assets of your site at a given point in time. And it's pretty cool. It's like time travel through your website development. And yeah, is pretty cool.

Cole Turner
I think it's so funny because I we're basically almost describing the way in which technology is cyclical and I feel like that's a theme on this podcast. But in this sense, WordPress created a development model that these technologies like Graph QL, came back around and made better. And WordPress is reaping the benefits of this iteration and innovation because now separation of concerns is becoming better. And when it becomes better developers no longer have to proliferate their changes throughout one code base. You know, you have your headless CMS over here, you have your API over there. And that separation of concerns as you're describing JSON makes things more reusable. And what I love most about this, and maybe I'm just kind of getting caught up in the moment, but it really democratizes development, in my opinion, it enables developers of all range of skill to come in and start with WordPress, add an API with WP Graph QL. And then to build their front end in such a way that you don't have to be a WordPress expert anymore. You can be a fun and expert, you can be an API expert, or you can be a WordPress expert. And I just think, you know, it's cool to see how technology continues to improve on itself. Yeah,

Jason Bahl
again, it What, like you said sick stuff is cyclical, too. I think like, CMS is like web used to be fairly static, right? It was like HTML pages that you would upload, like via FTP. And like, if you want to make a change, you got to go like change HTML and upload a new file. And Dreamweaver. Yeah. And so like, like, the performance is probably pretty good, right? It was like the static files that, you know, there wasn't server logic in between is just like, here's your file, man, like, so now. But then CMS is we're like, oh, that's hard. Like, we need to solve that. But then at the cost of, okay, now it's dynamic. Now the server is taking a hit every time people are paid. So then there's like caching that got figured out and whatever, but but now we're back to static, we're like, very popular way to build sites with Next, for example, is to output static files. So when your user hits, they're getting a static asset from CloudFlare, or whatever. And there's no server being hit, right. And so we're back to that point, like, where you can use a CMS though, but like WP graph. ql.com, for example, is all static, like you're getting, you know, 5060 millisecond responses or whatever, it's not hitting a WordPress server, all my data, or a chunk of my data is in WordPress, I have multiple data sources, like I pulled some of my Docs from markdown files and GitHub, but then like, my marketing pages, and like blog posts are in WordPress. So it's like multiple data sources come together and make one unified front end. And that's another cool part about like API's and components and stuff. But but, uh, but so we're back to that point in web development, where like, it's a static file that the user is getting served, like 20 years ago. But there's the dynamic nature, I can go hit publish, and WordPress and invalidates next cache next rebuilds the page on demand, and creates a new static file. So my users are always getting that static response, you know, 52nd, most, you know, or 50 millisecond responses. But they're seeing up to date data, you know, so I could go publish a new post, and you'd be able to see it within a couple of seconds. But the file is static, right? So it's a, it's a really cool, like, stuff is cyclical, but we're coming up with new solutions to get to the same end result that we used to have.

Ryan Burgess
I love it. Yeah, it's so great. I mean, I love going down this journey. And just like learning the updates on WordPress, because it has changed significantly, and quite frankly, made it a lot better for developers and end users. I'm curious as we before we dive into our picks, I'm curious to know, like, what are some advice that you would give someone wanting to leverage WP graph? QL? How would they get started? You know, what are things that they can maybe avoid? Making mistakes with?

Jason Bahl
Um, yeah, sure. So yeah, like anything. There's there's trade offs with any technology, right? So like, like we mentioned, one of the, one of the benefits of Graph QL is being able to fetch multiple resources in one request, right. But there's a cost to that too, right. It's not It's not magic, right, that it's the server still asked to get these resources. And so there is a tipping point. And it's not, it's not the same for everybody depends on your other plugins you have and you know, what type of data you're asking for. But there's a tipping point when asking for too much data is too much data, right, like so. So be cautious. Just because you can doesn't mean you should, right. So like, at some point, you probably still should break up your Graph QL requests into multiple requests. Not Not always, it doesn't mean like every time you fetch two resources should be two queries. Like that's not the case, but you shouldn't be calling for like 500,000 posts with their authors and the terms in their comments, like all in one payload, that doesn't make any sense, right. So use, you know, use your brain a little bit too and just be like Why would I do this outside of graph? QL? Would this make sense outside of graph? QL? Right. And if not, then it might not make sense in Graph QL to it might be easier to do. But you maybe shouldn't do it too. So there's things like that to consider. Also, with like, cache invalidation, like, we have solutions for cache invalidation. But the more data that you query, the more actions will be typed in validating that data to so like having a balance of like getting the data you need, but also what what data does the user need, right? Does the user actually need 1000 posts on the blog? Probably not, like maybe 20. And then when they scroll, maybe a load more button or you know, infinite scroll or something, you know, so be just be smart. Like, just because you can do it doesn't mean you should so those are some things you should think about. There are plugins for like I said, like there's, you know, caching plugin, there's the Graph QL plugin for ACF. There's all sorts of different stuff. But WordPress is massive. There's you know, 1000s of WordPress plugins that do lots of unique things in WordPress. And so there's definitely not coverage for everything out there. So if you need X, Y, or Z functionality, the counterpart and Graph QL might not exist yet. So you might have to roll up your sleeves and and make WordPress plugin work with the Graph QL API so that and that's true even with like the REST API to or anything else. You might have to do some custom work or find someone who can help you do it. But so there's things like that, you do lose some things, like I mentioned, like WordPress does have the whole template layer to it. If you're building sites in traditional WordPress, if you go with React or some other technology, you have to do a lot of that yourself, right? Like so fast. We we try and help with that, I would encourage you to check it out. If you're building stuff in next, like we do things like a like at the center of WordPress, whenever you visit a URL, WordPress knows how to translate that URL to figure out what type of thing it is, and return a template that matches that thing, right? Like, if you visit a user profile, like on a newspaper, you see a list of posts written by that user. So WordPress knows that that URL represents a user and should love a template of users posts, right? Or if you visit the homepage, it knows to load the homepage template. So fast like we have a we have a templating system that works very similar to WordPress Core. So you can you can build templates based on the URL that you visit. Fouse knows how to talk to Graph QL to figure out what data it is and then what templates should match. And then so you could just index provide templates that match and whichever one matches first, it will look very similar to WordPress, a lot of stuff like that. Headless developers are trying to figure out on their own, and we're trying to centralize some of that, like the stuff that you lose by decoupling WordPress, we're giving it back to you, but allowing you to take advantage of cool stuff like components that you can't do in, you know, traditional WordPress. So I love that.

Ryan Burgess
Yeah, I think also one thing I would add to maybe not so much for WP Graph QL as a best advice, but you mentioned plugins, we've actually mentioned it quite a few times in this episode is one thing I've learned over the years is use them sparingly. Like there's so many plugins out there. And you can go and add way too many plugins, I've had clients that you know, want everything and everything can be customizable. And you know, it just adds more complexity that you may not need. So that's just one piece of advice I would share. I would just

Cole Turner
say after listening to this episode, if you're not sure where to start, check out the documentation because I was looking at I've used WordPress before, but I was looking at the documentation for WP Graph QL. And it is comprehensive. And it's presented in a way that I think any developer can pick up. And so I always recommend starting off with documentation or examples. And there are plenty. We

Jason Bahl
just launched a new site last week for ACF extension two so acf.wp graph ql.com still some stuff in progress and learn but it's a for that particular extension that's even more comprehensive for just that one.

Ryan Burgess
Plugin. All right, well, that's a good time for us to jump into pics in each episode, the front end happier podcasts, we like to share pics of things that we found interesting want to share with all of you. Cool, you want to start us off?

Cole Turner
Sure today I have two picks. My first pick is Costcos Kirkland, peanut butter pretzels, which are ironically in my background right now. And they're very good for when you need a snack and I just you'll see this kind of disappear over the day. My second pick is I recently moved and my house doesn't have any forced air at the moment. And so I've picked up one of these CO2 sensors from Aranet4. And as you can see right now, even just in this episode, I'm in the yellow territory. This is where you start to get a little bit like lightheaded a little bit like you've just exercise And so this is a great sensor for reminding me when I need to open a window or go on a walk after all day sitting in virtual meetings.

Ryan Burgess
Right on Jason, what do you have for us?

Jason Bahl
Oh, man, I don't think I came prepared for this. I'll go, I'll say stream deck. So Elgato stream deck, I have this little tool so I can do. It's got buttons, you know that I can press I can do things like control my lights or whatever, you know, straight from here. So I can configure shortcuts and stuff to do things like that. I can even turn on lights and other rooms and stuff like that, just from here, or like control zoom settings or whatever. So we'll go with that.

Ryan Burgess
Yeah, no, that's a good one. I definitely leverage that one. Especially in meetings and things like that, too. You can have like raising hand or mute, unmute like there's, is it really customizable for what you want to do with it, which is pretty cool. And actually having physical buttons is great. So that's a good one. I just have one pic for this episode. I obviously been doing a lot of photography for years on my own. I loved seeing my kids get into it. And so I purchased two cameras for one for each of my kids. It's just like a small point and shoot camera. It's not an expensive one at all. But it's been really cool to see them just like using them. They're shooting video, they're taking photos. And you know, it's just it's been a really cool thing. So if people have kids want a cheap point, shoot that works. Well. I will link that in the show notes. But it's been a cool one to try out. Jason, thanks so much for joining us. This is amazing. I love taking a thank you for taking us down the journey of WordPress and WP Graph QL it's been great to learn a lot on that. Where can people get in touch with you? Yeah,

Jason Bahl
so WP graph ql.com Of course, like CO mentioned that's where the docs and everything are. I'm on Twitter at WP Graph QL or at Jason ball Jas when VHL so you find me on ER x.com I guess I still call it Twitter. What's the agreement? Do we call it Twitter? So I so called Twitter.

Ryan Burgess
We call it Twitter? Yes, definitely. Yeah, no one knows why they call

Cole Turner
it Twitter until I'm not calling it at all anymore.

Jason Bahl
Yeah, exactly. And then it on the WP graphical website if you scroll all the way to the bottom, we have a link to a Slack community so you can join that from that link with I don't know 3000 Or something people in there helping each other out, you know, building stuff with them up graph girl, so I'm pretty