React Summit

React Summit 2022

Remixing WordPress: Building a Headless Site with Remix, WPGraphQL, and Web Fundamentals

What's up, React Summit? My name's Jeff Eberhardt, and I'm a Senior Developer Advocate at WP Engine. The title of my talk today is Remixing WordPress, where we're going to spend about 20 minutes building a headless site with Remix, WP GraphQL, and a few other open source plugins. But before we get started, maybe we could talk broadly about what headless WordPress is. With the rise in JAMstack architectures, we see a ton of SaaS offerings in the headless CMS space. But if you're looking for an open source alternative, a lot of people don't know that WordPress can also become a headless CMS. And with WordPress being the most popular content management system, which is powering roughly 40% of the web at the time of this recording, there are chances that your content teams are already well-versed in the WordPress platform, so there can be a lot of reasons to consider this as an option. So let's take a second and talk about what traditional WordPress gives us. Traditional WordPress is your basic monolithic software platform. The visitor maybe interacts with a CDN by typing in a URL into their browser bar, but ultimately all of those requests are served by WordPress core. And any of the developer experience that needs to happen, whether that's theming or plugin development happens directly with that WordPress core software, as do the publisher interactions. So when people are creating content, they're doing that as a part of the WordPress monolith. Now when we look at headless WordPress in comparison, that offers the developer a lot of flexibility. The experience for the visitor is still the same. They type this URL into a browser bar, but instead of their request being handled by WordPress core, it is actually handled by an application that we ultimately determine what that looks like. And so in the example today, we're going to use Remix as this Node.js runtime, but that could be any potential front-end framework, whether you're a fan of Nuxt or Next or you want to use SvelteKit. That is entirely up to you as the developer, and all of your effort is going to be into developing that platform. And all of that interacts with WordPress through either the REST or GraphQL APIs that we're going to explore today that are a part of WordPress core or added via plugins. But the ultimate benefit is that the experience for the publisher or the content creator doesn't change and they get to use WordPress sort of as is to create and publish content while we as the developers get to take the benefits happening in the front-end framework space and bring those to our users. So let's get started. We don't have a ton of time, so I'm going to hop right into building out our headless site. So the first thing that we'll need to do is create a new WordPress site. And I'm going to do that using the local development tools. I'll click create new site, give my site a name, select the preferred customization option, create an admin username and password, and then I'll let local install those services for me on my local machine. If you have a WordPress site already, feel free to use that as well and install the plugins there. Once that's done installing, we can open up the WP admin panel, log in, and then we'll need to install a few plugins. First we'll want to install the WP GraphQL plugin, which essentially turns our WordPress app into a WP or a GraphQL API. You can install and activate that plugin. And then we will also be installing a plugin called Atlas Content Modeler, which is a headless focused content modeling plugin that will allow us to create complex content types and make those available over GraphQL immediately. Now with our plugins installed, we can work on creating our first content model. To do that, we'll use Atlas Content Modeler to create a content model around projects. Do that by specifying a singular and plural name, determining the API visibility of our content model, whether it's public or private, choosing an icon for the post editing screen and creating a description for our users to see. When we click the create button, that will automatically generate the model and begin the process of adding it to our GraphQL API. With our model created, we can begin the process of adding fields to our model. We'll start with a text field that stores the name of the project. We'll use that as the entry title, make it required, and add it to our model. After that, we can add a date model that will store the due date for the project, make that required as well, and add a description for that model that will be displayed to our users. From there, we will add an additional text field to store the assignee's name for the project and this will be the DevRel Associate who is assigned to a particular piece of content. Make that required as well. And then we will add one last rich text field that will be the project description. So now that we've created our project content model, let's add some data. We'll open up the post editing screen and fill out all of the fields that we specified as we created the model. And then when we're done, we can publish that piece of content to make it available for use in our application. Now that we've seeded our project with some additional data, let's explore the features of WPGraphQL in the Graphical IDE. The query composer feature of the Graphical IDE allows us to visually explore our GraphQL schema and select individual content types and their nodes and properties, all while composing a GraphQL query that we can run dynamically and to return actual data from our WordPress site. So now that we understand the resources available to us in WordPress to model data and to serve that data over GraphQL, let's talk about how we're going to integrate Remix into that equation. So I've got a pretty basic Remix app set up right here with a few dependencies installed that we're going to need to communicate with our WordPress server. So one of those is the GraphQL package. I've also installed Apollo Client and I've done some styling with Tailwind CSS. So where we can get started is in our index.js route. We can look here, we can see that we're importing two different components. We've got just a basic header and a basic project component that's going to list our projects out in cards on this page. So what I'll do over here is in my terminal, just click npm run dev to get this dev server running. And then I can come back over here and we'll just refresh on localhost 3000 and see that this test data array where I've got some projects that we'll eventually swap out with data from our WordPress site is rendering right there for us. So the next thing that we'll want to do is configure Apollo Client to query our GraphQL endpoint from our WordPress site. To do that, we'll begin by creating an Apollo.js file in the lib folder. And then we'll add some import statements to import those needed resources from that package. And then what we'll do is create a default export that is going to be our client. And we'll set that equal to a new Apollo Client. Now we'll pass in some configuration parameters. And one of the ways we can get our GraphQL endpoint is to hop back into our WordPress site, open up the WP GraphQL settings page and copy and paste that into our project. And we'll also create a new in-memory cache that we can use to help speed up our application. And once we're done, we'll save those things out. So now that we've configured Apollo Client, I'm going to create a new file to contain my data fetching code. And really this part is entirely up to you about how you want to structure or where you want this code to live. So I'm going to create a file called WordPress service. In there I'm going to import the client that we configured in the last step. And then also the GQL object from Apollo Client. So then we'll create an export and export a function called get projects. And then from here, what we'll do is hop back into our WordPress WP GraphQL instance, copy the query that we were using, and then we'll create a new query, open up a new template literal with GQL and paste that query in there. Then what we'll do is create a new variable called response and we will essentially use the client to query and pass in that query to that configuration object. Then once we get that response back from Apollo Client, we will dig down into the object that we get back so that we return the individual project nodes. It's always helpful if you're unsure of how to traverse a particular object, you can always hop back into WP GraphQL and visually look at what the data looks like that you're going to get back from that API call. Okay, so now that we've got this function stepped out to make our GraphQL query, let's pause for a second and just take stock of where we're at. It's worth mentioning that although I've created this WordPress service file with these export functions, how you handle this organizing this data fetching code is really entirely up to you. I know lots of React developers in particular are fans of co-location, so having the code that does their data fetching also inside of their components, there are ways that you can achieve that as well by having some of this code happen in the individual route files. So this is just a choice that I've made because I like this organizational pattern, but that doesn't mean that you couldn't make another choice and Remix is unopinionated about this as well. As we transition into looking into how we use this function to load data into our route components, Remix is actually opinionated and we'll talk about some of those differences. Next we'll take a look at this index.jsx file in our routes folder. The Remix framework uses a file-based routing system, which is kind of similar to what you might get in Next.js or Nuxt if you're coming from the view world. So there's a decent amount of overlap in how this framework handles routing. And we'll look at some other more complex examples in just a little bit. But so if we open up our index.jsx file, we can see that we're importing some components in here and then we're exporting this index component that returns all of these jsx elements that are going to render our application. But right now we have all of our data hard-coded in this projects variable. And so the next step that we're going to want to tackle is loading our data dynamically from WordPress. So to achieve that, we'll just throw a couple more import statements up here. And I'm just going to copy those from off screen real quick. We're going to import two different things. So we're going to import our get projects function from this WordPress service file. And then we're going to also import this use loader data hook from Remix itself. So once we've done that, then we'll come down here and we're actually going to create another export. So this is going to be an async function named loader. And that is a Remix convention. And what's going to happen is when Remix goes to render your components, it's going to call whatever is inside of this loader function on the server. And it's going to go out to your service, whatever that may be, in our case, WordPress and GraphQL to get some data. And then we will be able to access the data that this loader function returns using the use loader data hook. So for us, all we need to do in this example is add a return statement, and then we're going to await the result of get projects. And so again, that's one of those reasons that I personally like to develop in this way. So I like having a service file with all of my different data calls out there so that my route components can be very clean. Alternatively, you could certainly do some of this inside of this loader function. That's totally up to you and how you want to handle it. And to be honest with you, I'm not sure Remix really cares either way. But so we've got this loader function, we're doing some amount of work in there, and that's up to us to determine what it is that we want to do. And then what we'll do down here is instead of hard coding this array, we can come and we can just use the use loader data hook. So we'll set projects equal to the result of this use loader data function. And so if we save that out and refresh our page over here, we can see that boom, that worked just as we expected. When this index route gets called, we go to render that component. This loader function calls get projects on the server. We return that data and then use that data via this hook to populate these project components down here. So fantastic. We've got our index page working the way that we want. But I think it might be time to pause for just a second and discuss this opinionated choice that the Remix framework makes. I've worked with a number of different Next.js projects and other React projects where some of the data loading that we're doing happens entirely on the client. And so if we're used to using the Apollo like use query hook, for example, and having those components make those calls out to our GraphQL server on the client, this is a bit of a paradigm shift if you will, right? Because each one of these loader functions is only getting called on the server. And I think the Remix team made that choice for a really good reason. And they've enumerated those reasons in a lot of videos, so I won't belabor them and I encourage you to go check out some of the Remix singles to get a good idea of those. But in some ways, it does help us as developers simplify the type of code that we're writing, right? If we look at a framework like Next.js, for example, where maybe we're doing static site generation and then some things are getting loaded on the client, it has a tendency to get a little bit messy, right? Because we have all these different abstractions for these different use cases. I think Remix sort of simplifies that. It says this is the one way that we're going to load data into components. And so it makes that a little bit easier. It also makes it a little bit easier to handle credentials, right? If I were making authenticated calls to a database, since all of this data fetching in the loader function is happening on the server, I don't have to worry about leaking my credentials into the client. So there are a couple of pluses to this that I definitely recommend you explore if you're new to Remix and kind of compare and contrast with whatever your framework of choice is at the time. So now that we've got our index page looking the way that we want, each one of these is actually a link to an individual project. But right now, if we click on it, we get a 404 error. So what we'll do in the next few minutes is just dig one layer deeper and look at how we would handle this dynamic routing example with the Remix framework and WordPress. Okay. So for our project to handle this dynamic route URL, we're going to need to make some changes to our routes folder. We can see that the URL that we're sending the application to is project slash the slug of the particular project. So inside of our routes folder, we will create a new folder called projects to match that part of the URL segment. And then inside of that projects folder, we're going to create a new file called $slug.jsx. And this is going to be the component that we export. So I'm just going to come over here real quick and copy this from off screen and paste that in just so we can take a look at it. And we'll go ahead and save that out. And then we'll sort of just talk through a couple of different things here. And we can see already in the terminal that we've got some work that we need to do. So let's hop back. I'm going to save this one more time. We'll hop back into our WordPress service and then get going from there. So we can see that our component is using this get project by slug function. So we'll hop back in there and we'll go ahead and we'll stub that out. And so this isn't going to return anything at the moment. Get project by slug. And then this is going to take the slug as a parameter. And so now that we've got this stubbed out, let's hop back into our WordPress instance. And this is where we'll use the graphical IDE to create our GraphQL query. So again, using the graphical IDE in the query composer, we can use those tools to help us visually create and format a new query to get our post by the slug. And if we open up the individual sort of project node inside of the query composer, we can use that and specify the type of ID that we want to look up the post by. So in this case, we'll use slug and we'll grab an ID from our WordPress site and pass that in. And then what we'll do is also add in all of the additional fields that we had on our previous query to make sure that all of the data is the same. We can just click those to add them to the query. And then once we're done, we can again, preview the result of that query by just running it in the IDE. And so once we have our GraphQL formatted the way we want and making sure that it's returning the data that we want, we can copy it and paste it back into our WordPress service file. We'll make a few changes inside of this GQL template literal to parameterize this query so that we can pass in the ID. Then after that, we'll actually make the query with our client object and pass that formatted query into it, as well as a variables property that takes an object where each property in that variables object, like ID, for example, corresponds to one of the variables that we parameterized in the tag template literal. Then we'll also just sort of traverse our response from GraphQL and return that to our loader function. And as always, if you're kind of confused and you need help figuring out what your data looks like, you can always use the GraphQL IDE to explore that. So it's worth talking really quickly about the loader function as it's implemented in the slug.jsx file. A lot of this should look very familiar to what we did in our index file, with the exception of this params object that is getting passed into the loader. This is how we access those dynamic URL components. So $slug becomes params.slug, and then we just pass it into our get project by slug function that we pull in from our WordPress service. And if we come over here and we refresh our page, you can see that everything is working as we expect. And now we have both an index page and dynamic URL segments that are looking up individual posts. Thank you so much for coming to my talk on Remix and Headless WordPress. If you're interested in learning more about the open source Headless CMS alternative and some of your favorite front end frameworks, be sure to follow me on Twitter or check out some of the content at developers.wpengine.com. Thanks. Thanks.


