Going headless with Next.js and WPGraphQL

Hello, everyone, welcome to yet another Buddy webinar. Today we are going to dive into the world of headless WordPress. And together with Fran Agulto, we will try to create a kind of simple WordPress index js application together with a bit of Graph QL. So friend, because you are much more of an expert when it comes to headless and everything, tell us a few words about yourself.

Yeah, absolutely Maciek. I'm super stoked to be here. And my kind of battle cry if you will, is I'm jam stoked to be here Extra extra excited. Thank you Maciek for having me. So a little bit about myself just to know where your information is coming from. I'm a dev rel advocate at WP Engine focused on headless WordPress. I started my career actually, in tech at WP engine on the sales side of things. And I was telling Maciek offline when we first met, I was like, you know, the inner nerd hit me. And during COVID, one of the one one of the few things I mean, there's mostly negative with COVID. But one of the positive things is, when we work from home, I had so much time to learn. And I was like, You know what? I saw a demo that our old Developer Relations Manager Matt landers did on headless WordPress. And I'm like, You know what? I Maciek. I said to myself, I need to learn that I enrolled in a JavaScript bootcamp focus on react in the mean stack. And the rest is history. Now I'm here two and a half years later and still breaking React code. So

yes, and now, we are we are here. So this is I mean, yeah, this is one of the great things about COVID we had more time to learn really cool and amazing things. So they're one of the few things we can say that COVID was cool about. And I am Maciek Palmowski and I work here at Buddy as a WordPress ambassador. So Oh, and good news. We have Mwale with us. And he's saying hi to us. Oh, hi, Mwale. So today, we'll learn about how to decouple WordPress and what does it means what is this headless WordPress, we will learn how to create the simple next JS app using WordPress Graph QL. And of course, next, and in the end, we'll try to deploy everything using Buddy en and Netlify account. Also, if you like what we are doing, remember to press the subscribe button on YouTube. You will always get informed about all the upcoming webinars. And also you will have a chance to watch a lot of interesting stuff that we have on our channel. And the last thing if you have any questions regarding headless WordPress, don't hesitate to ask them in the comment section either on YouTube or LinkedIn or wherever you are watching this. Okay, so I think everything I've remembered about everything, yes. So we can start talking about headless WordPress.

What is "headless" So let's start with the basic question. What does it mean? What does it mean headless?

Yeah, that's a that's a good start to the webinars to ask that basic question. So headless WordPress essentially, in a few words, Maciek is the decoupled approach A lot of cutting off the front end presentation layer that PHP usually handles in a monolithic sense, with traditional WordPress, and allowing a front end JavaScript framework within the node ecosystem to handle the front end UI layer. And then making WordPress basically just a database with an endpoint that you're going to consume that data out of. So essentially, that's, that's, that's what it is. It's cutting the hence the word headless. It's not because the you know, Sleepy Hollow and Headless Horseman story that we we knew when we were kids during Halloween. No, it's, it's not that, although it kind of relates to that when people think oh, Fran, what is headless WordPress? Is it? Does it have to do with a headless horseman? No, you're literally cutting off the head of WordPress, and making it having having the JavaScript front end do the work on the front end UI. So so that's what that's what it is. Now, the first thing I wanted to like just tell you Maciek unless did you have like another question real quick? Or can I dive right in?

Quick question, why? Why should we decouple WordPress?

Ah, yes, that's actually a next. That's a great question. So why should you decouple WordPress? Well, there's actually, there's three main reasons that you would, okay, when you sit down as a developer, and this is something that, you know, you and I being in tech Maciek, especially web development, at the end of the day. Typically, if you work for an agency, or you're a mom and pop that has your own business that relies on your digital property, aka, your website, or your web application, in order to generate money at the bottom line, you're going to have to make a decision on like a now that it's available, headless, or traditional. Now, here's the whys. Okay? If you're if if you want an uptick of perceived performance and actual performance, as far as the jam stack is concerned, because I throw that word out there. And I will for those that aren't familiar, because there might be some kind of super new beginners to the crowd of headless WordPress, jam, stack Sanford JavaScript API and markup. And essentially, that methodology means that at build time, meaning not at runtime, because traditional WordPress is server side rendered, right, it's dynamic. So when you hit that URL, every request is going to go back to the server, PHP runs, everything creates the files, and all the things that you requested, or that template sends back into HTML form. And then there Wallah, you can read it on the browser. In the decoupled approach, in this sense, from a performance uptake wise, you're not only cutting the front end off that JavaScript framework, you're going to pre build or pre render everything, meaning you're going to build everything before a user requested. Okay. And then you're going to throw it on a CDN, which means static files, which then in turn means Quick Access. When you hit that endpoint, literally, there is no going back to a server, all the files are right there already. So that's, that's one thing Maciek is that like, literally, the performance uptick is can be quite noticeable, perceived by the user, and also within the tech stack. So that's number one. Number two, from a security perspective, when you decouple your WordPress site, the surface area of attack for hackers, is very small. That's number one. Number two, because your back end is hidden, and this is with any decoupled approach it you could have a Shopify back end, you could have a Drupal back end, you could have a MongoDB, back end, whatever Contentful, you get the idea. It's hidden, it's hidden, so they won't even know you're using WordPress in this case. So the surface area of attack is more secure. And then there's only so much nefariousness you could really do in a browser. And then the third and last thing, and for me, Maciek, I think this is the most important because yes, you could you could aggressively aggressively cache pages in traditional WordPress, speed, all that stuff, right? Depending on how dynamic the site is, yada, yada yada. However, from a future proof perspective, I truly believe and this is why I joined the dev rel team here focused on headless WordPress. The future of the web as far as web technology is concerned is decoupled movement. It's, it's cutting the front end layer off and Having third and backend party services with all that data on your back end, consumed by endpoints so that you could essentially future proof your front end UI, right? That way thing. When users are trying to access your application or website through different nodes, a kiosk, a phone, it's much easier. It's much easier to grab any front end library or framework and whatnot and manipulate that data from your back end API into what the you want your users to see. So those are the three main things that I think a business or an agency would decouple. Now, Maciek, let me just add something on the flip side. On the flip side, why wouldn't you? Overkill? Because I'm telling you, you know, traditional WordPress is just fine for small medium businesses that

