Author: Emily Schiola

Welcome to Press This, the WordPress community podcast from WMR. Each episode features guests from around the community and discussions of the largest issues facing WordPress developers. The following is a transcription of the original recording.

Powered by RedCircle

Doc Pop: You’re listening to Press This, a WordPress Community Podcast on WMR. Each week we spotlight members of the WordPress community. I’m your host, Doc Pop. I support the WordPress community through my role at WP Engine, and my contributions over on TorqueMag.Io where I get to do podcasts and draw cartoons and tutorial videos. Check that out.

You can subscribe to Press This on Red Circle, iTunes, Spotify, or you can download episodes directly at wmr.fm. 

On this episode of Press This, we’re talking about Headless WordPress, GraphQL, and Faust.js. How these tools can be used together and what sort of cost could be associated with Headless WordPress. We’re gonna kind of try to dive in deep with this, and I’ve got two great guests joining me today, I’ve got Jason Bahl, a principal software engineer at WP Engine based in Denver, Colorado, where he maintains WPGraphQL. And we’ve got Chris Weigman, an engineering manager working on Faust.js. I usually like to start these shows off asking guests about their WordPress origin stories, but I thought I’d switch things up a little bit here.

Jason, can you tell us what WPgraphQL is and what its wordPress Origin story. 

Jason Bahl: Oh yeah, WPGraphQL is a free open source WordPress plugin that brings a GraphQL API to your WordPress site and GraphQL is graph query language. So it allows developers to get content in and out of WordPress using the graph query language.  

And the plugin originated, I was working at a newspaper a few years ago and we were doing a lot of content syndication. We had a network of something like 54 sites and all across the US and we needed to move content from one side to another. You know, when a news story was published, different newspapers could subscribe to content from other newspapers.

And so when various events occurred, we needed to move data around this network and we were using the WordPress REST API to do a lot of that data movement. And were having some issues with that technically and like the actual performance technically, but also the developer experience. I found out about GraphQL, the actual graph query language, which was open sourced by Facebook in 2015.

So I found this technology, did some prototyping, pitched it to my colleagues and then we migrated our contact syndication from REST to GraphQL. And then I continued working on the project as a community project knowing that JavaScript frameworks were becoming the hot thing and that would probably be the primary use case of using GraphQL, like server to server communication isn’t the primary use case. It solved our needs, but I saw a bigger vision for it, so I kept working on it as an open source project for the community. 

DP: Well, cool. Chris, can you tell us a similar story about what is Faust and how did it come about?

Chris Weigman: Sure Faust is, recently as of really this week, officially released to the public, re-released to the public framework for building Headless WordPress sites using GraphQL. Well development started on it in 2020, and it was kind of an unofficial project of WP Engine, and this is the third major pivot.

They had started it as an extension of DevRel, kind of started making it a little more official with and pivoted into something called GQty and a very JavaScript, developer first mentality. And then when I took over the team in December 1st of last year, we realized that that wasn’t our target market.

We should have been developing for WordPress devs. So we started rebuilding it again, and that’s just finally been able to be re-released recently. 

DP: Jason you’d recently tweeted that you had launched the new wpgraphql.com on Faust.js. The previous site, I believe was headless WordPress. Can you just tell us about this change that you did and you know, what improvements you’re saying? 

JB: Yeah. So wpgraphql.com, it’s been a headless site for many years. So I’m using multiple data sources. So I have a lot of content in WordPress, like the blog posts are all in WordPress. 

Some of the documentation exists in WordPress as well. And then some documentation exists in markdown files in the GitHub repo. For the longest time I was using Gatsby, maybe for like three years, I was using Gatsby, which is a JavaScript framework that at its core has its data layer where you can pull in data from multiple sources.

So I was using that, it would pull data from GitHub, pull data from WordPress using WPGraphQL as well and allow me to use that data to build my templates. So I was using that for a few years. There’s a lot of pain points with the data layer that I wanted to kind of get out of.

