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.
- 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
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.
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.
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.
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.
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.
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.
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.
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.
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):
Matt Perry (53:53):
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):
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):