don't have that many users like, or my sister who has a therapy practice in California, she uses traditional WordPress, she does not want to touch code. And WordPress is excellent for that. She can just download a bunch of plugins, manipulate her front end, and not even ask a developer to do anything. You know what I mean?

Yeah, this is a great thing that about WordPress, that it can be really almost no code or low code. And the moment we are trying to go headless, we require this one extra layer of work, we have to prepare this front end. And there was a thing because, together with friend, we had that dry run, which turned into quite an interesting discussion. And we also discussed that the headless is a really great solution when it comes to the moment when you are, for example, let's say a React developer, you don't want to learn PHP. So in this moment, why learn PHP, it's easier just to grab, for example, Gatsby, or sure shopping or something similar. And using your knowledge that you already have. Just grab the data from WordPress, mix it together. And yeah, you will have a working website without the need of learning new technology, which is sometimes especially right now very important, because we don't have too much time and learning new tech takes time. So

yes, 100% agreed Maciek, it does take a lot of time. And that's the thing too, from a financial perspective, the decision going headless, you have to account for money, because to your to your point Maciek, you're going to have to hire if you don't know React code, say you're not even savvy too much on JavaScript, you're gonna have to hire a React JavaScript, you're gonna have to hire a developer team. And that costs money unless you want to learn it. yourself. Now, again, there's trade offs to everything. That's why like, I truly believe that like, there's always going to be the room for both monolithic and headless WordPress. And I think that's the beauty that you have a choice in web web development, especially, especially with WordPress.

Hmm, yeah, that's, that's true. So I think it's time to show how to convert how to decouple WordPress, right?

Yeah, let's let's let's do it Maciek. Let's talk through this. So the first thing that you have to consider when you're decoupling WordPress is the API layer. Right? Because as mentioned, when you go the jam stack approach, the decoupled approach API driven development, whatever you want to call it, it's just that it's your API endpoint that you're going to consume this data off of. And luckily, there's two ways you can do this in WordPress. I'm going to use Graph QL. And don't worry, everybody in the webinar throughout this whole webinar that I'm going through, in our developers.wp engine.com website, we have a whole tutorial that I'm playing off of, as well as rest vs Graph QL, and all these things. So if you want to dive deeper in and whatnot, I'll work with Maciek to like, send some links, a post webinar. But anyway, there's two, two ways you can do this. You can use the REST API, which some of you that are already developing in traditional WordPress already used because it ships with WordPress Core. And with the REST API, you use the HTTP verbs or I like to call them verbs but methods like get create, read, update, delete, to grab up that data off it. And then I always pull up this handbook here, from wordpress.org to so I have a reference of like all the endpoints that I have, so that I can grab that data from posts, categories, tags, etc. Now, here's the difference. And there's trade offs which we won't go deep dive because this is not a rest versus Graph QL. webinar, but major difference between will actually the two major difference I want to address Maciek is the way you grab data. So first of all, as I mentioned, HTTP method, REST API, Graph QL queries and mutations. Because what Graph QL is, at its core is a query language. And when you have a Graph QL layer on whatever database data data schema you're using, it exposes it as a Graph QL schema this way? How it's, it's interesting, because one of the benefits of it is that Graph QL itself kind of makes each API is kind of different, right? Whether you're using a Shopify API, WordPress Core REST API, whatever back end, you might be, it's hard as a developer, because you're like, Oh, great. Now I have to like expose that schema and see how the API endpoints are all laid out and everything with Graph QL it uniforms it and turns everything into a Graph QL schema. And most, I'll show you real quick most Graph QL instals. Now, within a database, have this graphical IDE editor, where you have a query composer, and this is that my WordPress schema here, exposed in a Graph QL scheme. So that's the beauty of Graph QL, it kind of unsniff flakes, each API because of API to me, it's like a snowflake Maciek, it's all different, unique, and Graph QL, we'll just, um, snowflake that and now you were like kind of used to this graphical IDE. And then the other thing I wanted to point out is that I showed you guys can reference that in wordpress.org, all begin points within WordPress that you have access to and rest. But in Graph QL it is just one endpoint. And within that endpoint, in rest, you're you you're at the mercy of what's in the API, you can't declare exactly what you want. But as I mentioned here, in Graph QL, in this case, again, queries and mutations I'm clearing and asking my Graph QL server, which is on top of WordPress, now, hey, Graph QL. From my WordPress data schema, I want all the posts. And within those posts, those posts have nodes. And those nodes have fields of title, your eye, I'm pulling out the date the content, you can pull out other things. But for the webinars sake, we're just going to run this press play against the Graph QL server.

And there you go. I asked exactly for this data, and in this form, and it's giving it back to me in this forum. JSON. So simple as that. That's how we decouple WordPress with Graph QL. Now, skipping one thing in the plugins, and I gotta give a shout out Maciek, I know you know what, I'm gonna shout out to one of my favourite people in the decoupled movement in WordPress. Mr. Jason