So I wanted to use Next which is what Faust is built on. It’s another JavaScript framework, but there was a lot of missing pieces, I guess. Next, and a lot of these JavaScript frameworks have the idea that your front end frameworks should define all routing, right? But if you’re using a CMS, your CMS defines routing.

And so there’s a lot of technical issues of getting those things to play nice, where like your front end has an opinion on something and your back end has a different opinion. So like one of the problems I was trying to solve is getting my front end to recognize that a specific URL was a specific type of thing, and then render a template that represented that thing.

Like a blog post has a different template than a doc or a user archive or whatever. So I wanted my front end to have the ability to send a URL to the CMS, get data back, but understand what template to return. In WordPress its called template hierarchy. And so when the Faust team was able to get that problem solved, I was like, heck yeah, I’m moving over to Faust.

So, yeah, I’m able to take some of the concepts that exist in core WordPress, like PHP theming and use them in headless so I can use the benefits of React and whatever JavaScript I want to use on the front end to template my site, but still familiar concepts from the WordPress world. 

DP: Chris, you were mentioning that Faust kind of underwent some changes. What were those changes? You know, Jason was mentioning them. What were some of those changes that have made this improvement possible?

CW: It’s always focused on WPGraphQL. It was everything else that was really the issue. For instance, the last major version of Faust used a library underneath to interact with GraphQL called GQty, which on paper sounded really cool. The idea being from the Faust team at the time that, let’s just abstract, people shouldn’t need to know how to build these complex queries.

This framework should abstract that for you. On paper that looked really good, in practice because of all the complexities of WordPress data. Even a single post type can have so many variations. Maybe you’re mixing that with category, maybe all the different things. GQty just couldn’t power it through.

On top of that, when it was built with the GQty version, there was really no attention given to the routing problem that Jason spoke of. Who handles the routing? WordPress wants to handle its routing by what the content is, it’s a content management system, so all routing and WordPress is largely content based.

Next.js is a frontend framework, so all routing is based on, it’s a completely different paradigm for how the routing’s based. What could be /Blog on Next may have nothing to do with content for a blog. It’s going to a set of templates. It’s going to part of the application that can build a blog.

Whereas /Blog on WordPress could very well mean, these are all the blog posts. And that paradigm when building, if you wanna make WordPress a very solid frontend or headless capable CMS, we had to deal with that routing. Another shift when we made this, like I said with the GQty version, our goal was JavaScript developers who had to use WordPress, which seems noble until you realize this is WP Engine. 

We’re dealing with agencies who have built on WordPress for years, who now for various reasons that we can get into later, are moving into a headless thing. They know how to do WordPress development. They understand how WordPress template routings work and templates work, things like that.

We need to bring those features forward, so GraphQL can be more easily used by WordPress devs. And that’s what the goal of Faust here has been. The template hierarchy, just simply rebuilds what WordPress did. Now if you wanna use Next’s routing, there are ways to override it in the app so you’re not losing anything.

But for people who are using WordPresses as a true content management system, capable of routing content by content management, then Faust is gonna handle that much better for you? Does that make sense? 

DP: Yeah. Absolutely. You know, I think that’s a good spot to take a quick break here. You’re listening to Press This, a WordPress Community podcast with Chris Weigman and Jason Bahl. We’ll be back to talk about WordPress and headless. Stay tuned.

DP: We’re back with Press This. And you know, Chris, right before that break you mentioned something, you mentioned kind of more and more companies getting into headless, and I know that WP Engine has done a lot of research kind of showing that is the case. I am kind of wondering, headless definitely has a reputation as something, I think enterprise, when I think headless am I thinking correctly. Is that what headless is? Is it just a tool for enterprise or is this a tool that more sites are gonna be using? 

CW: Yes and no. Largely headless, especially with WordPress right now, the complexity involved in it means that you probably have a full team building out what you need.