Jeff Everhart

GraphQL Galaxy

GraphQL Galaxy 2021

Exploring the WordPress Graph with Next.js & WPGraphQL

Colby Fayock

GraphQL Galaxy 2020

Using GraphQL on WordPress

Sid Chatterjee

JSNation Live

JSNation Live 2020

Building React frontends for WordPress

Hello, everyone. I am Pablo Postigo, co-founder and CEO of Frontity. I founded this company five years ago, and I had one obsession, make it easier to create modern user experiences with WordPress. So first, let me give you a bit of context about WordPress. WordPress is the most popular content management system in the web. It powers 30% of it. It is also one of the biggest open source communities out there with over 15,000 themes and more than 55,000 plugins. And it's also the platform of choice for marketers and content creators. But I guess that you will be asking yourselves, why is this guy talking about WordPress on a JavaScript conference, right? Well, it is because after years of working hand to hand with WordPress publishers and developers, we have found a way to combine WordPress in the front end and JavaScript in the front end. I mean, WordPress in the back end and JavaScript in the front end. So please let me explain to you how we can combine React and WordPress. There are three main points to keep in mind. The first one is the first reason is to create a great UI and user experience for the web visitor. At the same time, we want to maintain a great developer experience for the tech team in charge of creating and maintaining the website. And last but not least, we also have to keep in mind that we need to provide with a great content management experience for the team in charge of managing the content of the website. So how can we achieve this golden triangle using React and WordPress? It's easy. Since 2016, WordPress includes a REST API. This REST API opens a world of possibilities. And now we can use WordPress as a headless CMS. Using WordPress as a headless CMS means that we use WordPress only in the back end to manage the content and expose it using a REST API in a JSON format. With this REST API, any technical team can choose the technology they want for the front end. So for example, they can build the front end with a React application. Actually, this approach is not new to us. We've been working with this architecture since 2017 with some WordPress publishers came to us with one request. They wanted to improve the user experience of their mobile sites with one goal. They wanted to improve the user engagement of their websites. So in order to help them achieve this goal, we developed a product called Frontity Pro, which was a mobile theme with instant navigation and swipe. This mobile theme was programmed using React. Because with PHP and jQuery, it was really difficult to accomplish these features. This is Gudo, one of these big customers that wanted to use Frontity Pro. This is their website. You can navigate it yourself using your mobile phones. But please let me go and do a quick demo. So this is the website. It might look like a normal website. But as I said, it has some cool features, like the swipe between categories. It also has instant loading in the articles, and also has swipe between articles. Our goal was to provide a user experience that was as close as possible to a native mobile app, but on the mobile browser. And as you can see, this website performs just great. This website, this project was a success. And it achieved great results for this publisher. Gudo saw an increase in every KPI that they were measuring, including their page views, their organic traffic, the time spent in the website, and also an increase in the user acquisition. After helping dozens of publishers, we decided to release all of our technology and open source our project. And the result was Frontity Framework. Frontity is the easiest way to create lightning fast websites using WordPress and React. These are some of the key features of the framework. Frontity is really easy to use. It comes with a zero-situp architecture and a suite developer experience. Babel, Webpack, the routine, the state manager, everything is configured and works just out of the box. It is also an SEO-friendly framework. We have solved the server-side rendering of the app. It is also an extensible framework, which means that you can easily reuse parts of your code among different projects, and not only your own code, but also include themes and extensions created by the community. And as I said, we have been using this framework with Frontity Pro, helping dozens of publishers, and it's battle-tested. Frontity Pro has served millions of page views all around the world, and it's ready for production. Before I finish, I want to make a quick recap. We have built a solid bridge between two walls that were totally disconnected, WordPress and React. And we are really confident about the possibilities of this new combination. The WordPress ecosystem is already excited about starting using React in the front end. And we hope that the React community also embraces the possibility of using WordPress in the back end, as I said, to provide a great developer experience, a great user experience, and a great content management experience. If you're curious and you want to start looking and investigating Frontity, I invite you to take a look at our website, frontity.org. You can also take a look at our documentation, where we have a really easy step-by-step get started guide. And I also want to invite you to join our community, where you will be able to start a conversation with the Frontity creators, the community, people using the framework, and share all of your feedback. We will be happy also to keep the conversation on Twitter. So feel free to ping us there. And thank you very much for being here with us in the conference. Enjoy the rest of the talks. Thanks.