Fried Pizza. Yeah.

In fact, I, I think I'm doing an injustice to Jason. Because I should have had like an Arab fried pizza for lunch here, but anyway, brought to you by air fried pizza and Jason ball. So WP graph. QL is an open source plugin created by Jason ball who works at WP Engine and he's one of my favourite people in the world. But essentially, all you do is download this plugin. And then it turns your WordPress instal, like I said, into a graph, QL server, and then all of a sudden, you have a Graph QL option in the menu on the left side of WordPress Core. And then you have your graphical ID. So that's it. That's all you have to do to decouple WordPress.

Now, Maciek, we're ready to talk about the front end. In this case, we're going to use next JS for our front end framework. And then for some helper functionality to grab the data. On the front end, we're going to use the Apollo client and its Graph QL library. So let's jump over to my Visual Studio code here. And I have some things already pre made for the sake of time here. And again, don't worry, we have an step by step tutorial on the website that I'll link over after the webinar is over. So the first thing I want to talk about is next Js itself, right? Because it last time I checked, which was like last week, and I always see Lee Robinson, who's the head of Developer Relations at verse cell. Next, Js is made by Marcel. And it's the most, it's the most popular, most used downloaded framework in this ecosystem, and there's a reason for that. And for me, developers are full of opinions, and whether you agree with them or not, that's just how they are Maciek, you know that you've been doing this longer. You know what I'm saying, Man, so I'm going to share with you guys my opinion about why I think next Js is so popular. So the first thing is the developer experience and the productivity of the developer flow that allows you to get into off the bat as a developer, okay? Because the first thing is how its structured, boilerplate wise, when you spin up and pull, it's an NPM package out of the box. So if I jump into my terminal right now, which I did before this, and then put the utility command in there, MPX create next app, it's going to pull out all the dependencies and the packages and all that. And this is basically a next Js boilerplate, I've made some things, but I'm gonna go over what it spins up out of the box here. The first thing I think is super sweet is the page based routing that it does out of the box, because as a web developer, especially on websites, next to us is actually built architecturally already for you for pages and routes. And as a web developer, you're like, oh, great, sweet, my friend. And my framework that I'm using already does that for me. So in this pages directory, all you do is in this case, the index.js comes out of the box with it, that's the homepage, when you hit the just the forward slash, that's, that's the default homepage route. But I can drop in this page, and it relates to the file. The route is related to the file name. So if I put like about.js Maciek in this, and then render a, create a React component, a default component and render some JSX, like, Hello World, or whatever. If I go to my browser, and then visit that path, slash about, it's right there for you. So that's one of the things that I think is pretty sweet. And then obviously, this is built on top of React. So it uses React component style library. And then the second thing that I think is super sweet about next, Js, and I'll get down into this, once I start talking about the files and how to create a headless WordPress site here

is the rendering patterns that next Js allows you to have as a developer at a page level, right? Because I mentioned at the beginning that like going decoupled and JAMstack in your site is the approach of hey, as much as we can, at build time, before user even is available to request and hit that URL at build time. Let's build everything. Let's build everything. Let's make it static. Let's throw it on the CDN. faster access. Some people in countries that maybe the internet's not so good static file, they can access it. Okay, great. However, with pre pre pre rendering, if you will, pre building there's a trade off long build times. Because if your site is ginormous, and you're building everything from scratch, every time you make a change that gets that that's a trade off, you're gonna you're gonna have long build times when the

new page will make it longer and

longer and longer, longer and longer. Yes, Maciek. Exactly. Exactly. It's like rebuilding your house every dang time you make a anyway.

Yeah, just I decided to clean the window. Let's let's change Let's rebuild the fundamentals to build the concrete. And this extra annoying when you have, for example, a new site that has news from like 10 years backwards, and you just published a new post and if you would pre build everything he has all the news from those 10 years back will be rebuilt. So this is a trade of, as you mentioned,

100% a trade off. Now here's how next Js kind of alleviates that as, as well, on a per page basis. You have the optionality to either statically generate, or pre build, if you will, each page. Or you could go back to and again, Maciek and I were joking around, because if you're on a Twitter space, in web development, and other social media platforms, there's this joke going around that like web development is like fashion. In the 70s, bell bottoms were in disco, you know what I'm saying? Guess what Maciek bell bottoms are making a comeback, retro. And then like server side rendering, could be making a comeback. But in next Js, you can choose per page to server side render instead of statically. Generating so that your entire site's not pre pre building, if you will. And then there's a hybrid pattern of like incremental static regeneration, where you can set a time interval where the paid, say a certain page is changes quite a bit, but you not enough to like, Hey, I'm going to statically pre build this page first. But in next few years, I can set a revalidate cache interval, where it's going to check my back end and this in this case, Wordpress, say you set it every 30 minutes, whatever the time interval is, is going to check to see if there was any changes within the data. And then it's going to invalidate that on a timed interval. So the first user that hits it will get the stale data, then that triggers it to go okay, yeah. And then now we're going to show on upon every subsequent request the new data so. So that's what I think is sweet. Okay. So I think now we are ready to get into the nitty gritty, and just go over how, how I did this thing. So let's, let's do it. So. So the first step in creating a headless WordPress site is, as I said, we're connecting, we're going to use the Apollo client. And you can download the package, I've already installed the Apollo client dependency, and its Graph QL client, so we can use this data fetching library. So we need to hook Apollo client to WordPress. So the first thing that we have to do is use environment variables. And how we're going to do this is we're going to create a dot e NV dot local file, which I already have right here in the root of my project. And when within this environment file, you're going to have a key, which you can name whatever you want. In this case, I named it next public WordPress API URL. And then you simply put your value in your WordPress API URL exactly what the key is asking you for. So that's the first thing so then what happens now is that within next Js, by default, it's going to look for the dot E and V dot local file in the root of this project, to load any environment, variable files within a dot process dot EMV object, which I'll show you in a second how that's created. So. So that's step one. The next step is the Apollo client. So we have to now that we've downloaded the dependency of the Apollo client, we just have to create that instance of Apollo. So let's see how I did this here in this file. So what I did is I jumped into the root of my directory, I created a folder called library or lib for short. And within this library, I have an apollo.js file.