This isn’t somebody just using WordPress out of the box, that you just want your personal blog. It can do that, but it’s a much heavier lift so far in order to be able to do that. Same with Contentful, same with all these other CMSs. If you just wanted something simple, something that, you know, the type of content that’s been on the web for years, headless is probably more work than you wanna deal with so far.

Is it strictly enterprise? Look, no. Gatsby’s been working on this problem for years. You’ve got another podcast later, Doc with Mastodon. It’s a community I’ve been involved with for a number of years. Most folks on that are using variations of headless CMSs, especially Gatsby, but there’s Hugo. There’s all kinds of different, that type of technology on a very grassroots level. 

So you wind up with the grassroots users and you wind up with enterprise users for heavy sites, whereas WordPress traditionally seems to fall with everybody else in between. It’s the person who doesn’t wanna deal with markdown files and code like a Gatsby user might, or you know, just Gatsby out of the box anyway.

But it’s also not somebody who has a whole team of 10 building their personal branding or personal blog. This takes WordPress out of that middle and expands it to both ends very easily. Now you can easily build between GraphQL, you have all the data and you have an ever-growing set of ways to handle that data.

And Faust makes it much easier to utilize that and something that you can build in a day instead of a month. 

DP: Jason, Chris mentioned something I’d like to hear your thoughts on, I hear that this is not maybe great for small teams, small bloggers like myself, which obviously makes sense, I don’t need a headless WordPress, but like, I guess what I’m wondering is, is headless WordPress going to cost me more because I’m gonna have to have an iOS dev and a WordPress dev? Is it more expensive or is it somehow more cost efficient? 

JB: Probably depends on what you’re producing, I guess. If you are doing, like you mentioned iOS, if you are doing a native mobile app, I mean there’s obviously be costs associated with that regardless, and there’s not really a good way to do it if you’re using data from WordPress, other than doing it headless, cause you know, a native app doesn’t render php, so you would have to do that headlessly.

But as far as like if you’re building for the web right now in traditional WordPress, you can go find a theme, you know either a free theme or find a theme on a marketplace, download it, install it, and you’re off to the races. Most people are going to customize it in some way or another.

So you’re gonna have developer cost usually, whether it’s yourself doing it or someone else. One of the things with headless WordPress that differs from traditional PHP theming, Is that for example when I launched the new wpgraphql.com, I was able to use the same instance of WordPress that was powering my Gatsby site.

I’m getting the data, the data was coming out and going into the Gatsby site, I was able to continue publishing content in the CMS while developing my next frontend for it at the same time. In traditional WordPress development, you have to usually migrate your site into like a staging environment.

Activate a new theme on that environment, build your theme over there, deal with some sort of like content freeze period where you tell your content creators, “Hey, today you can’t publish content cause we’re gonna migrate and then we’re gonna set the new WordPress instance, the live instance.” And then you have to log in over there and start doing your content right.

Headless WordPress, I was able to rebuild my site on a completely different frontend stack without disrupting anything in my actual WordPress instance, it’s a separation of data and presentation, right? So I could go, if I wanted to explore the next hot technology tomorrow, like I could put my sight on Svelte instead of Next, and I wouldn’t have to change a thing in WordPress.

So in some cases it can actually be cheaper because that whole process of spinning up another server, getting your team to stop writing content and then move into a different instance of WordPress, and then start publishing there, doing Delta migrations, things like that, that has a cost too.

Another thing that’s interesting too is the JavaScript ecosystem is really shipping. The common drive, in my opinion, one of the common motivators for moving headless is component based architectures. And there’s, all sorts of component libraries in the React and VUE ecosystem, which allow you to reuse components across projects.

And so agencies can build common components that they use in projects and they can update those in a central place, but then install them in multiple projects. With WordPress, that’s not quite as easy cause your PHP template parts and WordPress are usually very tightly coupled with the project they belong to.

Where with headless you can have an MPM package that has those components and multiple projects can update that package and benefit all at the same time with less effort. So I think at the moment, I would say probably is more costly and more work, but I think tools like Faust, that didn’t exist until recently are, are lowering the overall effort required to build headless.

