Demystifying Decoupled WordPress
You may have heard decoupled (or “headless”) architectures can make it simpler to deliver content across multiple channels and devices. However, this approach—where your CMS is completely separate from your front-end user experience—can also add unnecessary complexity, cost, and time to your content management.
How can you know whether a decoupled architecture is right for your business? Ultimately, the best choice depends on your goals, and this webinar is designed to help you make an informed decision.
Topics include:
- Why (or why not) to go decoupled
- Lessons learned from Accuweather’s experience going decoupled
- The most common types of decoupled architectures
- The relationship between React.js and WordPress
- Answers to your decoupled questions in a live Q&A
Transcript
Tess Needham (00:02):
Hi everyone. I’m Tess. So here at WordPress VIP, we’ve seen increasing interest in decouples or headless WordPress sites. But there’s been a lot of misinformation and misunderstanding out there about the benefits of the sort of more complex architecture that this involves. So, for today’s webinar, we’re bringing together some of WordPress VIP’s experts on the topic, along with one of our clients to talk about their experience.
Matt Perry, lead enterprise engineer at WordPress VIP. He’ll go over the pros and cons of decouples and how to know whether your use case is a good fit. Then we have Ryan Sholin, Director of Business Development and Partnerships at WordPress VIP. He’ll cover some of the new technologies and integrations in the WordPress ecosystem that you might consider with a decoupled setup. You’ll also hear from Rachael Trost, AccuWeather’s Product Manager of content about the headless architecture that enables their seamless content experience. We’ll have time for questions after the presentation. So if any questions come to you during the presentation, please just use the Q&A box here in Zoom to ask them. If we run out of time to answer all of the questions during the session, then we’ll follow up with you later. Matt, I’ll let you take it from here.
Matt Perry (01:19):
Thanks, Tess. And welcome everybody, good morning, where I am, or time appropriate greeting wherever you are. I’m going to quickly go through a few bits of background and then dive into talking about decoupled architectures and their pros and cons in a little bit more detail. As mentioned, I am an engineer and I help lead our enterprise team here at VIP.
So, let’s start by just taking a quick overview of the ecosystem surrounding enterprise WordPress in general. Obviously, at the core of any WordPress space app is the open source software WordPress, and this is deployed here at VIP in exactly the same form as you would download it just yourself from wordpress.org. On top of that, obviously we support our clients in building a huge variety of applications. This component defines the experience for your internal and external customers. It includes traditional forms such as themes and plugins, but also decoupled applications built in JavaScript, mobile apps, and all sorts of other stuff.
And then, just to complete the picture, along with the applications and core itself, we deploy a whole set of APIs and other tools to support your deployment here at VIP as would be the case in other environments as well. And then, we also support a huge variety of integrations with external systems, including off personalization, all of the other pieces that define the digital experience. So this is a picture of the overall ecosystem no matter what architecture you adopt.
Drilling in a little bit to just that top bit, let’s look at the pieces of WordPress and the apps that are built on top of WordPress. So we have as mentioned WordPress core. We have components that are specifically enabled by PHP APIs within WordPress core to extend WordPress and as I mentioned, these are the traditional forms of building on WordPress. Principally, PHP code plugins and themes.
Another key component of many WordPress applications is the REST API, which for those of you who don’t know, ships in WordPress core and is automatically on in WordPress when you just download it. This is the key component that enables you to build decoupled applications on top of WordPress. The goal of the REST API is parity with the PHP API. And then of course, there may be any number of external components that define applications on top of WordPress. These can be mobile, JavaScript, based front ends, which we’ll dive into here in a bit. And other stuff, including Internet of Things, display and other non-traditional front ends.
So a little bit about terminology. We use the words decoupled and headless quite a bit to define the subject we’re talking about today. And we’ve actually gone back internally and with our colleagues quite a bit about when it’s appropriate to use what word. But just real quick, when we say decoupled around here, we’re usually referring to the architecture that we’ll describe here in a moment where a JavaScript application is speaking through the REST API to WordPress. Headless is a word that we typically more apply to the CMS itself. So a headless CMS is a CMS that supports authoring and workflows, but doesn’t necessarily expose a front end.
So back to architectures. As I mentioned, there’s a whole spectrum here of architecture to discuss. We’re going to be talking specifically about fully decoupled JavaScript architectures. But let’s look at all of the variety of architectures that we sometimes see built on top of WordPress. These, of course, begin with the traditional architecture that, as I mentioned, leverages the WordPress theme API and provides a unified bundled execution in PHP. We also see this sort of middle ground where we see folks building heavily in JavaScript but within the theme architecture. So this might mean shipping a full page like experience in the context of a theme.
Moving into the more complex territory, we see of course, fully decoupled JavaScript architectures. So these, as I mentioned, are powered by the REST API, they’re written in React or in other framework typically, and they’re served by Node typically. And then we see just for completeness, a whole universe of other applications also built on top of WordPress.
So if you think of this as a spectrum, it’s a useful way of just visualizing the options that are out there and a spectrum of complexity. So visually, we can just zoom in on the two that we’ll really focus on today. That is the traditional WordPress architecture where the front end experience, the digital experience is bundled in the PHP execution stack with the rest of WordPress. And then the decoupled architecture on the right where you have the REST API linking JavaScript front end with WordPress.
I just quickly assembled a little bit of a table that compares some of the aspects of these architectures. We won’t spend a great deal of time on this but it’s useful to just see them sort of side by side. Some of the trade offs we’ll talk about here in a moment, start to reveal themselves on this table. And in particular, I’ll draw your attention to the difference between traditional and fully decoupled architectures in terms of some of these aspects. So, the big one is, for fully decoupled, you have two applications that require two stacks and two sets of hosting and support and often other considerations. And with the traditional architecture, it’s a single unified stack.
Having set the context there of the whole universe, let’s zoom in a little bid on decoupled architectures themselves and take some time to really talk about their ins and outs. I think often, this is first of all, a conversation that we have all the time with our clients and partners here at VIP. We’ve over the years helped many organizations make the decision about whether and how to embark on the adventure of building a decoupled front end for their WordPress deployment. So we’ve accumulated sort of a bunch of wisdom over the years about how this decision is made and some of the factors that go into it. So in this section, I’m going to just discuss briefly what our experience has been with some of those ideas and considerations and trade offs.
So we might start with what we’ve really experienced as strong reasons why you may indeed wish to build decoupled from it. We really see groups come to us with all sorts of perceived reasons. But these are the ones we’ve noticed over time really seem to be strong indicators you might want to go in this direction. So the first is portability. If you have a requirement that your front end be highly portable, for instance, if you want to swap out back ends potentially in the future or in parallel with your WordPress deployment, you want to support a different back end to your front end experience, different set of authors, different technology for building your data, then a decoupled architecture is a great choice. It allows you to invest in a front end and building customer experience and not be tied to a given CMS.
And that does have some appeal these days, especially in large organizations where a front end may be deployed in multiple contexts, or just indeed in this world where headless CMSs are more and more common.
The other strong indicator that you may wish to go decoupled is if your front end needs to integrate diverse data sources. There are a whole bunch of examples we could bring out of this. I think when Rachael speaks later from AccuWeather, she’ll be able to speak to this more. But the real indicator we’ve seen here is if WordPress is one of many data sources for your app, and probably not the primary source. So if your app uses content to decorate another source of data or the content is just one out of many data sources, then that is also an indication that you want to build from it.
The reason for this is pretty simple. WordPress can of course integrate external data sources, that’s not a problem. And we see people pulling external data into WordPress itself quite a bit in the traditional context. However, when the balance sort of tips over to the site of external data rather than content being at the center of the app, then that might be an indication that it’s wise to invest in a decoupled front end.
And then there’s another application which my colleague Ryan will speak of a little more later, where you may wish to deliver your site in a flattened form. In other words, you might wish to take a dynamic site when it’s generated by WordPress and use one of several JavaScript solutions to flatten the site and deliver it as flat files. If this is a requirement for you, then there are good solutions in the decoupled realm for that too.
So these three, this isn’t an exhaustive list, but these are three considerations that are usually pretty strong arguments for going decoupled. So next, there are a couple of reasons I want to cover that are possible indicators that you and your team might be a good candidate for a decoupled architecture. These can go either way depending on the circumstances. But they’re very common, and so I wanted to mention them and just discuss them briefly.
So one is you may have an existing JavaScript oriented team. You for whatever reason are in an organization that is pretty JavaScript Node React oriented, and you want to make sure you leverage that team to build great experiences for your customers. This is an entirely balanced, valid, excuse me, business reason, and we totally understand this. I think the calculation around whether it automatically means you should build decoupled is somewhat more complicated sometimes than we think. And we’ll discuss the ins and outs of why this might be an indicator or not later.
Similarly, just in general, we frequently hear a strong desire and a healthy desire from clients to simply build and invest in modern JavaScript. It’s the future of the web, it’s easier to hire developers often that are skilled in modern JavaScript. And there any number of other reasons why this is a business requirement for folks. The trade offs here are somewhat complex, but many of them boil down, and we’ll discuss this in a moment, to total cost of ownership. So, it’s important to look at what you’ll save by using an existing JavaScript oriented team or investing in this technology. What the benefits of that are versus the additional costs you’ll incur by maintaining the JavaScript front end over its lifetime. So we’ll discuss that in a moment.
But first, I wanted to take a brief detour and just mention a few possible less strong reasons that we sometimes hear folks wanting to go decoupled but often are not as strong as the other reasons I mentioned. And the first, let’s just go right to what I just mentioned, the total cost of ownership of the app. First of all, it’s easy to underestimate I think the cost you’re going to incur by owning a decoupled front end. We’ve seen already that these apps require two stacks, two sets of support folks, often two dev teams. And all of that cost over the lifecycle of the product can be significant.
The other area to think about is that if you’re building in React and Node, many of the solved problems, many of the simple features that are bundled with WordPress now in terms of editorial workflows, editors, and then front end features like integrations with delivery platforms, those are solved for you in WordPress, especially in a context like VIP. And many of those, you’ll need to figure out on your own in a decoupled front end. So this goes into the cost, of course, but it’s an area that we consistently see folks underestimate when they’re attempting to make this decision.
So, it’s good even to just make a list of what integrations and other requirements you’ll need to solve afresh in the front end context. And this can even just be fairly obvious stuff. One consistent issue is how do you preview content if you’re authoring in WordPress and you’ll deliver on a decoupled system? That’s a solvable problem but one that has to be tackled.
Interestingly, we do have teams come to us who want to go to decouple specifically to improve performance. And while I don’t want to say that there can never be a performance benefit to delivering with decoupled front ends, this is typically not a very good reason to go decoupled in and of itself. First of all, if you’re working with a platform like VIP, we’ve highly optimized our delivery of traditional WordPress for performance. And there are a number of complexities and new considerations that come up if you were to go decoupled. I’ll just quickly mention a couple of them. One is certainly the additional caching and fortifying the front end itself. And then you have the link between the front end and WordPress. So there are just a number of steps and complexities that all have to be optimized now when you’re going this route.
So, we’ve just quickly assembled a little tool to help you think about these and a couple of other issues. And so, I’ll show you this little quiz we made. These are some of the questions that we encourage you to perhaps start asking when you’re approaching this decision. So, this addresses many of the issues I’ve raised already, like front end portable. How do I feel about different aspects of cost of ownership of two systems? How sensitive am I to performance and other stuff? Answering yes to many of these questions may mean that you’re a great candidate for moving, and if you only can answer yes to a few, possibly less strong signal that you would want to consider a decoupled front end. This is not meant to be diagnostic or definitive, but it will get your team thinking in the right direction about many of these issues. I think we’ll have a copy of this that you can find on our website after this.
Okay, moving right along. When confronting this decision about whether and how to build decoupled front end, we like to make sure that teams have a full picture of the role of JavaScript in WordPress. So I’m just going to spend a very short period of time here before I hand off to Ryan discussing the current landscape of JavaScript and WordPress in general because I think this is a rapidly developing area, one that’s good to keep in mind when making this decision.
So, a little bit of history. JavaScript has always had a presence in WordPress, of course, in the PHP area from the beginning of the project, there is always WordPress and core, Vanilla WordPress and then jQuery. So that sort of is the little layer of JavaScript that you would find on top of WordPress core in the PHP era. JavaScript began expanding its footprint in WordPress core in the 2000s and 2010s. You had major components of core being written in frameworks, but they were isolated within core. This includes things like the media manager and the customizer. But the real revolution came in 2014 and 2015 when the REST API shipped in core. This powered a whole new universe of front end integrations and other integrations and really marked the beginning of the modern era of JavaScript in core.
And then just really about a year and a half ago, at the end of 2018 with WordPress 5, we had the true beginning of JavaScript frameworks in core. So, for those who don’t know, React ships with WordPress core now. It powers the editing experience in WordPress, and it represents sort of the direction of WordPress and JavaScript in the future.
As I say, the block editor, which is the core component of WordPress that is currently written in abstracted React is the home of modern JavaScript in WordPress now. And even just that revolution has opened up a whole universe of possibilities for JavaScript developers who wish to contribute to WordPress. It’s possible for React developers to build complex workflows and editorial experiences in WordPress. It’s possible for them to build themes and plugins. And that footprint is rapidly increasing.
So, whereas now the editor is the real center and home of modern JavaScript and WordPress, coming rapidly in the next year, that footprint will expand to other components of WordPress. So widgets, customizer menus are up in the immediate future, and they’ll be followed shortly by other components. So, the message to take away here is that while WordPress certainly traditionally lives in the PHP world, already, React developers are certainly first class contributors to building experiences it WordPress. So if you have a JavaScript team now, if you have an interest in modern JavaScript, it’s possible to not only build decoupled front ends, but to contribute directly to more traditional forms, even if you’re a React developer.
I wanted to mention here the idea of a block. So traditionally, we have extensions for WordPress in the form of themes, front end experiences and plugins pieces of functionality. A third first class object in WordPress is now the block, which is essentially a JavaScript component that defines some piece of content. And these are pieces of functionality in WordPress that can be built now by modern JavaScript developers. And their footprint, as I say, will only expand. One way this will happen is that sometime in the next year, just like there is a community ecosystem for themes and plugins, there’ll be a community ecosystem for blocks too. So this is just kind of a sign of the new prominence of modern JavaScript.
And going a little even further, just to give you a sense of how this new paradigm will work, core right now, and this is just a visual of the ticket involved, is building full site editing and other more pervasive presences for JavaScript in WordPress. So you can expect this landscape to expand rapidly and there to be more and more opportunities for modern JavaScript teams to contribute to WordPress themes and plugins.
So, I guess the main takeaway of this section, by all means, consider building a decoupled front end but don’t limit your thinking in terms of how to deploy modern JavaScript and WordPress to just that paradigm. There are plenty of other opportunities for your JavaScript teams to contribute now to your editorial tools and to other experiences with WordPress.
So with that, I’m going to hand it off to Ryan Sholin, who is going to spend some time talking about, a little bit more about decoupled WordPress landscape and some of the tools that are emerging to help us with that work. Ryan?
Ryan Sholin (23:47):
Sure, thanks, Matt. So a lot of what Matt has discussed has to do with how you take your WordPress back end and translate from the REST API through to a decoupled front end. So what I wanted to talk through is a few existing solutions to do that sort of thing. And for a couple of other bells and whistles in terms of presenting flat files or other kinds of decoupled connections to your back end site.
So, one of the questions actually that came up in the Q&A is when you’re querying the REST API, you might be asking for everything that’s available for a certain post or page or taxonomy or any kind of JSON payload that the API can deliver. There are ways to slice and dice that so that you’re not making a huge call every time getting more data than you might be displaying in your front end. GraphQL is a query language that’s built to be able to really kind of chop up the API responses to get just what you need on the front end. There’s a great WordPress wrapper for this WPGraphQL. That’s been developed in part by some VIP clients and partners over the years. These days, there are a lot of people contributing to it. And it’s definitely something that’s worth checking out.
When we see folks going decoupled, they’re often using a solution like GraphQL to make sure that they’re really kind of making their calls a little bit more lightweight, and just getting the data that they’re going to use in the front end, which can definitely improve performance.
On the front end, one of the tools that we see being used for WordPress and other platforms too, have a framework that takes that GraphQL response and provides you with React templates that start making sense without having to sort of reinvent the wheel from the ground up, is Gatsby. Gatsby is increasingly popular, some of the same people who are working on WPGraphQL are working on Gatsby as well. And it’s just a Good thing to check out if you’re looking for how you can build that decoupled front end in a modern JavaScript framework like React without having to sort of learn from the ground up every last way to make a call. There’s a couple of other ways to do this that I’m going to talk about as well.
These are WordPress specific solutions that we’re seeing emerge. So when I say don’t reinvent the wheel, there are some really great ideas out there that are being productized now that are worth following and checking out. These are a couple that we’re following pretty closely. Frontity is interesting because it takes the idea we’ve just been discussing of making GraphQL requests and of having a React front end that is, you don’t have to write from scratch, but then takes that and applies it very directly to WordPress, so that you can have, instead of having to say I’m going to write my query to say what is gets involved in a post and what should be there and what an article page should look like or a homepage, Frontity has done a lot of that work for you so it could be a good base to build from. We’re actively talking with them and trying to follow their development pretty closely.
Strattic is a little bit different. They are turning, as we talked about a little, turning your WordPress pages into static sites. So this is sort of a shortcut to say, if you’ve got a site that doesn’t have to be terribly dynamic, you can cache everything at the edge, a static site generator, possibly tools for smaller sites, for landing pages, for marketing sites, this is one option as well. So Strattic is turning a WordPress site really kind of in a push button way to static pages, and then hosting those in their CDN.
So, I think that we’ve got Rachael available now from AccuWeather. We also have some good questions in the chat that we can continue answering there as well.
Rachael Trost (28:06):
Cool. Sounds good. Hi, everyone. My name is Rachael Trost and I’m a product manager of content for AccuWeather, which basically means that I oversee our content products. So, our WordPress CMS environments, any kind of content integrations on accuweather.com, our apps, or any kind of local media partnerships. So, my main bread and butter is our WordPress environment. I’m going to walk you guys through why we’ve gone with a decoupled structure and just some of the lessons we’ve learned along the way.
So, quick overview of just what is AccuWeather. Like to kind of give a heads up on kind of what we are as a company as it kind of lends itself into why we went with a decoupled WordPress structure. So, AccuWeather is mainly recognized as the most accurate source of weather forecasts and warnings in the world. More than a billion and a half people use our services daily, which sounds like a very large number. We were founded in 1962 and we are based in State College, Pennsylvania with offices around the world. So we deal with tons and tons of data. Weather forecasts from hundreds of thousands of locations across the world. We handle enterprise solutions for businesses. We deal with a lot of different APIs, we have lots of local media partnerships, lots of forecasting. And then in my world, we do a lot of news coverage, video coverage, podcast coverage, things like that.
I like to say that the weather needs an editor and that’s one way we kind of look to differentiate ourselves in the weather area, is that we provide that kind of context visual coverage for our users.
The one project we worked through very big last year, which is getting us into why we’re using decoupled is a project called Project Glacier. In July of 2019, we launched a new responsive websites. We kind of came to the times and decided we needed a responsive website. With that, we decided to move to a new CMS system, which was WordPress. We had been working on several different CMS systems through the years. So we had been decoupled for a while, but one reason we’ve moved to WordPress for instance is the simple integration for decoupled that WordPress offers. We work with a couple CMSs like I said, and the integration for WordPress for decoupled so far has been the smoothest for us, which is awesome.
As I mentioned earlier, we have more than a billion and a half people using our sites and services a day, which kind of adds up to 50 billion plus data calls. So this is everything from the temperature, wind gust, the probability of rain in a certain area as well as radar mapping, things like that. Most of our bread and butter is not content. We are a Weather company. But still with that amount of users and that amount of people on our site and our products, we do still make 750 million plus calls to WordPress daily. So things like alerts that live in our WordPress environments, articles, videos integration, photos, images, things like that, which can be a really large group of calls for WordPress environment.
So why did we go headless? As I said, content is just one piece of what we are here at AccuWeather. Big plus for us was that we could set up our decoupled structure, and then we could make changes on the front end as we need to. We don’t need to go through, and I’m sure Matt and Ryan touched on this earlier, and there are presentations, we don’t have to rebuild everything in WordPress, just if we’re changing some stuff on the front end. So it does allow for us as we’re kind of in this rapid period of change at AccuWeather when it comes to our products, to allow for that flexibility. As we kind of know our content strategy, we know how we want to do things moving forward on that end. It does allow for us to make those changes on the front end without having to fully rebuild things in the CMS.
It also makes our content applicable to kind of other applications. We are going through a new project now regarding our apps, different kind of OTT offerings. And having the ability to look to WordPress for those pieces so far has made those projects a lot simpler. We can lean on our already existing endpoints to serve content in the way we want to and other applications without having to rebuild anything in that aspect. And then one other note I didn’t put on the slide is that we’re serving hundreds of thousands of pages on our site to different locations across the world. As for us, being able to present the different endpoints and having teams look to those versus having to serve those pages through WordPress has been good for our use case. We do have content on the vast majority of our website’s pages, but it’s not the very, very basic piece of what we do. So having kind of endpoints we can stand up, adjust as needed, has just been good for us from an efficiency perspective of our site.
Main things we’re using to kind of utilize our decoupled structure is just extending the REST API. So, it’s been helpful for us, one, as we transition to WordPress. We migrated over from a CMS called Brightspot. As we made that migration last year, we transitioned over 130,000 I think article types into WordPress. So, utilizing that API for the content migration was great. We’ve also continued to expand the API. We use a service called JW Player to house our video content and expanding the API to service that process has been beneficial for us. We also expose a lot of new endpoints. So for instance, right now, I mentioned we are working through some new stuff regarding our app to be able to expose different endpoints, so that use case has been the best for us in terms of utilizing our WordPress decoupled instance.
I just want to talk through a couple product tips. I’m a product manager. So some of the technical stuff gets over my head and I rely on our awesome CMS developers. But from the product perspective, things that have helped us with this decoupled setup, I found it very helpful for myself to work very closely with our front end development team. I would say it can be a challenge sometimes if I would like to change something on the design or the look or the placement of content modules on the front end of the site. For instance, if we do have breaking news, if I want to move a module up, I can’t just do that in CMS, I can’t just rely on my CMS developers to do that. I do need to rely on our front end team to handle.
So, working really closely with our front end PM has been beneficial for me. We check in very, very often. We make sure as we’re kind of doing large projects we sync very closely to make sure that one, we have a clear requirements side, and then two, our development teams have a clear communication going word of what do we need to do in WordPress? What endpoints are we hitting? What functionality do we need to build there so that they can take it on from there and continue the development on the front end of the site.
We’re also focused a lot on flexibility. So, we’re working through some stuff for the tropical hurricane season right now, and making sure we’re thinking of, what are we building now that one can be utilized for this purpose but then for other purposes as well. I think it’s a good tip for life in general, focus on flexibility. But we just want to make sure as we’re building stuff in the CMS, we can present things to the front end as flexible as possible so that changes can be made later on as needed.
And then we view our CMS, instead of it being WordPress serving our website, we definitely view it as a management for all of our content. Like I said, we use WordPress to serve content on our apps, we use it to send stuff to local media partners, we use it to create different experiences for OTT platforms. So, having all that content in one place and having a system for sending it to all different areas has made it easier for us to kind of, one, adjust strategy on the content side for what should we be servicing where, and having that flexibility, and then two, not having to have multiple different areas for those teams to look at in different documentation, confusion having it in one WordPress has been a big win for us at AccuWeather.
Cool, and that’s it.
Matt Perry (36:31):
Thank you, Rachael. Sorry about that. A little mic malfunction. I think that’s a really awesome use case, and thanks for sharing all those details. And it just sort of for me underlines a really great use case in a number of ways for decouples. So we saw some common themes that we see across our clients there, variety of data sources including content but maybe not always centered on content and the need for extensibility and flexibility and powering the number of apps. So, thanks so much for sharing that.
We wanted to maybe just wrap up here and then we have time for questions after. With just a few core things that if you were to leave this time together today, what should you take out with you. So, we have a few very loose and directional recommendations for folks when they’re beginning to think about the ins and outs of building decoupled front ends. So I’ll go through some of those quickly and then we can get to your questions.
So, if there’s anything to take away, it’s that the decision to go decoupled or with another architecture can be complex. There are a number of questions and considerations involved. So we encourage everyone to ask why in some detail they’re considering going in this direction. So you may choose to use the quiz tool we surfaced earlier or another method to get to all of the factors that are affecting your decision including team considerations, technology considerations and the nature of your project. So it is a significant inquiry and we recommend you take the time it deserves to make.
And the reason is really this other thing that I mentioned earlier, the total cost of ownership. If you think of what you’re building here, you’re going to build a JavaScript app that is potentially going to live for years, will go through a whole product lifecycle, will need to be maintained, hosted, and otherwise cared for for a significant amount of time. So, it’s an investment that we help folks all the time to assess in terms of its size and its total cost over the lifespan of the software.
It’s also good when you’re doing this to look ahead in a variety of ways. Look ahead not only to the future of your own app, but also in terms of where WordPress itself is going. We saw earlier the expanding footprint of React and JavaScript and WordPress core itself. The changing paradigms of how themes and JavaScript behaviors are built into WordPress directly and can be used to extend WordPress. So, maybe look ahead a year or two at the probable state of WordPress. And we’re happy to have those kind of conversations with folks, by the way. We love talking about the open source project itself in addition to what you can build on top of it. And really think deeply about how you want to be deploying your JavaScript assets, not just now, but say in a year or two from now.
And overall, we just encourage you to embrace JavaScript and WordPress no matter which direction you go. There are rich and increasing contributions that can be made by JavaScript developers and React developers in WordPress in the traditional context and in terms of building decoupled front ends. So, if your existing WordPress team doesn’t know JavaScript deeply, we encourage you to start that process. That’s a process that all of us here at Automatic and across the WordPress world had been going through in the last few years is to really embrace JavaScript as a core technology to WordPress.
So I think we’ll leave it at that for now. And Tess and Ryan, I think we have questions, right?
Ryan Sholin (40:17):
Sure, absolutely. Folks, if you have more questions, please do drop them into the Q&A. I’m going to read out and point out a couple of them here. We’ve been answering some along the way, but one that I think we should touch on is the questions about the new Gutenberg editor. Of course, the new block editor and WordPress has a lot of sort of what you see is what you get type functionality. And so, it’s been interesting to see some developers work with Gutenberg and decoupled. So Matt, really the question there is, is this counterintuitive to say use the new block editor and you can use that in a decoupled state? How are those working well together?
Matt Perry (40:59):
Yeah, it’s a good question and one we get quite a bit. And I’d be curious to hear what Rachael’s experience has been with this too. In general, like the block editor is the new editor for WordPress, so it powers the editorial experience within WordPress and is really a platform for building complex editorial experiences. So, in that regard, it’s a great tool no matter what architecture you adopt. I think there are few considerations when you’re deploying a front end or a decoupled architecture and also building blocks at the same time. They’re certainly meant to correspond to front end display in a particular way in a traditional architecture. So just really thinking deeply about how the blocks you’re building will interact with your endpoints I think is important. But overall, without going into a ton of detail right now, we certainly support clients who are using both and investing in both. Rachael, what would you add to that, or Ryan?
Rachael Trost (42:07):
I would say our [inaudible 00:42:08] team really does love using our different Gutenberg blocks. For them, it’s been an easier workflow than past CMSs we’ve been using. And for us, it’s just been kind of like I touched on, very clear communication to our front end team of, this is this type of block and making sure as we’re developing new block types, it’s clear to that of how to display it and what kind of thing it is when they’re getting it. So we don’t release anything new until we’re working really closely with them on how it’s going to display on the front end. But from our editorial team’s perspective, I mean, it’s been really helpful for them to figure out how to lay out their stories and how to bring in different elements in their own editorial process.
Ryan Sholin (42:49):
I would just add, for folks, if you look back at a webinar we did a couple of months ago with a Big Bite from the UK, one of our agency partners, they will show you some impressive Gutenberg blocks they built bringing in data from different sources that then are actually going to a decoupled front end. So the power that its offering their editorial users and the power that their decoupled front end is giving them are separate but equal in that respect.
One of the other questions that has kind of floated to the top of the list from Mike [Rantaya 00:43:19], and I’m going to read this one and make sure that we understand it, when operating in the traditional WordPress setup, does it make sense to still use the REST API or is it better to stick to admin-ajax?
Matt Perry (43:34):
Oh, right. That’s a good question. So admin-ajax is the, I guess what I would classify as pre REST API method for making ajax calls in WordPress. It’s still supported. As I think many people know, WordPress is extremely famous for its backwards compatibility. So, admin-ajax is very unlikely to disappear or otherwise be deprecated anytime soon. It still works fine just like many other legacy components of WordPress. It’s not really going anywhere. I guess as a developer, there’s nothing particularly wrong at this point with still leveraging admin-ajax. That said, the REST API, one of the specific goals there is to achieve parity or near parity with the PHP API. So, anything you try to do with admin-ajax, you probably can do with the right kind of REST API endpoint.
And indeed, we see many teams developing patterns around building for WordPress that demands certain types of coverages. So that often the CMS team when they’re building a new feature, will implement the future in PHP. And then just as a matter of their own practice, produce an endpoint that surfaces that same functionality just for completeness. So, it’s a good question. I think either way works. I think the modern trend is towards more comprehensive use of the REST API and building for a future where you may wish to surface really any part of your application in a JavaScript context or a decoupled context.
Ryan Sholin (45:20):
One other follow up to a question that we answered earlier, Nikolai asked about the REST API and making too many calls. One of our answers for that was using something like GraphQL. The follow up question is, can you cache API responses with varnish or something similar? How do we cache the REST API?
Matt Perry (45:41):
Sure. The answer to that is yes. On our platform, on VIP for instance, REST API responses are cached. And that’s one of the primary mechanisms we use for scaling REST API endpoints. In general, they tend to be super performant and cacheable. Like any other resource, you’d want to go through the process of determining whether they can be safely cached and for how long and all that kind of stuff, but definitely cacheable. And that’s really a primary scaling mechanism we use. If you think of some of the use cases, we have folks powering mobile apps, for instance that are making thousands and thousands of REST API requests per minute. And that can easily scale with the right caching solution like varnish. Rachael, you guys are a pretty good example of that, right?
Rachael Trost (46:33):
Yeah, we are. And different endpoints will be cached at different instances. So for instance, our landing page endpoints can cache about five minutes right now. Previously before implementing that, we did see our website timed out after a certain amount of time. So we would see instances where it wouldn’t respond in time given the number of calls that were being made and how often content was updating and things like that. So we found a sweet spot at that timing. Other endpoints will update more frequently like our article endpoint since those aren’t being hit as large number. Definitely our landing page endpoint, I think that we’ve spent a lot more time thinking through how we need to cache that and making sure it was working as efficiently since that’s one that both our website, and then different kind of applications will be looking towards.
Matt Perry (47:18):
[inaudible 00:47:18] just mentioned that if you are a VIP customer, the solution will vary depending on your architecture and environment. But in our case, we provide an API for controlling the cache and setting all of its parameters and that sort of stuff. But really, any full page caching or reverse proxy that you’re using to cache webpages can be leveraged for the REST API too.
Ryan Sholin (47:41):
One of the other questions that I’ve seen, which I think we’ve got a really funny answer to is about managing brand consistency and accessibility and frameworks that exist outside WordPress. That’s from Deborah Bacon. The way that I’m going to frame that question, no pun intended, is to sort of ask and answer. If you’re using WordPress as your back end, the decoupled front end, as Matt talked about a little bit, yes, there’s a web page, but there also could be lots of different ways to consume the REST API and to consume the data from your WordPress back end. So we’re seeing folks use digital signage. And obviously, native apps on smartphones, and a variety of other sorts of applications to consume the data from WordPress.
So in terms of brand consistency, accessibility, their style guides, they’re often implementing those on a variety of platforms and frameworks consuming the same data. I’m not sure if that’s 100% aligned to your question but I think it’s just a point that we want to make sure we get out there.
There have been a couple of good questions about the REST API and security in terms of should we disable access to the API on sites that we don’t need it on or how do we authenticate REST API calls? Can we IP whitelist sort of access to the REST API? That’s certainly something that we’ve seen clients approach in a variety of ways.
Matt Perry (49:27):
Yeah, all good questions when you’re considering this architecture since that’s a core component of it. The question of whether to disable the REST API for sites that don’t need it, we get a lot, I think it’s, typically will just depend on your requirements in that department. The overall view is that nothing should, by default, nothing is accessible through the REST API in a WordPress site that is not generally also available on just the web front end of the site. The one exception we sometimes work with folks on are the author endpoints. Like if you would rather not expose all of your author data in a convenient form you can, and we’re just talking about the names of the authors that appear that author your content. But that is an endpoint that some folks disable.
It’s quite easy to disable parts or the entire, parts of the REST API or the whole REST API. That’s literally like a line or two in PHP so it’s possible. But there’s usually not a super strong reason to do that unless you have particular security requirements because almost all of the, or really all of the unauthenticated data that is accessible through the API is stuff you’re going to expose on the front of the website anyway, and could easily be scraped. Does that sound right, Rachael? What do you guys do in that department?
Rachael Trost (50:55):
We’re pretty much in the same situation as you. The data we’re presenting and the REST API is going to our website in some form or some other area, which is why we’re presenting it in the API in the first place. So the front end or our app or anything to pick it up. So we haven’t had as much concern there. I think for us, that’s one reason partially why, decoupled as well, since it’s easy to present those, that information we actually would like out there. And then keep our other information like weather data, things like that in a different system.
Matt Perry (51:25):
Cool. Yeah. And in terms of authentication, there are definitely, I mean, there’s two flavors of API endpoint and WordPress and unauthenticated and authenticated. And there are several methods of authentication. So, as you’re building for the API, that’s certainly a consideration and part of deciding how to deploy this architecture. Rachael, how do you guys use authentication with endpoints?
Rachael Trost (51:51):
I don’t think we use it too much in all honesty, it hasn’t been something that’s been a huge concern for us at least. Like I said, a lot of the stuff we’re using in our endpoints, we are wanting to be seen and sent out there to the front end and want to be able to be hit. So for us, it hasn’t been an issue. Since a lot of our stuff’s editorial content that we want the world to see, so we want it to be sent out to the front end.
Matt Perry (52:18):
Great. There’s a whole universe of possibilities for authenticated front ends, typically, those are front ends that are going to display restricted data in some way or endpoints that cause data to be updated or created. So, for instance, people have built entire authoring environments on top of the REST API that are not the typical WordPress back end, stuff like that.
Rachael Trost (52:41):
And it’s definitely something we’re thinking through now, though, as we’re kind of going more towards different subscription questions and things like that of what do we want to make sure we’re not just throwing out there as we’re kind of working through, what our [inaudible 00:52:54], look does like AccuWeather professional look like and that editorial content we want to serve on those that we may not want out there. So, it is something we’re thinking through, it’s just currently we’re not doing too much with it.
Ryan Sholin (53:07):
There have been a couple of questions just in general about WordPress and backwards compatibility. I think we’ve touched on this a little bit. WordPress isn’t going away from PHP anytime soon. But Matt, do you want to elaborate a little on the Learn JavaScript Deeply? recommendation from Matt Mullenweg, cofounder of WordPress. That was from a few years ago. Now, really, Gutenberg is very much built with React inside and all over it. Are there specific ways that we recommend to people that they build their JavaScript knowledge to be able to build Gutenberg blocks and to be able to build these decoupled front ends?
Matt Perry (53:53):
Sure. It’s been a transformation for many of us. It’s sort of proceeded at different speeds depending on the developer. I’m a web developer from way back, I learned certainly in the PHP world and that’s where I come from. So it’s been a really fun adventure to really take up JavaScript seriously. I think like many web developers, I could always play around with JavaScript. I knew jQuery pretty well and some Vanilla JavaScript. But learning these frameworks properly has been a pretty cool process. It’s looked a little bit different for everyone. For me, it’s just been a little bit of self-training, going back and learning React really from the beginning.
There are a couple of really great members of the community and companies that have sprung up around this space where they’re training folks for and retraining developers for work in React. Shoot, I’m going to get this name wrong, but there’s a fella named Zack. Do you know who I’m talking Ryan and Rachael?
Ryan Sholin (55:01):
Sure. I do.
Matt Perry (55:08):
There are a whole bunch of resources online available for free and at a cost to take you through the process of starting as a PHP developer really expanding into the space. Specifically actually for WordPress and how to develop for the editor. So that is an area that we’ve seen a lot of movement in. I think right now, as I said, the real value there for your teams is going to be delivering features for the editor and display elements for your themes. But that universe of stuff that you can do in WordPress with React is expanding super rapidly right now, and I think it’s worth looking a year or two down the line to really get an idea of what you’ll be able to do with that shortly.
Ryan Sholin (55:54):
And that’s Zac Gordon. Zac, and it’s with one C. We’ve had had him in to do some training before for clients partners, especially in the original rollout of Gutenberg. He’s been great. You can find video training and more on his site, javascriptforwp.com.
Matt Perry (56:16):
That’s the one. Yup. I think there are others now as well but Zac really pioneered that whole and took up that mission to retrain many of us in this way.
Tess Needham (56:30):
Thank you so much, Matt, Rachael, Ryan. Unfortunately, we’re out of time, we still have a lot of questions that we didn’t answer. So, we will definitely reach out to people to answer those. We’ll sort of huddle internally to see what the best way is of answering them. But I really thank you all for your engagement, everybody who joined us. At WordPress VIP, we help large organizations power these modern content rich digital customer experiences like the decoupled architecture that we’ve talked about today. So, after you leave, you’ll see a link to a quick survey. So we’d love your feedback about the webinar today. Thank you so much for joining us and take care.
Rachael Trost (57:11):
Thanks, guys.