And then let's see what the configuration says. So the first line up at the top, on line one, I'm importing the Apollo client, and it's in memory cache from the package. Okay, and then below, I'm creating a new instance right here of the Apollo client, and I'm just calling the variable client. And then within this, we have a config object with two properties Maciek is a URI property, that's going to point our environment variable to that graphQL endpoint, because that's where Apollo is gonna say, hey, Fran, and Maciek, where where's your WordPress? Data? Where do you want me to grab it? It's right here. So that's What I was talking about with the process dot ENV object that next Js will look for, as far as from the Apollo side is concerned. And then one of the reasons to use a client side library to help is having in memory cache on Apollo, which is one of the main reasons people and web developers use Apollo client so that when you make a query, a graph, QL query, and a same one is made it caches and stores in Apollo's memory that way, there's some performance upticks there. Okay, so that's it within a couple of six, what is it, four or five lines of code here, we've configured an Apollo instance, and we've connected WordPress, to our next js application. Now, we need to access this and then get grabbed that data dynamically from WordPress within our pages. So let's let's do it. Okay, so the next thing you have to do is within the pages directory in order to make your Apollo client and its provider accessed throughout the root of the next js, application, and all its components, and its pages, is next Js ships out of the box, I just call it a wrapper, it's the underscore app.js file. And within this file is where all the page props within the page components are accessible. Within next Js, and in here, as you can see, I'm importing the Apollo provider from its library client, and then its react instance. And then I'm taking our client that we just made from our library, Apollo folder here, and then I'm wrapping it around the Apollo provider component, and passing in the client as a property so that now Wallah, we now have access to our Apollo provider across our entire next js application. And Okay, step two is done. Now, here's the fun part, y'all. And I, and this is this is, this is where I get really excited. So the first thing we're going to do is we're going to talk about how making the homepage in and don't worry, I'm talking about code I know is abstract, you know that to Maciek, but I'll hit the browser once or twice just to show you what's going on and seeing that sweet JSX and HTML. But the first thing we need to do in our homepage, because this is what I actually want to do here is I want a list of titles on the homepage. And then within that whole, within those titles, I want a clickable link so that the user can click on that post title and go, Ah, I want to be taken to the details of this. This this post, give me the post Details page. Okay, so the first thing we're going to do on the homepage, and it's funny, because I think of this, a basketball analogy. I know I'll most a lot of developers maybe have like little quarks on how they think of things. But for me, this is how I think of this, like so it's like when you're doing a basketball shot, like you're like taking the basketball from from down here. And then you're shooting it so that the ball goes up and into the basket. And in this case, my hand is my functions. And then the the the ball is data, and the ball is jumping into the hoop to give the data into the JSX and HTML corny I know, but it's how I remember things. So it starts off with the first function here that you guys can see on the screen Maciek you can see clear yes, right here. I'm

like yes, yes, of course I've ever think is visible.

Okay. Perfecto. So the first thing that I mentioned at the top is that with next Js, you have the option of essentially statically generating all your pages pre rendering pre building, within next. Js, the function name to do this is export is going to be an asynchronous function, get static props. Okay, that tells next Js. In this case, it's, it's, I'm telling it, hey, for the index page, I want this to be statically generated every time and that's okay. Because the data here won't change much. Plus our query is stagnant. It's not dynamic. There's no variable. It's the same query that you can that we made, actually from the graph, QL IDE and WordPress. So that's the next step that I wanted to talk about is that within our asynchronous get static props function, we're going to Create a variable I just named it get post, which is going to equal our Graph QL. Client. And that's when you would go back. And remember our query here. Y'all remember that? Yep. We're gonna go back, we're going to take that query, and essentially, paste this within a template literal backticks, into this variable here of getting the post. So that we're telling next Js, within this function. Next, Js, this is my graph, QL query. And this is exactly what I want to grab. Now, after that, we're going to have to make a call with a client and passing the query string to the config object right here. Because like I said, I called it get post. And then here's the query property here. And we're just grabbing that, then we have to traverse that data to pull out the data we want into the homepage. So here's the other variable of posts, and then the response is going to be data post notes. You're probably asking Fran, how do you memorise there? How do you know that I don't memorise these things? Are you? Are you kidding me? Coding is hard enough, developers always look at Doc's. And go, do you know what I'm saying? So just so that I remember, Oh, how does it return? Again, I go back to my graphical IDE. And there, there it is how it comes back within the graph, QL schema of WordPress data, post notes. And that's how you manipulate the response and get back, get it back. And then you have a return object, of course, with a props property, and then you're returning all the post data. Okay, we're set with our function, this is grabbing our data. Now we have to, we have to shoot that data up into an export default function, that's going to act as our page component. Okay. And this is where it's going to return the JSX, which will show the HTML on the page. So in this case, right here, within this function Maciek, putting within the object parameter post, because that's the data that we want accessible within this function. And then I'm just returning some H, HTML with some JSX. Right here mapping through dynamically mapping through all the post data, and then returning a single post. And then within this return statement, you're gonna notice something you all here. And this is one of the cool things of React development is component reusability. So I created a postcard component, because remember, I told you all that the idea here and you'll see in a second, because I'm going to spin up the browser is we want a clickable link with the post title, right? Well, you know, we want to make that pretty and reusable, because we might have another page that might need like a postcard, and whatnot. So in I built it, I made a components folder with a postcard.js file. And within this, just an export default function with the postcard and then we've got the posts. Within the parameter object, we got the post data in here. And then we're pulling back the essentially we're just grabbing the post dot title within using next link. And that's another sweet thing about next Js, it has the link component with client side transitions for linking between pages out of the box. So that's cool. So let's see how that looks on the browser, shall we? So if I just