And I think in the not too distant future, it might be cheaper to build headless than not headless. 

DP: Chris, did you have anything you wanted to add to what agencies might need to think about in terms of costs of headless WordPress? 

CW: I think Jason really hit the nail in the head.

And that’s one thing I like about WPGraphQL is my team’s working next on extending WordPress that direction with what we call, our working title is the React Gutenberg Bridge, but it’s a problem in WordPress too. How do you reuse these components? I don’t wanna use the word just component, because it doesn’t apply on the WordPress side in the same way that it applies on the JavaScript side, right?

But how do we reuse code across projects, headless or otherwise with WordPress and headless does enable that. But I think it’s safe to say that the average blogger just trying to get out their foodie blogs, probably not dealing with that themselves. That’s very much an agency problem. Is that more cost?

Maybe, maybe not, but that’s where it gets complicated when we talk about where’s the cost in this? Because it’s different types of how you want to use data. 

DP: Yeah, absolutely. You know, coming from a newspaper background, working on Weeklys in the Twin Cities and in Nashville, Jason, I can imagine what it would would’ve been like to tell your 56 newspapers not to publish for a day.

No news today, because we’re updating the site. 

JB: Yeah. And I mean, we did go through those periods, right? Like when I was hired there, they weren’t on WordPress and so part of my job was getting them from another system to WordPress. So there definitely were days when it was like, all right, it’s go live on WordPress day. Stop what you’re doing. Right. 

So there definitely were periods like that or we also had to deal with that issue of like, okay, they were publishing on the old system until midnight last night, but we had the WordPress ready to go two days before that. So now we gotta do like a Delta migration and make sure all the data’s still synced so that, you know, there’s definitely technical and human cost to those processes for sure. 

DP: Yeah. And I’m thinking there’s also a lot, when you’re still using WordPress, you still get that ecosystem that you can get this cost saving. You don’t have to build the SEO tools.

You can use Yoast SEO plugin or whatever. Even though you’re a Headless site, I’m assuming, most plugins will still work as long as they’re not front facing. 

JB: Yeah. That’s actually an interesting thing. So the new Faust is built with a plugin architecture itself. So like out of the box, it’s going to come with a client, it’s using Apollo client so that you can fetch data from WPGraphQL, you can get your WordPress data, but you can create plugins so that, let’s say you did, like you mentioned, install Yoast SEO on your WordPress site.

You can add a Yoast Plugin. It doesn’t exist yet, but it can soon. You could add a Yoast plugin for Faust on the frontend that knows what to do with that data, right? So there’ll be the ability for folks, some we might produce and support, but some, the community can produce and support plugins for the Faust side of things as well, so that you with just one line of code, add this plugin can get functionality such as Yoast for your headless front end. 

It’s something that I don’t think any other headless frontend really has the concept of in the same way that Faust is approaching it. So I think the plugin, I think it’s another thing that’s familiar for WordPress developers. It’s bringing familiar concepts from WordPress, but bridging it with the modern JavaScript frontend stack.

DP: that’s a, that’s a good spot for one final break here on Press This, and when we come back, we’ll wrap up our conversation with Chris Weigman and Jason Bahl. Stay tuned.

DP: You’re listening to Press This, a WordPress Community podcast. I’m your host, Doc Pop. Today we’re talking about WPGraphQL, Faust, and how you can power your headless WordPress site. Right before the break, we were talking about Faust and plugins and I’m just gonna throw some random questions at y’all and just kind of see if there’s any good answers here that come up. 

But Chris, I’m kind of wondering with, with Faust, is there any potential, I know it’s a headless platform, but is there any potential for like a WordPress Faust theme that just kind of at least gets you set up with like, here’s the plugins you need and here’s just kind of everything out the box.

CW: Absolutely. In fact, we already have it. We’re referring to it as Blueprints because it works so heavily with Local. Most people are gonna do some sort of tweaking on this stuff before launching it on a platform like WP Engine. So we borrowed Local’s name of Blueprints. 