Pablo Postigo

React Summit Remote Edition

React Summit Remote Edition 2021

Scaling WordPress with Next.js

Hey everyone, we're going to talk about WordPress and how we can scale it with Next.js. So who am I? I'm Colby Fayok. I'm the one hugging BB8 and Kylo Ren over there. I work with the dev community as a developer advocate for Apple tools. You can find me pretty much anywhere on the web by just Googling my name as I'm the only one in the world. So let's start off by addressing the CMS in the room. It's 2021 and some developers would cringe at the thought of WordPress, but frankly, we're still living in a WordPress world. According to Build with Trends, if we look at the CMS distribution of the top 1 million sites, 40% of websites are using WordPress. I'm not quite sure how accurate this number is, but if you look at the number of detections on the built with site, it's over 800 million installs of WordPress. That's a staggering number. While we might not all want to use WordPress, it's realistically around to stay for the foreseeable future. So let's talk about how we can take advantage of the King CMS in a headless way and use it to power our static jam stack sites in 2021. So to start, what does headless actually mean? With our traditional stack, somebody visits a page in the browser. The browser reaches out to the server. The server will do all the work like request data from our database, where it then returns the HTML for the page and returns a response. And if we're lucky, it'll return that cache. Finally, the browser displays that response to the person visiting the site. With a headless approach, that request to the server is asynchronous on the client. In this particular example, the person would visit a page in the browser and immediately get a response straight from storage. Once that page loads in the browser, the browser will kick off another request to a server, which can load all the dynamic content. But I would imagine you'd be wondering, why would we want to make a client side request to a CMS like WordPress? And that's not necessarily the recommended approach. That's where static site generators come in to do the hard lifting before your page is the browser, which is what has given rise to what people now call the jam stack. Maybe you've heard of the jam stack on Twitter, or maybe it's completely new, but what exactly is it? At the core, jam stack sites are static HTML websites. This isn't a new idea, but it's a modern approach. Typically, they use JavaScript in the browser to make any request to your APIs that would provide dynamic data, or they can use those APIs at compile time and serve that dynamic content without an extra client side request. One example that we can imagine is building a React application. This would serve as our JavaScript layer. We would want to use the WordPress API to provide the content and the dynamic data. We would compile that down to a static site using Next.js or another tool, which along with a lot of other features is a static site generator. Now, if this is all new to you, it sounds like a lot of work. Why not just use WordPress out of the box like we always do? The great thing about jam stack sites is they have a lot of compelling features kind of built right in. By default, we're living up to what AWS considers a well architected infrastructure. These are features that we all care about, like performance, reliability, and cost. With most of the server based solutions like WordPress, there are a lot of options to help speed things up. For WordPress specifically, that includes plugins to cache or some custom work under the hood. But each page is still a server hit, which is prone to its ups and downs. On the other hand, serving a plain static HTML file is just going to be fast. Instead of spending time rendering on a server, you serve a static file straight from storage or a CDN. While you can do this with a default WordPress, it's often a lot more complicated. And some of the plugins that cache might serve an HTML file, but they still serve it from a regular server, not storage. With any server, we're typically paying for how much we expect our traffic to be. While most of the time that's predictable, we all hope that one day one of our posts will go viral. And if that happens, the people visiting our site will be the ones paying for it with slow speeds and timeouts. There are solutions like load balancing and auto scaling, but those aren't perfect solutions and might not always handle a certain traffic. Back to the fact that we're serving static HTML files, because we're serving files straight from storage or better yet, static files directly from a CDN, buzzword alert, that means our user-facing website is going to infinitely scale. That static site will survive the Reddit hug of death when your post goes viral. But managing servers isn't always cheap. While a low traffic personal blog can manage a few dollars a month, the more that traffic grows, the more that cost is going to quickly grow. While you have options again like load balancing and auto scaling, those services quickly add up and without it, you risk your site slowing down or worse, downtime. Storage is really, really cheap. We can maintain huge static projects on AWS using S3 for really low cost. But even if we still manage a server, that usage is going to be much, much lower with only content managers or requests at compile time. While there are a ton of headless solutions or options out there, it is a headless world where WordPress still has a lot of features that makes it compelling to use. One issue with a lot of the recent solutions is they seem to be very developer-focused. And that's not necessarily a bad thing, but you have to know your audience. If the ultimate goal is for the CMS to be used by people who are non-technical, you're providing an experience that people might struggle to learn and use. WordPress is the most used CMS in the industry. That means most of our clients are already going to be familiar with WordPress. There's a huge ecosystem already thriving around WordPress. If you run into an issue, you're more than likely able to find someone who already ran into that same issue with a simple Google search. We can also take advantage of a lot of community solutions that extend WordPress. All right. So if it's so great, let's actually see what this looks like. Since 4.7, WordPress by default now supports a REST API. This means right out of the box, WordPress is actually available as a headless API. But taking that a step further, thanks to Jason Ball, who created WPGraphQL, which is a plugin that we can add right inside of our WordPress dashboard, we have the ability to query our WordPress data with GraphQL. So coming full circle, we can take advantage of this approach where we leverage APIs at compile time to produce static websites. Rather than waiting for a server request, we'll have our entire WordPress site available as HTML documents. And I've done just that with Next.js, where I've created a Next.js WordPress starter, which lets anyone serve up a new static WordPress site with React framework Next.js super easily. I've set this up so that on our homepage, when we're compiling the site, we first reach out to get the first set of posts, kind of like we would commonly see on a blog site. Those are passed as props to the page that's built out in React, where then I can create the UI however I want. Because Next.js won't know the routes ahead of time with a dynamic route, we need to figure out all of those pages it needs to create. So we grab all of the posts, and then we create new paths for each one of those posts, telling Next.js to create a new page for each one. And with all that, and a little bit of glossing over, I was able to get together a WordPress site statically compiled with Next.js. The goal here wasn't to get you all to jump ship over to WordPress, but to show the flexibility of it and why it's still a compelling option along with all the others. We can come up with some pretty powerful solutions that provide a great user experience, while still also making it performant and cheap. If you want to check out my work, Next.js WordPress Starter is completely open source on my GitHub. And if you want to learn more about the JAMstack, you can check out my book at JAMstackhandbook.com. And that's it. If you want to learn more or chat about the talk, you can find me everywhere at Colby Fayok. My DMs are open. And I'll also tweet out a link with some of the stuff you've seen here today. Thanks everyone.


#wordpress