run my development server, and it kind of always defaults to localhost 3000 Let's visit the browser here. And there it is. And before I actually, here's the postcard component, and then here is this is the dynamic data that we're grabbing right here. This isn't from the next Js front end, these titles are coming from here. Okay, so the next thing we're going to want to do is when I click this link, I want a dynamic route page to route me to the actual detail of and I know everybody's dying Maciek to know what my top five movies of all time are. Like. I know already you may know already and you had some disagreements and that's okay. But um, lastly, we need and then I'm super excited for the next step because I want to see how we're going to deploy this to Buddy, Buddy. But lastly, what we need to do like I said, is homepage, not dynamic, right? It's always the same query and whatnot. But we need a dynamic route. Okay? So every time a user next is doesn't know, when they click on the link, what that user is going to click, and what route and path to access and what content detail that posts relate to index js, the naming convention, you all to create a dynamic route file is the bracket syntax. So in this case, I have I made I created a dynamic route file, and the parameter within this dynamic route, you could do URI, I do slug, it's just the easiest, just this the slug of each post. But I'm just like that, this tells next, Js, hey, this is this relative dynamic. So we're not, we're not, we are not super sure what the user is going to access here, slug wise, but it will be a parameter of slug. And then when they click on that detailed page, to that slug, we're going to give them back to the post detail content. So let's, let's see how that's done. You're going to notice a little bit of similarity here, y'all.

Because, again, you guys saw this on the index page, right? Get static props, we want to essentially, jam stack this thing and grab the data pre rendering from WordPress, and then pump it into our HTML JSX. Up on our default function. Now, here's the thing, right? Notice a couple of differences. Remember, I said this is a post detail page, we don't want all posts, we don't want that. That's what we're grabbing on the index file index.js file on the homepage, we're grabbing all the posts, because that's never going to change, we just want all the titles. This is the detail page. So if you notice the query changed a little bit, y'all, and you can paste this into graphical ID, and it'll come back. But notice here is that it's singular. And then to parameter a ties, if you will, this query so that it knows, hey, this query is, is his variety, it's a variable, okay? Like it's not static, like the index file, friends asking for actual details to a post with the ID type, which is the slug. And the database ID meaning that, hey, this is this, this is a, these are the things that are going to be changing within this query within this graph, QL query. So that tells next, Js, hey, yeah, within Graph QL, this query is a variable, and it's going to relate within this parameter. Within the object here, you pass in the params, which is the slug. And it's going to say, Hey, these are the, it's going to look back into WordPress and go, Hey, this user is asking for a friend's top five movies. That's the variable that he's asking for. So let's give him that data back. Okay. So that's, that's, that's the major difference is this. This query has variables, the index page did not. So now this is very similar. But again, we have to account for the variables. So we have a response variable where we await the client, then we have a property of query and then same thing get post. But again, accounting for the variable, which in this case, the parameter is the slug, that's what's going to be a variety, it's going to be a variable, it's going to change, okay. And then down here, we traverse that with data post. And then we return the property of the single post this time, not posts, posts, that's the major difference between the dynamic page and then the homepage. And then, the last thing I wanted to go over before I show you everything and then pass the realms over to Maciek is that if you notice, we have a new function down here. This is get static paths. Now within next Js, the in a dynamic route file, when you're going to make get static prompts. You have to pair up with get static paths. Because next Js pre will generate a static version of your page when it starts serving the app. So what happens is, because these paths are dynamic, and they're multiple, you have to let next Js know, hey, within this dynamic route, there's different paths right? Excuse me that we're going to have to account for two, otherwise, it's not going to work, we need the paths and their props. So this is the function that pre generates or pre builds the static paths. Here's the caveat. And this is going to be solved in the future, maybe Maciek you and I can do another webinar indicator when Jason ball releases WP Graph QL smartcash. But here's the thing that here's the issue right now. If you're getting into headless WordPress, and using dynamic route files, index js, sometimes, we didn't get stuck in static paths, you can make another query of grabbing all the paths and pre building them. Okay. Which is fine. Because obviously, it's it's pre built JAMstack snappier, faster. caveat to that. When it when you have a large site, like maybe Android authority, who's on WP Engine using headless? Or if you're if you'd like sports, I don't know, ESPN, okay.

