In this episode, I talk to Jason Bahl, the creator of the WP GraphQL plugin. Last year, Jason and his plugin joined Gatsby to work full time on making GraphQL more accessible to WordPress developers. Jason has a lot of knowledge to share about static and headless sites and, of course, GraphQL.

Links

Try Branch - Automated deployments for WordPress
Branch is my company and the sponsor of this podcast. Branch helps agencies and freelancers set up automated deployments for all their WordPress client sites. Listeners of this podcast get twice as many free deployments by identifying themselves in the live chat widget!

➡️ Create a free Branch account

Transcript of this episode (automatically generated)

Today I'm excited to  welcome Jason Bahl onto the show. Jason is the creator and maintainer of the GraphQL for WordPress plugin. Last year, Jason and his plugin joined Gatsby. I'm really looking forward to talking to Jason about everything, static, headless, and GraphQL. You can find Jason on Twitter at JasonBahl and the plugin on WPGraphQL.com.
Before we begin the episode, I want to tell you a bit about branch. Branch is my business and the sponsor of this podcast. It's the simplest way to set up automated deployments for your WordPress sites. We've got your back with the recipes for all the common workflows that the WordPress developers need making it super easy and fun, honestly, to build out your deployment pipelines.
It's continuous integration and deployment without the learning curve and it's free to get started. So go check it out. And if you open up the live chat widget and identify yourself as a listener of this podcast. We'll double the amount of free deployments on your account. Yep. Twice as many deployments without paying, you can sign up for free on branchci.com.
Jason, what makes a WordPress site headles?  Uh, headless WordPress site, uh, would be, we use WordPress to manage your content. So you use the admin interface that WordPress provides to manage your content, but then you use something other than the WordPress theme layer. To render the data. So that could be an iOS application.
For example, that may be used as react native or Swift or something like that to pull data from WordPress, but uses some other rendering mechanism other than the WordPress theme, API and commonly lately, we've been seeing a lot of JavaScript frameworks using their rendering mechanisms, whether it's react or Vue or Ember even, or angular or anything like that, then they'll communicate to WordPress.
Via an API and render the data with the JavaScript framework instead of the WordPress PHP theme API. So does that mean people are mostly interested in the workers, admin and not so much, like they wouldn't be using a theme for example, right? Yeah. I mean, there's obviously still a huge market that wants to use WordPress that quote unquote classic way, but yeah, there is a Ryzen.
Tooling and things specifically in the JavaScript ecosystem where you can build component-based architectures much faster, potentially scalable with a lot of benefits, like tree shaking and whatever. So like your front end performance ends up being faster, but you still need to manage data somewhere.
And instead of reinventing the wheel and building a whole CMS, It to existing stuff like WordPress, WordPress powers, what is it? Something like 38 ish percent of the web today, the top 2 million sites or whatever. And it's still, you know, a lot of content editors, a lot of teams that are writing content and posting content are familiar with it.
And they just want fast websites. Developers have been using WordPress because it's existed in people like to write content in it and there's plugins and all sorts of stuff, big ecosystem. But a lot of developers don't love the experience of developing for WordPress, right? Like stack exchange or whoever it is, does a survey every year.
And WordPress is almost always at the top of most dreaded software for developers. So, if we can give the users the experience of writing content in a system, they like, but also give developers and experience of using tools. They like the decoupled architecture can be a win for both parties and ideally a win for the users, the end users, because you have a really fast site as well.
So wait until you're basically saying if we're using headless WordPress, we won't really have to be WordPress developers. We won't really be doing WordPress development so much. Depends. So I maintain WP graph QL, which is a graph kill API for WordPress. So that does, is it exposes much of your WordPress data in an API.
So if you can get by with a lot of the core data that WordPress provides and that's all you need, uh, you can start right away consuming that data into whatever front end technology want, whether it's Gatsby or next or anything like that, or an iOS app. Oftentimes, you're going to run into points where you're at go shoot.
Like we have this certain custom data that we manage also. So depends like right now, Yoast SEO, for example, is a really popular WordPress plugin. There is an extension for Yoast that exposes Yoast data to the WP graph, kill API as well. So in that case, if there is a way to make your data that you're managing and WordPress exposed to the API, then you can start consuming data right away without having to write any PHP in WordPress.
If you're doing something with custom data and maybe there's no max for that data to the graph API, then in that case, you yourself were a developer, you know, or whoever might have to write some code to expose the data to an API. Currently I'm supporting like best custom fields, which is a very popular WordPress plugin to manage custom fields in WordPress.
So you can add metadata to posts and taxonomy terms and users and things like that. And so I have a plugin that maps all that data. You can build your forms, however you want, and maps that data to the graph API. And then there's like plugins, like custom post type UI, for example, where you can register post types and taxonomies.
So I have an extension that just adds like a little check and a couple of fields that allows you to register those to the GraphQL API as well. So we're working on all sorts of extensions. We've got WP graph kill for woo commerce. For example, maintained by Jeff Taylor WP graph kill for gravity forms maintained by Kellen mace.
So we've got a lot of community members that are bridging some popular WordPress plugins to graph QL. So that, yeah, you can be a purely react or Vue, JavaScript developer or iOS developer, for example, or Android or whatever it might be. And you can start using WordPress in many cases, without writing any PHP or any history of WordPress development.
That was pretty fascinating. Actually, when I first heard about graph QL, it wasn't immediately obvious to me what it was. Do you have maybe a simple way that you're explained to folks what graph QL is? If they've never. Work with it before then maybe they've heard it mentioned, but they don't know much about what it is or what it does.
Uh, yeah. Uh, I'll do my best. So graph QL is a query language specification for writing queries to an API and getting data returned to you in the exact shape that you asked for it in. It has some similarities to rest API, and I can get Jason responses, uh, when he asked for data. But the difference is you have one end point.
And you specify yourself, the client, whoever's asking for the data specifies down to the field, what data they want, where rest API, you specify the endpoint and the server specifies what data you'll get in response. So you have limited control or graph QL. You have to explicitly express what exactly you want.
And you'll get that in response. And you can follow relationships as well in a graph QL API with WordPress, for example. You could ask for a list of posts, but then you can also ask for the author of the post, which isn't a different entity. And then in a restful API, that would be a different endpoint.
You'd have to hit an endpoint for posts, and then you'd get an ID for the author. And then you'd have to hit an end point for the author or in graph QL. You can follow those relationships, uh, in a single request. And then you can specify the exact fields on every object type. Uh, that you want in response.
So it actually, it feels more like a SQL or something like that, where you can find ways to pull out, you know, you could join tables and do stuff like that. Yeah. There was some inspiration from SQL. So GraphQL was created by Facebook back in 2012, they use it an internally for few years, open sourced it in 2015.
And they, they were heavily inspired by SQL and some other data languages. It's also quite a bit different than SQL, but yeah, it's a, there are some similarities in that we can get multiple types of data, individual requests. So when you're using, and that we already mentioned this, like you have a plugin that helps people use graph kill with WordPress.
And when you're using your plugin, how deeply do you need to understand graph QL to benefit from using your plugin? It depends how you want to use it. I think a lot of people that use it today are JavaScript engineers. JavaScript developers are the primary users right now. Uh, so understanding how to consume graph QL would probably be important.
In my opinion, that's pretty easy to get going with there's amazing tooling to start tinkering with it. Uh, you might not know deeply, but you can feel productive within a few minutes, understanding at least the basics. So WP graph QL has when you install one of the latest versions, it has a tool called graphical built in.
So when you install it, you have this tool called graphical in your WordPress admin. And it's an IDE that lets you write graph QL queries. And it has really cool features like type ahead. So you just start typing like the word post and it will show you all the instances of posts in your graph, QL schema.
And then you can select what fields on the post you want to ask for. And then he just hit this play button. It executes a query. It gives you the data back and it feels like magic the first time you ever do it. And then you're hooked and then you use graph Gail for everything. So what your plugin does is basically you've implemented the graph cradle layer on top of like the common WordPress data models and plugins that a lot of people use and stuff like that.
Can you explain a bit how that works? Yeah. Sure. So when you saw WP graph QL, it creates a slash graph tool endpoint on your side. So it'd be site.com/graph 12. And then that allows you to set in graph QL queries to that end point and get data in response. So graph kills based on the schema. So what that means is you described the types of content or types of objects.
That your API can return. So WP graph, QL defines types in the schema for things like posts and pages and you know, categories and tags and users and comments and media and all that stuff. So it does a lot of this out of the box for you so that WordPress content just can work and then it sets up all the relationships too.
So if you set up a post type to be connected to a custom taxonomy, it automatically sets up. The ability to query those relationships like custom post type Bay. And then you can ask for taxonomy B or whatever. Uh, so it sets up a lot of that stuff for you and sets up the fields like, you know, the title of a post and the content of a post and the excerpt of a posts.
So like sets up most of the stuff that you can do in normal WordPress internally in PHB allows you to do outside of WordPress in JavaScript or whatnot. And then it provides a lot of APIs for. Plugin or theme developers on the WordPress side, in PHB to hook in and register their own fields too. And types of data to add that to the API.
So yeah, out of the box, It gives you most of the core data that you can think of that would be useful even like general settings, like the title of your website, for example, and things like that. So if I'm building a, like a JavaScript app or JavaScript based side, or if I'm building an iOS app or something like that, I can kind of like.
Make the same query. I'm thinking like the good old loop in WordPress, when you're building a theme, like you can get all that information and display it, like in a JavaScript context or like work with it in a JavaScript context, for example. Yeah, exactly. So you can do exact same thing. So you'd write a query and you specify, you want to list the posts and then on each post you want the node, which is kind of a graph QL language thing, each entity, and the graph we call it nodes.
Uh, so you can write a query that just says, Hey, I want posts. And on each post node, I want the ID, the title of the dates or whatever. And then you'll get a Jason response. So you don't quite have to do the loop. The reason you use the loop and WordPress is to handle like global state WordPress uses a lot of global state.
So like, as it loops over your data, it sets the current post in global state. And that sets the author of the post and global state and things like that. So then you can determine. Is this post allowed to be seen by the person who's asking to see it and things like that. So WP graph killed does all that behind the scenes for you.
So you can ask for a list of posts and it's going to know if you're allowed to see the posts or not, for example, behind the scenes. So it does all the global stuff that the loop would do for you behind the scenes. If you're logged in, you cast for things like draft posts, but if you're not logging. And you asked for draft posts.
You won't get any in response. It knows you're not allowed to see them. Same thing with password protected posts, like it'll expose certain fields like the title, like a WordPress homepage might do, but it won't show the content so respects, like all the access control rights or whatever the term is for WordPress content that it abstracts it away for you.
So like normally if you're building a WordPress theme, you're going to write some PHP to query some content. And then it's kind of up to you to determine with current user can functions like can the current users see this field or can they not? So WP graph QL tries to abstract that away as much as possible and say, Hey, this is how WordPress core treats data.
I'm not going to make you stress about it. Like I'm gonna respond if you have access to respond or I'm not, if you don't have access to it. And then he can granularly control that for like your site behind the scenes. If you need to, like, if there's a certain field that WordPress maybe keeps scribing, but you want to allow there's filters and whatnot to override some of that default behavior.
Let's say an agency is building like a next JS site or something like that. And they're using WordPress on the backend. So they want to use your plugin to allow that. Do you find that they typically would have to extend the plugin to get the functionality that they need or would for most use cases, it would just work out of the box.
And also like part of the question, like how extendable is it? Is it fairly easy to extend it? Like if you have extra data or something like that, Yeah, it kind of depends on what data they need. Like, uh, I would say in most cases you're probably going to extend it just like WordPress. Like it's pretty rare that I've ever seen anybody using WordPress.
With just like the default theme and no plugins. Like, I think I've been working on with WordPress for 12 years. Full-time and I don't think I've ever seen that other than just like people playing around for the first time. I don't know if I've ever seen a production site that hasn't extended WordPress in some way.
And so the graph Kelly APS is going to be the same way. It expects it to be extended. And so a lot of the work I've done is building APIs that make it easy to extend. Let's say you have a post and you want to expose a color field, for example. In the back end, you're gonna build a metal box for the user to enter some color on the post.
And in graph QL, there's a function called register graph, QL field. And so you just write a registered graph, go field, you specify the post. I want to register this to the post type in the schema, and then you give it a field name, like color. And then you just write a function to resolve it, or while you specify the type.
So you'd say, Hey, this'll be a string. This is always going to return a string. So the user knows what to expect. And then you write a result function that is past the post object, and then you can do whatever you want, like get post Metta for that post ID, the color meta field. And then you return that. So, you know, three lines of code, you can add custom fields to the graph, kale schema.
And then what's cool about that. Since it's a graph anywhere you can get to that post in the graph, that field will be available to it. So you can ask for lists of posts, for example, and then ask for the color field of each post. Or you can ask for one individual post by ID maybe, and he could ask for the color filled on that post, or you can ask for a specific category or tag, and then the posts within that tag.
And then you can get the color field on that post. So with three lines of code, you can have SS this color field of every post, like a hundred different ways where like, in rest, for example, the rest API you'd have to register an endpoint and then register fields, like you'd have your post endpoint and it would show up there.
But if you wanted to specify, like I want featured posts or something, Well shoot. Now I got to go register a new end point and then I got to specify what fields on that end point is like not everywhere. A post shows up in the rest API. Is it treated the same as, because you want to control usually like you don't want to over-deliver data in rest, both graph QL you, the consumer specifies what they need.
So you don't have to worry that, but that problem, the server can say, here's, what's possible for you to ask for. But then it leaves it up to the client to actually ask for it when they need it. You have the ability to extend on the server as much less involved than extending the rest API and certainly like Dex all our QC API.
Yeah. It sounds like it's pretty extendable. That's awesome to hear.
This next question might be slightly politically loaded. Maybe. I dunno. Maybe even like slightly explosive topic, but why would we need the rest API, if we're half your plugin? Like why would you choose the rest API over? Well, for example, so graph QL is new. Obviously rest is a technology has been around for what, 20 years or something like that.
So it's familiar for folks, right? Also rest API for WordPress is actually in WordPress core. So I think that's probably the biggest reason is, you know, it's always there on every site, WP graph kill right now as a plugin. If you're building a plugin and want to use graph QL in the admin of WordPress, for example, well, there's no guaranteeing graph kills going to be there unless you ask the user to also installed this other plugins.
So that's a big trade off, right? Like right now as a plugin, more targeting like agencies and whatnot that want to. They'll decoupled sites or even build stuff coupled like you can use Graphco within PHP too. It doesn't have to be JavaScript or iOS or whatever. But yeah, the target is, since it's not in core, you're limited on how you can use it unless you want to like bug your users.
Hey, install this dependency also, which is not a common thing I would say in WordPress. So I think that's the biggest trade-off is it's not in core. Will it ever be in court? I don't know. That's a loaded thing. Graph QL is evolving outside of WordPress. Right. And if I want to keep up to date and we're is really committed to backward compatibility, right?
We decided today as a community, Hey, let's get graph QL and decor and graph QL decides they release a new spec every six months. So the graph killed today might not be the graph QL of six months from now. And so WordPress has a decision to make like. Do we actually make a breaking change or do we have two versions of graph QL with a lot of technical debt?
I mean, WordPress is obviously not scared of technical debt. So you, you kind of like, do we evolve with the world or do we freeze in time? And, uh, as a plugin allows us to, you know, opt in, if it's a valuable thing for your project, but we can also keep up and you can opt often to whatever version makes sense for your project.
So if we make breaking changes, you can often when you're ready to. Uh, where if it's in core, you're stuck with whatever decisions were made the day it landed in core. So like the rest API, for example, came in what, late 2016, I think. And we've seen extremely little changes to it over the years, other than minor things to support Gutenberg.
We're seeing application passwords coming in this next version, which is cool. WP graphical works with that too. So you do authenticate and stuff with application passwords, but yeah, the rest API has seen very little evolution over the four years. It's been in core and I think it's graph kill word and I can in core, we'd see the same thing.
The rest of the world would continue evolving graph QL and WordPress would be stuck on whatever version you're seeing people using the rest API for their headless sites, as well as the Kraft Carell plugin. Yeah, for sure. I would say the rest API can be a little bit easier maybe sometimes to get started with, because all you do is hit an end point and boom, like you got a bunch of Jace on data where with graph, Joel, you actually have to write a query.
So you have to understand a little bit of the semantics of how to write a query there's tooling, like graphical, for example, that makes it, I would say pretty easy to get started with how to write a query. You do have to understand the nuances of it. Uh, we're with rests. It's like you hit an endpoint and boom, you've got some data and then you do something with the data.
So it starts off a little bit easy with the rest. It can get hard when you start doing stuff like relational data, like, Oh, I need a list to post, but then I need the author and then I need the authors avatar. So now I'm hitting a post end point, an author end point and avatar end point. And then I got to figure out how to cache all this stuff.
And then I gotta figure out when do I render it? Do I have to wait for all three end points to hit? So like it starts easy, but can get more complicated, faster graph QL, probably I would say starts maybe a little more complicated because you got to learn this new language. If you've never seen him before.
Then you got to figure out, okay, how do I make this as an HTTP request? There's tooling that helps, like there's a client called a Paulo and they support like react and view and iOS, for example. So pretty much any front end that you're going to be working in, you can use Apollo with and they obstruct a lot of things.
So you just write your graph, QL query the same way you would in the graphical IDE. And then you could just copy that string that you wrote as a query and paste it into Apollo. Paul handles like all the magic of making an HTTP request, getting the data, caching it, normalizing it. So then you can reuse it throughout your application without having to talk back to the server.
So there's tuning and graphical. That makes it easier. But I think it's more complicated to start. So I work at Gatsby, which is a static site generator based on react. Uh, you can build really cool stuff, not just that excites. You can build applications with it and everything to Gatsby before I had joined had a WordPress source plugin, which allowed you to get data from WordPress, from the rest API.
Beyond like very basic sites, people ran into issues pretty quickly. And the reason is because the rest API in WordPress doesn't enforce a schema. So a decoupled application like Gatsby doesn't know what is possible to be returned from WordPress. It just like all of a sudden gets data. So Gatsby does have the graph QL layer itself.
And it needs a consistent data source basically to work well. I think any application really needs consistency to work well, but when you're talking decoupled architectures, you really need that. You need, Hey, you promised me you're going to give me this. And all of a sudden, give me something different. I don't know what to do.
And the rest API is guilty of that. It doesn't enforce a schema. And so deep couple of applications don't know what to expect. So if you install like. Advanced custom fields for the rest API, and you start populating advanced custom fields in your WordPress site. Every single post in your rest API response is going to have a different shape of data.
And there's no way for a decoupled client to know ahead of time. What's possible. It's just like, Hey, you're going to get some data, but like prepare for literally anything, because I can't tell you how to time. And so folks ran into issues really fast using Gatsby with WordPress. And honestly, it's not a Gatsby specific thing, any decoupled architecture you're going to run into issues.
You can't predict what you're going to get at that time. And so graph QL enforces a schema. So like you can't use graph QL if you don't declare ahead of time. What's possible to be returned like advanced custom fields, the pro version, which I think most users are probably familiar with has a feature called flex fields.
And what that means is like you can return a field that is one of many different shapes, similar to Gutenberg blocks, right? It could be an image block. It could be a paragraph. It could be one of many things. So if that's because some fields has this feature where you can define the layouts, they call them.
And it could be a group of fields with a text field, or it could be an image field, or it could be a select field, or it could be a user field. And for decoupled application, you need to know ahead of time, what your possibilities are. Can it be one of these five things or can it be something else? And so graph QL solves that by saying, Hey, you don't even have to ask for data, but I can tell you it's going to be one of these sub set of options.
And then something like Gatsby, we can prepare for that and say, okay, I'm now prepared to accept any of these five things. And if you don't return that, then like you're the one screwing up and you need to fix it. Right. So, yeah, that's a big thing. Even on basic sites, you get burned pretty quick. I think using the rest API, there's like funky stuff too.
Like if you asked for a media item, for example, it'll tell you the parent ID apparent of a media item could be of any post type. And you're given an ID, but you don't know what type, so you don't know, end point to hit. So you'd have to iterate over every possible post type endpoint, just to figure out what the parent of media item is.
And so there's just like quirky things like that. That if you start building something and trap ticket production, you'll get burned pretty quick. Yeah. Like when I think about it, like, it seems like graph Carroll is more pragmatic. Basically the client creates their own end points in a sense. And with, with rest, it's like, it's more idealistic because it's like, we want to fit everything into this breast full model.
Where each entity has like their own end points for like index for all of them and like show for a single item. And we try to like religiously like fit everything into this restful model. Whereas with graph curl, it's much more pragmatic. It's like, okay, well this page, I actually just need these three things.
And like these other things and a fourth. Thing. And like you just kind of like put together what you need and kind of like also what it makes me think of as an analogy. It's like, when I open up my SQL editor, basically, you know, to look at my database, if I just click the table name, it just shows all the data.
And that's kind of like reminds me of like a wrist end point. But then when I go to like the query builder, I can just query for enjoying like the specific data I want. And that's more like what you we're able to do with graph QL. Yeah. That's a pretty good analogy. I think one different SQL you can do like select star queries, and then it'll give you everything from a table that doesn't exist in graph, QL graph, QL enforces.
You have to specify the fields you want. There's tooling out there that like you can start typing it. And it will, pre-fill literally every field or like graphical. If you install WP graph, kill, you, get the graphical in the WordPress admin. And it has like this checkbox builder where you can like, build like what fields you want on a post.
So you can do similar things. But you still do have to be explicit. And you have to say, if I want everything, you actually have to explicitly define what you mean by everything. And you're going to stop somewhere, right? Because a graph QL, the nature of it being a graph, you can follow those relationships.
So you're going to have to stop somewhere. Otherwise you get in these like endless recursive loops, cause you could ask for the post and then the tag of the post and then the posts within the tag and then the posts and then the tags of that post. And then the posts of that tag, you have to tell graph QL, like when you want to stop.
So there's constraints like that. That can be like maybe a little confusing at first or whatever, but. I think like when you start working with it, you're like, Oh shoot, like this is saving me from doing something stupid. Cause you can do the same thing with rest, right? Like you could write a function to go get a post endpoint and then follow up to get the tag end point and then get the, like you could accidentally find yourself in that side as a consumer of a rest endpoint.
Um, we're graph. Gail says, Hey, you don't have to tell me when to stop and then I'll stop. Yeah. It's just a whole different, like way of doing things. And I remember the first time I interacted with the graph queue graph, Joel API was to get hub API and suddenly it's like, it's no longer rate limiting. And like, in terms of like how many.
Requests, you can make, like each request has like points for, or credits for like how advanced Aquarius, because, you know, you can make one query that's really, really heavy because you're querying for so many relations. So they'd have a credit system based on that and they charge per request. So that's just like a different paradigm.
Switching gears a little bit here. We talked about like how a site can be headless. The next thing I kind of want to hear is what makes the sites static. Uh, yeah, sure. So static site would essentially be a, yeah. You have your content and your templates, all prebuilt and deployed to a CDM. The actual pages will be served from the edge instead of the user, having to make a request and executing PHP, which executes my SQL, which then builds the template and then return something.
So that's kind of like the normal WordPress flow. Obviously you can put a like page cache in front of it. Which is essentially it makes him sad, excited at that point. Yeah. So static would just be like, you have just a prebuilt page. That's served from a CDN is kind of the most basic definition and one example of a static side.
Generator right. Is Gatsby essentially the company behind Gatsby also acquired your plugin and essentially, I guess, equity hired you to work on this plugin. Full-time right. Like, can you kind of explain the setup there? Yeah. So yeah, I'm an employee of Gaspe now, uh, WP graph, Gil's a GPL community project.
I'm maintaining it for the community. You don't have to use Gatsby to use it so you can use it with whatever you want. Next or any grids on which is like a view competitor, uh, iOS apps, like anything you want. Build PHP themes and use graph killer, like it's to benefit everybody, but Gatsby is investing pretty hard in making the WordPress plus Gatsby experience a good one.
I've been working on it for a little over a year and there's two parts to it. So I'm working on the API side of WordPress to expose data from WordPress. And then I have a coworker Tyler who's working on the consuming side, getting data from WordPress into Gatsby, so that then you can use all your work with data that.
WP graphical exposes in Gatsby with your react components. And then you can also use it alongside other data sources. Like, like a lot of places I've worked, I've built websites where 90% of the contents in WordPress, but the HR team always wants to plan and job postings and some other system. Right. But like, I think that was pretty common.
And so like, you got like all your content come from WordPress and now you're like, Oh shoot. Like how do we render this data from this other. Third party. It's like, I guess we'll I frame it, you know, like who knows, like whatever we'll have guests, we can pull on a source plug-in from WordPress and then he could pull on a source plugin from whatever other like.
Job management API that they're using. And then you can source both things, build your react components with the same styles and the same, everything, the same component libraries that you're using. Then it outputs a static page that you can serve from a CDN. So instead of having like the user load, your job listing page, and then it has to wait for some live requests to some remote service to figure out and then render.
So like, People are waiting three seconds to see a job listing it's prebuilt. Right? So the way Gatsby works, it fetches the data ahead of time. You write components or pages dope out of components and then a composite to a static HTML page, and then it on queues react, uh, when the client visits the page, but a lot of guests besides you can use without JavaScript at all, not everyone, some of them depends on how they're built.
Um, but a lot of them, you can turn off JavaScript and you just have a static HTML page and it's going to load in milliseconds. And every time the user is visiting the page, it's not talking toward press directly. It already talked to word, press once and built the page. And then what we're doing also, we have another plugin called WP Gatsby, that kind of tracks activity on the WordPress side.
So it's another WordPress plugin. You install. And as you're making changes, like, you know, you fix a typo in the title of a post. It sends notices to Gatsby saying, Hey, this content changed. And then Gatsby says, Oh cool. Like you let me know that a post changed Gatsby tracks aware all the pages of posts content would live.
So WordPress sends notification WP Gatsby sends a notification. Gaspe saying something changed Gatsby. Then rebuilds just the parts of the Gatsby site that were affected by that change. It's called the incremental builds. So then within a few seconds, in many cases, you're. Static site is rebuilt, and now you have a really blazing, fast static site for your users, but a dynamic editing experience still.
And you could potentially be sourcing from multiple data sources. It's not limited to just WordPress. Something that a lot of more precise have installed is a, some form of form builder. How does that work if you're running a static side? Like, can you still have forms on your website? Yeah, you can. I would say currently the integration between like Gatsby and WordPress form builders, it's got work to do still there's like dub hate graph Gil for gravity forms, which has maintained by killing mice.
And he uses it for a pretty big project. He was building. So it does work. There are options. Maybe a little complicated at the moment, but you can also use other things like, uh, format. I think they have a cloud service now. It's like, you can build like these rec forums and then you submit it to their cloud service.
So you can put it in a static page and it'll submit, or you can use there's all sorts of forums as a service libraries out there. Um, so you can definitely use a lot of those as far as submitting back to WordPress. Right now, we have probably a ways to go before we like have a real good solution on that.
You can do it on your own right now, though. WP graft kills, kill supporting mutations. So we've talked a lot about querying data, like getting data out of WordPress, but don't you figure out if kill also supports mutations, which is writing data back to WordPress. That was actually like the original use case of WP graph go.
I worked at a newspaper and we syndicated a lot of content. We had a network of 54 PHP sites that had to talk to each other. And so graph kills primary use case or non was sending data to other WordPress sites. So you can do that. You can register mutations, like you could register a mutation for contact form, for example, and you can specify what fields you want to accept.
And then you could fill the form and a reactor view or whatever you're using. When the user clicks submit, it would submit a mutation to graphical API. So you could register a post type or even hook into an existing form plugin. And have a mutation that saves the data in however, you're saving it in WordPress for it to be kind of like out of the box with form builders.
We do have a ways to go on that, but you can do it today. If you don't mind writing a little bit of code. That's one thing that's kind of like different from like the normal, like WordPress paradigm. I guess another thing I'm thinking about is hosting. Like, I guess you still need to host a backend somewhere, but then the Gatsby side, or like you mentioned a CDN, but like, can you explain just kind of like, what does the hosting look like?
Sure. Yeah. So depending on your setup, if you're the only author, like if it's a personal blog or something, and you're the only person that's editing content, you can potentially just even use it to like local by flywheel or something like that, maybe. But if you have more than one person and you know, don't want it on your local machine.
Yeah. You're probably going to have to host WordPress somewhere. The benefit though is if you're using something other than WordPress as the front end, You don't have to support the front end traffic. So if you were paying X amount of dollars to support a hundred thousand views a month or whatever, you don't have to support that anymore.
You just have to support the editors of the content. So if you have five people writing content and a hundred thousand people visiting the site, you really only have to support those five people now. So. You might be able to cut costs quite a bit on the WordPress hosting, but then yeah, you do have to host your static output somewhere of the Gatsby site.
Like GitHub pages, even like you can host like static files on Netlify has a free hosting you can pay for like Netlify builds. So like you can hook up your WordPress site to send notifications to Netlify to build. So gasoline cloud is a service that we have now. Okay. So there's actually one thing we didn't talk about guests and cloud has a thing called preview.
When you go decoupled with WordPress, you lose out on a couple of things that you get for free and WordPress and preview as one of them. So gasoline cloud brings that back. You can build your site in react and Gatsby, and then you can click preview. And if you're using Gatsby cloud, you will see your preview in Gatsby.
So it's super cool experience, but yeah, so you get that with Gatsby cloud and the Gatsby cloud right now is a build service that can deploy to any host you want. So you would hook up your WP Gatsby plugin in your WordPress admin to point to Gatsby cloud. Whenever you make a change in your content, it would notify Gatsby cloud gastric cloud would do the incremental build and then it would deploy to whatever CDN pick that is supportive.
So they get deployed in Netlify or. Look, Amazon S3 or whatever CDN that you configure. Um, some of them are free or extremely cheap. Like my doc site docs dot WP sql.com is on Netlify today and I'm not paying for it. Yeah, the free hosting is definitely a benefit of building these static sites and having everything behind a CDN is great.
It should be pretty hard to like Dede us a static site, unless you can take down cloud flare or something like that. Yeah. The whole world has got problems on their hands. Yeah, I think so.
Jason, this is really cool. I think this is a great introduction to some of the concepts here, and I think maybe a good introduction for people to not know everything, but maybe just enough to get their feet wet and maybe just install the plugin and kind of like play around with the graphical editor.
And just see it for themselves, because obviously it's harder this audio format, it's hard to explain all this stuff and it's probably helps to see it. So, yeah, Jason, I really appreciate your time. This was super interesting to hear about and I'm sure people find this helpful. Yeah. Thanks for having me.
Awesome. We'll talk to you later. Take care.erPdrOW o