Welcome to Press This, the WordPress community podcast from WMR. Here host David Vogelpohl sits down with guests from around the community to talk about the biggest issues facing WordPress developers. The following is a transcription of the original recording.
David Vogelpohl: Hello everyone and welcome to Press This the WordPress community podcasts on WMR. This is your host, David Vogelpohl, I support the WordPress community through my role at WP Engine, and I love to bring the best of the community to you hear every week on press this as a reminder, you can find me on Twitter @wpdavidv, or you can subscribe to press this on iTunes, iHeartRadio, Spotify, or download the latest episodes at wmr.fm. In this episode, we should have done it at like Halloween time because we’re going to talk about is the rise of headless WordPress with Jason Bahl, the creator of WP Graph QL, Jason, welcome to Press This.
Jason Bahl: Yeah, thanks for having me.
DV: So glad to have you here and of course we don’t mean like the horror show version of headless WordPress but a couple of JavaScript in WordPress and all this other kind of things. So for those listening today. Jason, comes to us, he’s from WP engine the place I work at as well, but he’s also immensely popular in the headless WordPress space crater WP Graph QL, but he’s going to be sharing his thoughts today about why WordPress is playing such a big role and headless, what it takes to start using headless for your site, WordPress site, and some of his favorite tools and approaches for building with headless really grateful to have him on today to talk about this coming from a very important with you. Jason, I asked this question of all my guests I’m very curious about your answer. Briefly tell me your request origin story.
JB: Yeah, sure. So I think it was 2008 I believe I was doing a lot of flash website building, and my cousin. Want a website where he can manage the content I was like, Oh man, that’s not that easy to do with a flash site. So I was looking into various ways of hooking up some sort of CMS to a flash site and that’s when I discovered WordPress had an XML RPC, and used WordPress at the time, found out about this API that could work with flash site I ended up not building anything to connect the two, but found WordPress started playing with it and have been working full time in WordPress pretty much ever since.
DV: I feel like that’s a very apropos origin story for you, Jason. Yeah, like you’re basically trying to set up WordPress to leverage flashers the front end back in 2008. And this was pre custom post types and custom meta fields which would have been released in 2010 So you were trying to do this before. WordPress even had that kind of data organization layer, as part of core.
JB: Yeah, back then. I think the common approach was to like set up different categories to act as a custom post type essentially it’s like, if, if this post is categorized a certain way treated differently, was, was kind of approached back then. But yeah, I hadn’t even heard of WordPress back then I set it up, took me longer than the five minutes that was advertised. But, but, yeah, I fell in love with it right away I was like, I’ve never, never experienced something that felt so powerful to like give users the ability to create for the web.
DV: very apropos you’re definitely the first guest to have a headless WordPress SEO origin story. You recently joined WP Engine tell me what you do there.
JB: Yes, so I started WP Graph QL as an open source project. Back in, let’s see 2016 and been working on that largely as a side project I worked the last year and a half at Gatsby, working on it, and then come over to WP Engine my role against who’s going to transition to work on not WordPress as much. So WP Engine saw that it was a, an important project to keep pushing forward. WordPress into the modern era. And so I’m, I’m here at WP engine still working primarily on WP Graph QL and its immediate ecosystem like currently today I’m working on WP Graph QL for advanced custom fields which is an extension I maintain to bridge those two worlds together. But yes I’m mostly working on pushing forward WP Graph QL immediately ecosystem, and then working with other teams here at WP Engine that are focusing on headless WordPress and helping them. You know just navigate the waters, and make work headless WordPress experience for everybody.
DV: That’s great. You get to continue to work there for WP Graph QL I know so many people who rely on it, and I’m glad to hear about you kind of working on those extensions, particularly there with ACF. For those that are listening though that may be unfamiliar. What is headless WordPress.
JB: Yeah so headless WordPress would be where you use WordPress, as the content management system so users would log in and manage data there. But you would use the data, you would render the data in something other than the built in WordPress theme layer. So very common are pretty easy to understand example I guess would be like a native iOS application that needed to get data out of WordPress. Since there’s no PHP theme layer in an iPhone or an Android phone, you need to serve that data, some other way. And so, usually that’s done through an API like WordPress REST API, or in my case back in the day with Flash there’s an XML RPC API or web Graph QL today. So treats your content, separate than your presentation, and allows different presentation layers to do something with the data could be an iOS app or the biggest trend is JavaScript applications like React or view our JavaScript frameworks that can take data out of WordPress and render them. We got native apps. You can even do like voice apps like Alexa skills to get data out of WordPress and read the news for example, or whatever.
DV: There have been many interviews on headless over the years, and I feel like every single person I’ve talked to that including off air and everything else, when they hear headless WordPress they think decoupled JavaScript. But you talk about it in the lens of like just a different rendering front end. The end noted, iOS app and we maybe perhaps if you could wind the clock back the flash app, but do you find it’s common that people like make that assumption that it’s the decouple JavaScript approach.
JB: Yeah, I think, I think given a lot of people’s minds, they are synonymous. I think there’s a obviously JavaScript is wildly popular right now. I mean it has been growing for a long time. So yeah, a lot of people in their mind they think they think they’re synonymous, and to a large degree, they kind of are, but yeah it’s it’s wider than that. Like, When WP when I started WP Graph QL our first use case for it was syndicating content from one WordPress install to many other WordPress installs. So it was actually PHP to PHP communication, but we just needed the data, we didn’t. We just needed the data accessible from something other than the WordPress install it was managed on. And so I think that’s the, yeah that’s the broader term but I do see a lot of people that just assume it means Oh using it with React or using it with Gatsby or next or something like that.
DV: Yeah, I find that path is pretty familiar to a lot of folks in terms of like these needs to make WordPress extensible. And, you know, not realizing that if you just lopped off the rendering part you essentially have a headless WordPress once this gets interesting, like how more out perhaps that notion or that realization, might make the decoupled JavaScript part approach more approachable for folks, because it’s it’s really just an extension using new technology that’s something that WordPress developers have probably been doing their whole WordPress career.
JB: One thing I like to note too is it doesn’t have to be like an all in thing, right, like, you can still use parts of WordPress to render things and maybe something else to render other things like the native iOS app, like get the newspaper I worked at, where we use WordPress theming layer for the regular Word WordPress sites, but we had our iOS apps also so we had WordPress rendering for the web. We had iOS apps getting data from an API. And then we had like a separate data warehouse team that was also getting data from the API. So, and then we use the content for print, as well, so we had all these different rendering engines and WordPress itself was one of them.
DV: We need a word for this like the Hydra or something with all these heads. It’s such an interesting construct to think about because so many people have assumptions going into what to what it means and some of it seems foreign to folks and then familiar. But then if you look at kind of the base components, it’s very similar what folks have been doing for a really long time. Thank you for that overview really really helpful. Now I want to kind of dive next into like well what are some of the benefits that that headless WordPress provides but we’re gonna take a quick break and we’ll be right back.
DV: Hello everyone, welcome back to press this the WordPress community podcast WMR. We’re interviewing Jason Bahl about headless WordPress, Jason right before the break you explained what headless WordPress was and a lot of different contexts love that by the way. So I kind of want to now transition into like well why, and maybe more in the decoupled JavaScript sense but like what benefits is headless WordPress provide.
JB: Yeah, so, yeah, when we’re talking about benefits to headless WordPress, just, I think, I think you’d benefit by separating concerns already so if you separate your data from your presentation I think that benefits, multiple parties, developers, especially, but if you can focus on inputting content and not have to worry about how it’s going to be rendered. I think that frees the creative process of creating content. And then for the developers, it allows them to use data that’s managed in WordPress in various ways without restriction, I guess, to like the templating engine of WordPress itself. And then there’s some cases like already talked about mobile, but some, some cases, there’s no way to natively do WordPress on as a native app so you have to get the data from an API so it benefits, benefits, developers, and content publishers by being able to separate the content from presentation. The way I look at it, it allows content creators to use a CMS that they probably already familiar with 40% of the web is publishing with WordPress today. It allows developers to pick and choose the tools they want to use so whether that’s react or view or WordPress and PHP or something else, they can, they can pick the front end technology they want or are required to use or whatever. And then, one of the big driving forces behind, especially the JavaScript movement is performance and security. So by decoupling your WordPress your CMS from your front end, like something like Gatsby, Max can take data from WordPress and statically build pages that are deployed to a CDN. And so when the end user visits your website, you get no second response of the page, because there’s no live interaction back to the CMS. So the pages are built ahead of time. And so that’s one of the big driving forces is the performance and security benefits of things like Gatsby or next that take data out of the API, filled with templates deployed to CDN around the world. And then users aren’t interacting with a live CMS so that’s I think that’s one of the big draws to especially the JavaScript.
DV: Yeah, it’s funny you didn’t mention this first I think every time I’ve talked to someone about this in the past, like provides insecurity and that’s the first thing full page caching is possible outside of, you know, the couple JavaScript approach. Why is it unique or special for the couple JavaScript, headless WordPress builds.
JB: Yeah so okay so yeah this is an interesting thing too, so I think it goes slightly beyond that even. Yeah, of course you can do you can make WordPress really fast, but a part of it’s the developer experience around it too, right. If you’re traditionally in WordPress, you have your templates in PHP, you have your JavaScript in a JavaScript file Yeah, your CSS and CSS file with SASS or laughs or something right. And so we’re separating, where we try and separate concerns by technology, not by actual concern. And this rise of like component based architectures, especially in view and react allows you to couple your concerns if you can build components, where all the concerns of an individual component let’s say we’re building like an author bio box at the bottom of a blog post that that component requires certain styles or requires certain data that requires certain markup. And in a traditional WordPress theme you’re going to have separate files, where you have to manage different technologies and different files, even though they all are related to this one thing with component based architecture you can bundle all that into a single component. And then down the road as your application changes. All you have to do is modify that component, the styles the data requirements, and, and the markup are all in one place. If you go look at like most WordPress sites that have been around for more than six months go inspect the css, scroll to the bottom and you’re gonna find a bunch of important tags in the CSS because over time, your markup changes, you know your whatever else changes and it’s very difficult to clean up your tech debt over time because you’re concerned, you’ve separated technology not concerns. And so, separating your data from your markup allows you to take advantage of component based architecture. Sorry, my wife’s got some advice here.
JB: Yeah so separating separating the data from the presentation layer allows you to use component based architecture in a way that you can efficiently do in WordPress with PHP templating. So that’s a big thing so the tech that gets cleaned up as you build if you adopt the component based architecture. And then, yeah, the deploys to CD ends. Yeah, that this can be done in WordPress. Right, I know there’s like strategy I think does this type of thing, and other hosts do it where they cache your whole page, but there’s no way, like, there’s no good way to optimize like your assets for any given page so you can deploy a WordPress page to CDN, but the JavaScript you’re loading for the CSS you’re loading for it is probably not all necessary for any given page, where the decoupled approach, will, will put your stuff through a build tool only include the styles you need for any given page only the JavaScript to you for any given page so when it is served from a CDN. Typically, it’s much smaller files that the user has to wait to download
DV: I remember that from my very first sinner days internet days back in 1996 less data was faster. Oh, I can. Okay so this is like from the high level the benefits you get benefits around performance and security and certainly how your team works on your site and the capabilities they have prototype building modifications and Tech Decks, there’s always benefits. Somebody is like interested though they’re like okay, I’m gonna give it a shot. What skills or tools do teams need to have in order to build a headless WordPress site. And for the rest of the interview Jason when I say headless WordPress she’s saying a couple jobs.
JB: Yes. Yes. So I think there’s two sides to it, right, there’s, there’s obviously the WordPress side which is a PHP based and MySQL based CMS. So if you need to expose data from the CMS, that is not already exposed by something like WP Graph QL, you would need PHP and probably MySQL skills at some level and some understanding of how WordPress works and, you know, capabilities and permissions and things like that,
DV: like a normal WordPress developer, those kind of skills you need, because you’re gonna have to get the data out into the JavaScript side.
JB: And then on the flip side, you would need some experience with JavaScript, react and view, tend to be the leaders in this space. So if you have familiarity with either of those frameworks, that’ll go a long way. And then there’s obviously different API’s to work with WordPress as the REST API, like I did with XML RPC or Graph QL so I’ll, I’ll push toward the Graph QL. So having some familiarity with what Graph QL in general, is WP Graph QL specifically with would go a long way.
DV: So, we’ve got, like, first and foremost is, obviously, It’s an organization that has a WordPress developers, familiar with PHP MySQL certainly HTML, CSS, but then you need to build the JavaScript, rendering side so that there you kind of talked about reactant view. And you then need to connect the WordPress content side, to the JavaScript side. And for that you need an API, and you’ve mentioned kind of the REST API within WordPress itself, or a third party solution like WP Graph QL. Yeah. Okay. And so as organizations look at potentially adopting this approach. I’m just curious, real quick, if they’ve learned react if they’ve started building like Gutenberg blocks is that helped them in this journey to starting to build these react rendering apps or is it still just like so far apart it’s just this huge learn JavaScript deeply journey and again just real quick response on that.
JB: Yeah, I think, yeah guna Grimberg experience will help quite a bit, it’s not going to translate necessarily like perfectly, but the experience of using React and components and state management and things like that would translate pretty good.
DV: Okay, you remember Matt Mullenweg asking everyone to learn JavaScript deeply.
JB: Yeah, I was in, I was in the room that day.
DV: Oh in Philly, you were so funny. Do you remember how many people was it. Were you one of the people that, that wooted when he said that?
JB: Possible
DV: you and Zach Gordon maybe are like the only people that were like Yeah, yeah. It’s really kind of interesting. All right, cool. I actually have a ton of more questions, but we’re gonna take another quick break and we’ll be right back.
DV: Hello everyone welcome back to Press This WordPress community podcast on WMR. We’re interviewing Jason Bahl about headless WordPress, Jason right before the break, you gave us kind of a quick rundown of the tools and experience that people would need in order to start building with headless thank you for that. It’s also mentioned WP Graph QL few times maybe you haven’t given us a ton of details. So what is WP Graph QL, and why did you recently double the price.
JB: Yeah. So what is WP Graph QL. So it’s a free, open source WordPress plugin that, that turns any wordpress site into a Graph QL server. What that means is, your site will be given a Graph QL endpoint so like your site.com slash Graph QL and then request can be made to that endpoint specifying exactly what data you want out of the API. So similar to rest in that you’re, you make a request to the API and you get JSON responses with the differences you specify in order to interact with the Graph QL API, you have to specify exactly what data you want out of it with rest you say, I want to hit this endpoint and whatever the server gives me. I have to be okay with where with Graph QL you specify ahead of time, exactly what you want so you can query, you know, posts and just the title of the post, and you’ll get exactly that response, or you can even follow resources so you say I want a list of posts with their title, and I also want the author and the author’s name, and maybe I even want the author’s five most recent posts. So you can do all this in one request, and you can specify down to the field exactly what you want. Will redress doing the same thing you’d have to hit the post endpoint, give a JSON payload back which would include the author id and enough to make request back to get all the authors of all 10 posts that he just received, then you have to wait for that, and then you have to make another request to get the recent posts from each author. So it puts a lot of burden on the application developer that’s interacting with the API where Graph QL gives you a lot more freedom and control and allows a lot less data to be transferred from the server to the client. This is next gen
DV: yeah like a way to describe that, you know, just imagine someone’s like listening to this podcast right now and like they’re multitasking and they’re writing a parsing script for some REST API response that’s like scattered with random that they’re like oh my gosh I got to parse this all out, it’s like, it’s a real problem as developers work with it I imagine people use WP Graph QL for a lot more than decoupled JavaScript. Is that true,
JB: yeah the first use case I mentioned it earlier the our first use case was syndicating content from PHP servers to other PHP servers. And part of it was the, the amount of data we were sending over the wire was painful and the amount of round trips we had to make to get all the data, like when you, when you syndicate a blog post. You’re not just syndicating the posts, you’re syndicating the author, the posts and the terms the taxonomy terms that are associated with it and the media. So there’s all sorts of network round trips, we were doing with Ras or with Graph QL we could specify exactly what we needed and make one request for it, and it would have made the developer process much easier because they were making one request and it’s very explicit so even six months down the road even if something wasn’t working. It was explicit what we needed, and then we can pinpoint that with rest It’s like something changed on any given endpoint. It’s hard to know what it was before because the coaches says hey give me this resource, And you don’t, as a developer trying to troubleshoot that you don’t know what it was yesterday versus today with Graph QL you know exactly what the consumer was asking for. So, it’s a lot easier to troubleshoot.
DV: Yeah. Gotcha. So like, you’re not like lost in the weeds with all this parsing and you’re not slamming your request server with request because you’re making more efficient requests which are easier for you as a developer to deal with. I love that rundown. You mentioned earlier that you’re working to make WP Graph QL extension for ACF better, that’s cool. Also, I was joking earlier Chris about doubling the price from $0 to $0. But you obviously have a lot going on. What are you working on a WP Engine that you’re excited about.
JB: Yeah so I mean my work is done for Graph QL and the engine are pretty much synonymous, I do collaborate with other teams that are working on the headless space so I would say don’t be Graph QL for advanced custom fields we’re doing some big changes to that I published like a preview video of a feature I’m working on just yesterday but YouTube. So that’ll be probably published to the plugin. This week it’s a big refactor of how location rules map to the schema. So ACF is a big one. I’m working like I collaborate with external teams like the team that’s working on WP Graph QL for Gravity Forms. Like I chat with them and help, help them lead the development on that plugin. One thing that’s, that’s happening is, plugins are taking ownership of the graphical interactions themselves. So, like custom post type UI popular plugin for adding custom post types. Just took ownership of the Graph QL integration I used to have an extension that bridged WP Graph QL and that plugin, They merged that into their plugin of their owning that interaction. Now, the events calendar, had a Graph QL extension and in February, they took ownership of that as well, it’s not bundled into the events calendar core but they took ownership of maintaining it and use it for you as it can.
DV: Painter to keep up with all these different integrations and plugins, it’s good to see that that’s a really positive sign for momentum in the VP graph UI view. Yeah. Anyway, getting out of their way to spend their own time to maintain it. Are there.
JB: Yeah, exactly. And then Yoast is doing the same thing now before that they’re working on right now or a branch of the Yoast WordPress SEO by Yoast, that they’re working on. Going the integration themselves as well so I think that’s one of the things that excites me the most is just how much the community is saying hey, this thing’s important. Let’s kind of rally around it, share ownership of it.
DV: Yeah, absolutely, that’s, that’s awesome news and that’s great to hear that progress and sounds like, you know, with that, with that kind of adoption. The future’s bright I’m glad you’re able to spend time working on WP Graph QL again know a lot of folks rely on that solution. Jason, thank you so much for joining us today.
JB: Yeah, absolutely.
DV: Awesome. If you’d like to learn more about what Jason is up to you can visit MVP Graph QL comm or check out the headless team he sits on a WP Engine at WP Engine comm Ford slash Atlas. Thanks everyone for listening to press this the WordPress community podcast on W Mr. Again, this has been your host, David Vogel poll, I support the WP Engine, sorry the WordPress community through my role at WP Engine and I love to bring the best of the community to you here every week.