Those have those are big, large, huge sites with multiple pages and paths. Imagine, every time you have a dynamic route file, you're going to tell next, yes, oh, build every single path that's going to pin your WordPress ever, how many ever times that you have, as far as like, those pages are concerned, that's not good. You're going to timeout your WordPress server exhausted and it's kind of like your DDoS attacking yourself. And it's going to timeout the WordPress server and then you're gonna get a 504 and a JSON error. You don't want that. So and again, this is only for large sites. But for best practice, you can essentially do two things right here. The first thing is, as you can see, in this get static path function, I'm returning here, I'm I crossed out the slash about path, but I'm returning an empty array. Okay. And then I return just the past and fall back blocking. This is telling next to Yes. Oh, next. Js, I want you to not pre build these static paths. But at runtime, aka server side render, that's what I want you to build the path when the user is trying to access the link on the browser, server side, render that built, build that at runtime, okay. And then after that, after subsequent requests, that path is already built. And then it's, it's static. So the code here is fallback blocking to server side render that now if you must, if there's really important paths that you need to pre render, like I said, you can just open up parentheses and then actually declare the relative path right here, and say, I have about page in here, somewhere, it'll, it'll pre render that actual path so that like, there's certain passes, you can render. So so let's see how this works in action. Super excited. Okay, I didn't close the server, the dump server. So now in theory, when I click on this link, it should take me to a post detail page with my top five movies of all time. And there it is that it did it. Yeah, there you go. The dynamic route, brought to me this path, which is the parameter of slug here. This is the slug of this detail page. And hopefully you like these movies, maybe you don't, that's okay. And that's how you build a startup headless WordPress site Maciek. I mean, again, I pre built all these files, and we have a step by step tutorial that you want can do but as you can tell, it's there's quite a bit of code code involved and whatnot, but we're trying to lower the barrier of entry to make it that much easier. So

yeah, and what's important right now, this is at least this part the single pages are server side rendered, because you set this static path to blocking Right,

correct. That is correct. So this is the path of server side rendered. And then every subsequent request from then on is is cache.

Yeah, so are the thing that that this, this left we should and I will show how to how to deploy how so? So now it's my turn. I'm just doing some. Okay, let me just zoom in a bit. because I know how so cool this is, in general, the repository, we already talked about this. There is just one thing about which friend didn't mention because it wasn't related to, to the product itself is this Netlify dot tomo file. So this is in short this configuration file to deploy on Netlify. The problem here is the problem, it's that moment when we are using server side rendering, we need a note server. Because the cool part about using everything that is prebuilt, we can just drop it anywhere because it's just HTML. Right? Now, we will have to use Node. That's why we will deploy it on Netlify. Because Netlify has a feature like this. Also, we can use versatile, some digital ocean if we can configure it properly. Okay, so let's do it. Yeah, so we're going to create a new project. Zoom. This is this body run. Project. So let that initialise. Okay. And what we have to do is, of course, create a new pipeline. Pipelines are of course, the set of actions we will be repeating every time we will try to deploy our code. So let's call it deploy to Netlify, right, because we will be and we will do it manually every time. When we press the Run button, let's add a pipe. So we go to our pipeline will do two things. First, we will try to build everything locally, at at Buddy to see is everything all right with our code. Why? Because it's much easier to debug some build errors using Buddy rather than using Netlify. So first, we're going to use that node command. And here we are going just to run NPM instal. And it was NPM run build, if I remember, what is important, if we will, or let's let's run it, oh, I forgot to change because it will be better to run on Node 17. Because you use its newer syntax at some point. So let's, it will be better to do and let me show what will happen because it will crash, it will crash for some reason, and we will fix it together. Okay, so it's now it's installing everything we have in our package json file. It will take a second because the first time is always the longest. Okay, and it's starting to create everything trying to collect the page data. Cool. And we have an error. Why? Because friend used very good practice of storing some of the data in the end file. But we shouldn't never store the env file in a git repository. So we have to pass the variable responsible with the URL of the of the WordPress inside we have something like the variables, and they can be either pipeline wide or action wide. We will store it for the for the whole pipeline. So we need this variable called x public workers PPI URL and it has to be the Okay, so let's see what will happen right now. So let's go back into the run. Let's run it again. And let's see what will happen. This is cool right now.

So again, this time it was faster because all the packages were already downloaded. And this time collecting the pages that we see the generating static pages three out of three, everything is done. So we were missing this variable. So right now we see that the whole build process is working. That's great. So we have it locked. If we will have a prebuilt page, we will just move only this dot next folder onto onto nullify, because we need to learn to note server, which everything is configured in this Netlify dot Tamil file, we will just do it a bit differently still, we will use that Netlify action.

And instead of the default Netlify Deployant select in the directory, we will do something like this and we will I already integrated with with my account called premium Euler. The problem is, if you will try to deploy right now we'll hit the same problem, we had action before. Because Netlify doesn't have this variable set this next public WordPress API URL and it will be built on the server. That's why we have to use nullify CLI has this great command called Netlify env. Set. And we will set the next public WordPress API URL, and it will be automatically taken from our variable. So we don't have to correct it in both places. We will we will store it at once. And then we'll run Netlify deploy and with the build parameter. So there was this built action set in this Netlify TOML file. So everything should work. Let's nice add this action. And the only thing left is to is to run it. Let's see what will happen.