For the new Faust we have one called Portfolio, which is basically a full portfolio theme and we’re working on just a very blank scaffold that agencies can use. Once you get the hang of things, you’re probably gonna wanna customize everything yourself. So a scaffold would be project best practices, spin that up, and then you can do all your own stuff with it. 

Long term we’ve talked very heavily about a headless theme store, ala Blueprints. We don’t have the manpower so that’s a little ways away, but it’s absolutely something we’re, we’re considering and we’d like to see happen. 

DP: Yeah that’s cool to think about. That’s a whole different kind of ecosystem to get into.

And you know, Jason, I’ve interviewed you before, and I’m sure this question comes up all the time, but every time I’m hearing about WPGraphQL, I’m thinking that sounds a lot like what REST API does. Actually, that sounds like a lot more powerful than what REST API does and REST API is part of core and I’m just kind of wondering, do you feel that WPGraphQL should be part of WordPress Core? 

JB: Maybe someday. I don’t think we’re there yet. When things get merged in WordPress Core, probably with the exception of Gutenberg, innovation halts. The REST API, for example, there’s still a bug that I point out to people that still exists from I think 2016. So I mean, when stuff goes into core, you’re adding a feature set to 40 ish percent of the web and so making changes has to be done at a much slower pace, where if it’s a plugin you can let folks opt into the version that they want to opt into and you can iterate much faster because they can choose what version works best for their project.

Where in core, if you update core and it includes breaking change, you might have just broke 40 percent of the web. So GraphQL is a specification, it has nothing to do with WordPress as well.

Right. And so the GraphQL specification is still evolving. And as that continues to evolve, we want to keep up with the latest and greatest of the GraphQL spec. If we were to merge, let’s say, WPGraphQL into Core today, and GraphQL keeps evolving, WordPress would be stuck at the 2022 edition of GraphQL where the rest of the world is on the 2030 version or whatever. To me, I think it might make sense at some point to have it recognized like WPCLI is as like the official way to do X thing.

Like you can go build your own CLI client for WordPress, but it’s kind of recognized by the community that WPCLI is the official thing. It’s not part of WordPress Core but it’s recognized by the WordPress Foundation and most of the WordPress community as the official thing. So it might be nice at some point for a WPGraphQL to be recognized like that is, like if you’re going to do headless WordPress, do it this way.

It’s still gonna remain a plugin. That’s my thought. There might be a time where the GraphQL feels perfect and it’s not really being iterated and maybe at that time we consider it. But at this time there’s things coming to the GraphQL spec that will cause the API to have breaking changes.

So doing it as a plugin to me makes sense still. 

DP: Right on. And yeah, you’ve mentioned WPCLI and I keep forgetting, like they just, they just feel like it’s part of core. Whatever it feels, it’s like official. So yeah, it’s like, oh yeah, that is like this independent thing, just like WPGraphQL is at the moment.

That’s a good analogy. So I’m gonna, I’m gonna wrap up here. It’s been really great chatting with both of y’all. If the listeners are interested in following either of you, you can follow @JasonBahl and @ChrisWeigman. We’ll put the Twitter handles in the show description if we can. You’ve been listening to Press This, a WordPress Community podcast on WMR. 

On next week’s episode, we’re gonna have Anne McCarthy, a product liaison at Automatic, talking about changes to site Editing and 6.1 and what’s coming up with 6.2. Thanks again for listening to Press This.

You can follow my adventures with Torque magazine over on Twitter @thetorquemag or you can go to torquemag.io where we contribute tutorials and videos and interviews like this every day. So check out torquemag.io or follow us on Twitter. You can subscribe to Press This on Red Circle, iTunes, Spotify, or you can download it directly at wmr.fm each week. I’m your host Doctor Popular I support the WordPress community through my role at WP Engine. And I love to spotlight members of the community each and every week on Press This.

The post Press This: WPGraphQL and Faust.js appeared first on Torque.