Static, Headless & GraphQL with Jason Bahl

Billable Hours

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

• WP GraphQL
• Jason on Twitter
• Gatsby

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 ...