Okay, so we we now have a few seconds. Until we'll, we'll we'll get the result and we'll see what will happen. So already the NPM build, as we see that now we are setting this next public, WordPress APA URL to our URL that we wanted. And in the meantime, we are deploying. Okay, it was set right now and I'm gonna context the belt is happening. We can see that the config file from the Netlify TOML file will be used. Oh yeah, I see. Yeah. Okay. That's why. Yes. And then, yeah, it's always taking away. We can talk a bit about your, oh, we have an error. I always hate when this happens. And it happens Netlify NPM. Run build config environment known version. This is this is rather weird. Let's check. Unexpected tokens. This is weird. It should you know what? I set the version of the node to the latest one. Yeah, you did. I saw that. I saw. I did it. But so you know what we're gonna do? A bit dirty fix right now because it doesn't. It's yeah, this is this is the thing about version changes, and everything's gonna work fixed in the code. Because because Brian is using always the latest latest stuff. And this is and this is great. I mean, I need to find, okay, now. That's why it is jumping like this. Oh, girl by the second. Okay, I'm trying to Okay. It was the fallback? No, this is the post responses. Okay, here. Sorry, not this one. It was on the index js and slide. Okay. I see is the problem. So we're going to fix it right now. Let's get to the index file. Let's click at that. I already see. See the problems here? Yeah, this is it. Because this is this is a newer syntax. And for some reason, I see that. Okay, if I did not set the node version of what I want, I won't go into details right now. Just Let's retry the execution should it should go right That one, if not, we'll just rebuild it from from the beginning, then then it should work. It because this is the thing that was either in the lighter in some latest 16 version or in 17. From from what I learned, because it took me a while trying to figure out Yeah, so let's rebuild everything from scratch. It will be. It will be easier. Let's try it. Let's do it. It should be all right now. And if and if not well, we'll see.

You got it. Love it.

Yeah. Those are the joys of

live webinar in. Oh, yeah.

Yes. Some things are happening. Yeah. But in general, we can see that the problem was related to this. Okay.

Come piled.

Yes. Come on, baby.

Yes, it was at where it wants to be. It went through it went through it was it was this one? Yeah, I'm kind of surprised because I did test before something with setting the node version on Netlify. itself. Didn't work, right.

Is that what okay.

Okay, and then we have the website URL, everything should be working. So we can we can copy the URL. Paste it and see if the website is working. Oh, no, that's it's my old one. So. Oh, yeah. Because I'm using this. I'm using the same account for for all the tests. Oh, please rebuild. What are you? Why are you behaving like this during the live webinar? This is this is really not nice of you. Oh, this is totally weird, Edward. This it's weird. It's something totally different. And it's not can Yeah, that was.

That's interesting. I wonder if it's because criminal Reaper,

it's showing me the the previous version of the website that we're offering is yeah, this is let's check the this one. Yeah, something is. Let me close this. Okay, this one will work. Yeah. So like, I already see the title. And was WordPress starter? Yay. Yes, we have cash cash. Of course, if everything. If something goes wrong, it's the cache. Yeah. clear the cache? Cache? Exactly. So yeah. This is, this is more or less how we, we can deploy everything. Of course, everything, it's very important about keeping an eye on on the versions of node of tools like this. And here we can, we can see that the routing is working. Also, because this part is dynamic. Could you try doing one thing? Please change the title of this website? Spent? Let's, let's do something. Okay. So we can see that without rebuilding that this is dynamic. So we will press the Ctrl.

Oh, you mean? So? So? So. So this actually is statically this dynamic page? Just that just the slug path is dynamic? The actual content is still on the page getting started? page itself is static. Not that yeah, it's the path that's not in the route. Okay. Yeah. So

have to rebuild everything to

we would have we would have to Yeah, we would have to essentially drop in a revalidate ISR function. And that could that we could do that on another on another one. But yeah,

yeah. Okay. So so I think we, we got it we we really covered a lot of things today about building and deploying everything, and dealing with some small box during the live webinar. This is always the best part. Have it. You never know what will happen.

And we have some questions from the audience. So we let's let's try to respond to all of them, especially that some of them are very interesting. First of all Lax asked, When will be WP Graph QL added to core?

That's a great. That's a great question. Um, I don't know. But I will tell you something like that. I'm a big proponent for it. So as Json ball I, it would be amazing. When WordPress ships with Graph QL at its core. I don't know when I hope it's soon, man. I hope it's soon. So yeah.

Okay, so yeah, we are. I remember that at some point. Jason had this discussion with Lennar There are loads of it's who is out there have a similar, have a similar plugin and they were discussing, should we or shouldn't we add Graph QL to the core. And I remember that at some point, they even started thinking that, yeah, Graph QL shouldn't be added to the core, it should be more of a plugin territory because of its nature, because the graph REST API is, let's say always the same. And with Graph QL. It's more about the query language. So yeah, yeah, yeah, it's not that easy. And Maula also asked a very interesting question is, how difficult would it be to use BuddyPress? With Graph QL? Seems there isn't a lot of documentation about it? I mean, if I remember, body press has the REST API. So this is good news. Because at least there is a REST API. I'm not also sure is there a Graph QL for for BuddyPress. But wallet, good news, I because I once played around with creating a Graph QL support for one plugin. It's not that difficult, try and do it, you can try making a plugin for it. It's not that difficult, although then you will have to support it and get hundreds of tickets every day. So I'm not sure where to start. But I think that if, if there was a Graph QL support for BuddyPress, it would be kind of easy to use. Together with static. Of course, we shouldn't use prep building, we would have to use server side rendering in most cases, because if I remember BuddyPress is for this, the social way to add the social plugin to use with WordPress. So yeah. And I see here, all we have this one from Luke Sanders. So would this be the preferred way? If I am building a one page website that will most likely stay static?

I mean, essentially, Luke, that's a good question. There's a lot of variables. That would depend. But but but if you're saying, Hey, if you're asking me, Hey, Fran, would this be the preferred way? If I'm building a static website? And I want to do it headless WordPress way? Yes, you would essentially just statically pre generate that page? Because there, there would be no real reason to use the other rendering patterns. If it's like, if it mostly is just static HTML that you're showing on a page. That doesn't change? Very much.

Yeah, does come converted to HTML and Yeah, forget about it. It's Yeah, forget about it. Yeah, this is the best thing about the about static HTML, it's well static. And we have also this on how can you create a clean editing experience while using component based patterns? Do you retain any server side rendering? Or is it static site generation? Or is the site static site generator?

So how can you create a clean editing experience? Okay, while using component based patterns do you mean like as far as a clean editing experience on the WordPress back end, and then retaining any SSR on obviously on the end, is that I probably think

yeah, it's about something like this. So

yeah. So so as far as from the editing experience is concerned with WordPress, that's one of the major kind of benefits if you will, on when you when you go headless, there's so many CMS is out there. There's Contentful, there's graph CMS. There's Super Bass. Well, actually, that's a database, but you can turn it into a CMS.

There is state make Drupal. I'm working on the list of headless CMS is like, Yeah, I'm on this topic right now. There's a lot of them.

Yeah. And that's the thing, right is that like, as as, as a WordPress editor, like you saw the post that Maciek and I were pulling out of WordPress, by default, the editing experience is just that awesome. In WordPress, it's easy. It's super easy it, it comes with default types, posts and pages, right. And then right away, a WordPress editor in a headless fashion workflow, they can have a front end dev team, and this is how mostly WordPress, headless WordPress teams work. Because I've seen I've seen actual customers do this, they'll have an actual editing team to your point. And they, they just go about their business like using WordPress, they don't, but they now know that, hey, I, I need these front end developers to say, Hey, these are my post types in WordPress, whether they're going to create a custom post type or not, Mr. Editor, you now create the components on the front end, okay. In react view, whatever, you're going to use front end. And then you are going to be in charge of whether you're going to statically site statically generate the page within those components on the page, or server side render, or like I said, you could hybrid render with ISR on next Js. So that's that's exactly the workflow. I hope that answers your question. Because the editing experience stays clean. Like the WordPress content editor, their workflow kind of doesn't change. The only thing that really changes is like, Oh, crap. I need a JavaScript front end developer to create those components to grab that data from like, like we were just showing exactly, I was creating page components to grab the data. So so yeah.

And the last question we have when a non technical user makes a change in WordPress, how can they trigger index js rebuilt? Oh, that's

a great, that's actually a great question. And the answer to that is, there's quite a few ways. Currently, what's really cool is on the Atlas, the Atlas platform, a WP Engine, you could do it via a web hook. And what a web hook is, is essentially it's just an endpoint that hooks hooks into certain backends or platforms to trigger an action. So in this case, say a non technical user. Maciek say I say my content editor and I'm like, I don't I don't want to I don't know code. Simply go simply go into your WordPress admin. You're going to download a plugin. There's quite a few I like WP web hooks, download that, go to your atlas platform. Or you can tell it's easy. Are you familiar developers who don't want to mess with a web hook, you just press generate web hook Netlify has come to for sale has him too. It's gonna give you a body that he hasn't, but he has him. It's gonna generate an endpoint URL, you're gonna embed that URL into your WordPress admin within that web hook plugin. And then you're going to tell that plugin, hey, every time a non technical user publishes a post, creates one deletes one, updates, one, please trigger a build in the front end index js so that it reflects the changes. So that's the, that's, that's a major and main way most people do it. And then obviously, like I was telling, Maciek with, with with ISR, and everything, if a developer is using next Js and the other frameworks do hybrid rendering, they can set a revalidate time period to invalidate the cache so that when you're like, when you change a data in WordPress, whether it's you make a change in the post or whatever. And you publish that you as a as a non technical user can rest assure that the front end code is going to search for that change. Whatever time you sent it, so that's another way and then you could also time it and use a cron job for it, yeah, so anyway,

anyways, so so so we can use one of our favourite phrases. It depends.

It depends. Yeah, it depends.

Also, using web hooks, we can also do one more thing we can connect it automatically that every time someone will press the same post, it will be automatically. So there are there are really lots and lots of ways that we can that we can do it. And it's really up to the situation because true, this is the most important that it always depends on the situation. So also, yeah, this was the last question we have also, with the start of this webinar, we launched a poll in the on the in the two commands about are you using WordPress as a headless CMS? And I mean, this is one of those surveys that didn't tell us so much, because every because it split it almost equally. Only decoupled WordPress, 1/3. Both 1/3. And WordPress as front back a little less, but they were quite quite near of of itself. So still, everyone uses WordPress as they want. Because we have really so much options. There's options. There's options. So really, selecting the best one is isn't easy. It isn't easy. And so friends, I really want to do. Thank you so much for showing us how to help start. I think that next time, Astro right. Will will dive more into us. Right? Yeah,

we actually that's a good idea. Because Fred shot I hope I pronounced your name right, Fred, the CO creator of Astro is actually coming onto my podcast next week to talk about Astro headless WordPress and how Astro might overtake next Js as the next framework. So listen, tune in for that. But yeah, next time because I'm going to be messing with Astro so maybe we do something with Astro Maciek.

This will be amazing. And remember everyone if you want to be up to date with what is happening with our webinars, join our meetup group called Buddy CI/CD group will be always informed about the events that are that are happening. Also, if you like what we are doing, remember to press subscribe or follow us on Twitter, Facebook, LinkedIn, whatever you whatever you like. And next week we will have a really interesting topic to be honest this is one of those topics when I didn't even knew almost anything about it. So I will be learning together with with with Philip tapper because we will discuss why the lack of us array disses kills your business. This SRA is a very interesting topic when it comes to DevOps. So if you are all in DevOps, please join us it will be something really, really interesting. So, friend, thank you. Thank you once again, it was really amazing doing this webinar with you. Also, I wanted to thank everyone in the audience for being with us. And what can I say Have a great day night or whatever you have. So, bye everyone.

Cheers.