 So our speaker today is Imran Syed. He's a WordPress developer for RTCamp. And he's going to be talking today about using WordPress with Next.js. And I will give him to you. Thank you. Hello, everyone. My name is Imran. And I'm a WordPress developer. And today, we're going to be talking about demystifying decoupled WordPress with Next.js. But just before we did that, it's my first time in Vancouver and it's my first time in Canada. I'm really excited about this talk. Are you guys excited? Yes. OK, so let's begin. What is a headless and decoupled CMS? Oops, wrong slide. No, we're not going to be talking about this thing. We're definitely not going to be watching a horror movie. I know this looks like headless. But can anyone tell me what is headless, actually, according to you? So you came for this talk. Maybe some of you have already heard about it. And some of you, it's new. So can anyone say what is headless? OK, the mic. Where is that at? My understanding from what we learned is headless. You have the front end on one side and the back end on the other side. So a back end will be WordPress to keep all your content and you can manage the content very easily. And the front end will be React or anything that you want to use for the front end JavaScript. Excellent. Excellent. I like doing that because I enjoy this being an interactive session rather than you feeling just sitting there and listening to what this guy is talking about. OK, so like she said, not that. So we have a back end and then we have a front end. If you break, like, shop this neck off and we separate the back end from the front end and that's decoupled. And then you have an API through which you can access the content on maybe an app or web. And then you also have headless where you can access the content and deliver it anywhere, even on IoT devices or a mobile app or a TV app. I've even built the application for some of our clients where they could power and leverage the content from WordPress and use it on the television for the TV app. OK, so before we continue further, does anyone know what's the difference between headless and decoupled? Because I know that sometimes people talk about headless and some people talk about decoupled. Does it even click in your mind sometimes that what's the difference? Doesn't even know what's the difference between headless and decoupled? OK, I'm not seeing any hands, so let me share that with you. Well, decoupled CMS is actually proactive, which means it prepares the content for the presentation and it delivers directly to the environment. And headless CMS is reactive, which means it manages the content and then just sits and waits for some process to ask for it. So that's the main difference, proactive and reactive. Now let's look at the trend of how headless has grown over the past few years. So if you look at the Google Trends data for the last 10 years, you can see that it started from almost no interest to really high interest now. So why do you think it's gaining popularity? The first important thing is the separation of concern. When you have the headless CMS, where the back end is separate from the front end, it's really easy for you to access the data in any part of the application, whether it's mobile or it's web. And also, it allows you to create a richer user experience, because when you have these JavaScript powered applications, the experience the user get is really, really fast. I'm sure you will agree to that. And of course, with JavaScript application, you have better performance. Then you have the flexibility. Now, why flexibility is because once you have just the headless back end, now the content is really flexible. I can just serve that content on any sort of application. I'm not tied. It's not like a monotholic architecture where everything is tied up. Then you definitely have security. Doesn't even know why a headless CMS, building headless CMS, will provide security. OK, I have one person. When you have just an API to communicate with, then you have much more control. No one can log in through an API. They can log into the back end, but you can have more restrictions on that than you would for an app where everybody could come in. So that would be just like one great layer of security just right off the bat. Excellent. Let's have one more question. Absolutely. So when you have the headless CMS, it becomes really hard for the hacker to hack into because your back end is completely separate. And the front end, you don't really have a tie up on the front end. And of course, it's future proof because technology is moving so fast. Like when I came into this industry, it's not like you just learn something today and you're done. You have to keep upgrading your knowledge. And tomorrow something better comes. Like today is next year. Tomorrow it could be some other architecture. So if you're building everything together, which is tightly coupled, it becomes difficult for you to move out of it, move out of the bubble, and try something new. But when you have decoupled architecture, it's really, really easy because my back end is separate. Let's say tomorrow a new technology come and I want to change my front end. It'll be really easy for you to do that because I just have to access the API. It's not tied up. So it's easy customization on front end. So I'm sure some of you who are developers here, okay, let me check how many of you are developers here first. Wow, wow, we have a full house of developers. That's nice. So for developers, I'm sure there'll be some clients who'll come to you, you know what? I want to go ahead and change this part of the site. And then if you go back and say, okay, no, I cannot change it because it requires some data. It needs to, it's like really, really tied up in that PHP template. And it's really hard for me to do that. But when you have a separate back end and when you have the API, you don't really have to worry about it because they could be just front end developer who just need the data. And they can make the changes in the front end very, very easily because it's not tied. So you have faster development because the developers can work in isolation and just tell the back end guy, I just need the data in this form, maybe adjacent format and I can bring the front end. I don't have to wait for the back end development to be done faster. Okay, so security, you can use modern libraries like React, Vue.js, security and scalable and it's future proof. So why use JavaScript themes with WordPress? So a few years ago, I think when Gutenberg did not come into existence and people are talking about Gutenberg and people really didn't want to go JavaScript and use Gutenberg. So there was a lot of reluctance amongst people using JavaScript in WordPress. They were happy and comfortable because that's what human tendency is that we are quite comfortable in the way we are working. We don't want to try something new but over the period of time, there has been a lot of interest among developers using JavaScript applications. I'm sure you'll agree to me, right? Excellent. So with JavaScript, you basically get performance. You have better user experience. You can actually build complex, highly interactive JavaScript front end applications. For example, building complex search functionality and it can be made simple with React state management. How many of you have used React? Wow, that's really nice. So you know that in React, you have the state management. So with state management, it becomes easy for you to build really complex applications, especially when you have like a search functionality and you can handle everything in isolation with the state management. Then you can have component-driven development with Storybook. Has any of you used Storybook here? That's nice, I can see a few hands, that's good. So Storybook is used by big companies like BBC, Netflix, Twitter and a thousand more teams. So as you can see, this is how it looks like and even Gutenberg components are used in Storybooks. So what Storybook is basically, it allows you to build the components in isolation, which means one developer can just be working on the header, another developer can just be working on the footer without having to have any kind of a dependency between each other. This becomes really easy when you are doing the testing or if you want to show one particular component to the client. Okay, and then of course, with JavaScript coming into picture, you have lots of cool libraries that you can use, which are pretty useful. So if you build our front-end in JavaScript as a single-page application, how would it affect our site's SEO? So SEO has been one of the concerns that we had, always had when building the decoupled application that how Google is going to look at it. But before we get to that, how many of you already know what a single-page application is? Okay, so good. So most of you already know. So basically, a single-page application is like, when the user accesses your application, there's no page reload. When the user clicks on it, it generates the content in the page on the fly and it shows it to the user. So when we are using single-page application, basically, there is no data on the front-end for the first time. So how would Google actually index the JavaScript-powered application? Because when we are doing server-side renders, pages, the data is already present for the Google to index. But in case of JavaScript-powered application, where we have a single-page application, everything is generated through JavaScript on the front-end, in the browser. So how would Google take care of that? Has anyone heard about two waves of Google indexing? Okay, good. So I have something new to share with you. Excellent. So how it works is that in the first wave, Google will crawl the page and fetch the server-side rendered content. So that's your first way of indexing. Then it reruns the indexing for the new links to be crawled. But for the JavaScript-powered application, where it's a single-page application, the data is not present. So will it not... How many of you think that it will not be indexed because there is no data? Okay, so a few of you think that Google will not index those applications because there is no data. But most of you think that, yes, it will be indexed. You are right. It will be indexed in the second wave of indexing. So JavaScript-powered applications, rendering is deferred, which means rendering take place when the resources are available to render the client content. So it will return after some time and it will re-index when the content is available. Now, this time can defer. It could be after one day, two days, three days, after a week, a month. We don't really know. Do we really want to be dependent on such kind of thing where we are leaving it on the hands of Google to index? Because SEO is really, really important because that's how our pages are available when somebody searches it. So what is the solution for that? So before we discuss the solution, let's discuss what is server-side rendering and client-side rendering. So who likes noodles? Everybody. I know we are getting close to the lunchtime and you will be hungry. But let me try to explain to you what server-side rendering and client-side rendering and with the help of noodles. Okay, so in server-side rendering, let's say we have a server. Server does all the cooking of the noodle. Then you have the internet, which gets the cooked noodle and the browser also gets the cooked noodle, okay? We will relate to that in a moment. Then in client-side rendering, server has all the ingredients, which is nothing is cooked. Internet gets just the ingredients and the browser does all the cooking basically with the noodle. And we also have something called static-side generation which we'll talk more about in a moment where you already have cooked noodle and the internet gets the cooked noodle and the browser also gets the cooked noodle. Which of the three processes you think is the best for the user? Server-side rendering. How many say server-side rendering is the best? Okay, we have a few. Client-side. Okay. And static-side generation. Okay, so I see that many of you are still confused which one is best, but we'll come to that, don't worry. I'll keep that as a surprise. Okay, so when we do the server-side rendering in PHP before we get to the JavaScript, we have a PHP server. When the user accesses the URL, the data is already available. Okay, now this is good for Google indexing because Google can see all the data. When the second URL is accessed, again you already have all the content available from the server. And same goes for the third URL. Now when you have a client-side rendering, you can see that you get an empty page from the server. You don't have anything. So nothing for the Google to index. And then when the page is loaded, then there's an API call and JavaScript does all the cooking of the noodle and basically generates the page for you. Not very good for Google indexing. When you have server-side rendering plus client-side rendering, what happens is that you already have the page available and then if there's any new API called like a hybrid page, then it'll call the API and make the page intractable. So, in client-side rendering, empty body, JavaScript is loaded, and then it becomes viewable and intractable. In server-side rendering, page is already viewable, JavaScript is loaded, and page becomes viewable and intractable. Okay, so now let's talk about what are the problems when we use JavaScript themes. So you all want to use JavaScript themes. JavaScript is really cool. It's amazing, it's fast. Yes? I have a question. In client-side rendering, the heavy rendering happens. Yeah, is it okay we talk about that at the end of the talk in the Q&A? Excellent, thank you. Okay, so the problem in using JavaScript themes. So you have a PHP server, you get the HTML and the browser does the HTML in JavaScript. In JavaScript themes, you get empty HTML files, which means everything, all the heavy lifting is done by the browser. So how do we solve this problem? The solution is that we need the server-side JavaScript applications. Now, how many of you have worked with Create React app? Okay, many of you. It's very easy, very simple, but the only issue is that you have the single-page application, so all the content is generated in the browser. But we discussed that we need to have server-side rendered applications. So instead of doing that server-side rendered applications ourselves, which is a little difficult to do or challenging to do, we have lots of frameworks available that does all the heavy lifting for us. You heard of Gatsby? Yes, excellent. So first framework is Gatsby, which is a React framework, and already does the server-side rendering out of the box. It's also a static-side generator, so we discussed about the static sites where the page is already available on the server-side as well as in the browser. It's available for general use, works with WordPress, but you need to know GraphQL for that. Next year's React framework has SSR. It's ready for serverless also, which is pretty cool. And then you can connect with the rest API. You also have FriendTiti, which also has server-side rendering. Then lastly you have Next, which is a view framework if people like view, and you can make a call using the rest API. Now, let's discuss about what are the problems we are going to face with a decoupled, because many of you are here to understand what are the solutions, what are the challenges that we face when we're building decoupled applications. And I have built over five different applications for enterprises, so I have kind of already known what are the issues you're going to face if you haven't built already. First thing is it increases complexity, right? Because when you are in the WordPress environment, everything just works out of the box, but when you come outside of that and you're building your own applications, certainly you have to build a lot of few things that already exist by default. And plus you have, there's a cost of training the developers on how these two architectures work. You have to rebuild many pre-existing solutions, such as SEO. Like you have the Yoast SEO plugin, you just install it, and it does all the heavy lifting for us, but now when you go decoupled, we really have to ensure that all the elements for the SEO are present on your front-end application as well, because you're building it yourself. I know clients will come and say, oh, just the plugin, you can just install the plugin and I'll get the feature, but no, it doesn't work that way in the headless architecture. If you're gonna install a new plugin, it's just not gonna work out of the box if it's a front-end functionality. You'll have to build that. Preview. How many of you came to this talk to understand how preview is gonna work? I know some of you already spoken to me before this talk about that, so yeah, we'll talk about preview as well. Okay, two hosting environments, because you need the environment for PHP to host your WordPress, then you need an environment for JavaScript applications, maybe a Node.js. You have to manage two code bases, one for your WordPress, other for your front-end. So when does decoupled make sense? You must get some thoughts like when is the time I should pitch decoupled to the client? Because for many of you, it's a really cool thing to use JavaScript, you go headless, but does it actually make good for your client? Is client going to benefit with that? Because every client comes with a different problem. So we as developers need to suggest the right solution whether headless is best for them or not. So first thing is portability. You know that you build a backend today and tomorrow if the technology changes, you can just change the front-end into any technology of your choice. You have content mesh, which means you can be serving content from multiple sources into one application. And then if you have an existing JavaScript-driven team, but if you want to go headless, you need to have developers that know how to build the application with JavaScript. And also prepare for the future because there's a growing interest in JavaScript. So let's talk about the enterprises. Since I have built a project for enterprises, what are the concerns they had when they wanted to build WordPress with decoupled? First thing they have is the scalability. So most of the enterprises, they do not have like just maybe 100 posts, 200 posts. That's for a small scale. But for enterprises, they have like over one lakh posts available. So you need to build an architecture that's really scalable because they're gonna have a lot of users. So for example, if Apple comes to you and say that please build a decoupled website for me, they're gonna be having a lot of users. So you have to take care of that. And of course, data security is extremely crucial and caching because you don't want to be serving content. When they have a high-end traffic, for example, Apple, they will be having lots and lots of users. So when they come to your website, if you're gonna make so many requests to the server, server can really go down. So you have to make sure you take advantage of the caching and don't keep making requests to the same endpoint. And of course, the SEO. Then forms, how to handle forms when you are building a decoupled architecture? How would you build search and filters, et cetera? Now how do we address these concerns? Well, the easiest thing we can do is choose the right framework. For every client, it could be different. If a client comes to you and says that my website is not gonna be changing for the next six months or one year. If the content is not really gonna change, then probably you may want to provide them some static site generator where you don't really have to build every time. But if somebody comes to you, which is like maybe an e-commerce website where they have to keep updating their products, at that point, you have to make sure they get fresh content and build it in the right way. Okay, so let's talk about why I would choose next year. Now everybody over here may have a different suggestion or preferences, but here is what I think why next year's would be most suitable in most of the situations. Okay, so the main problem that I faced because I have built websites with Gatsby, I have built it with Frantiti, I have built it with next year's. The main problem that I faced was updating the starting content. So what was the problem? So let's say you build a website and you run the production build, everything is static. Now if the clients wants to go ahead and update a post, that data doesn't show because you have to rebuild. So to solve that, next year's has got a really, really cool thing which I love next year's about, which is called incremental static regeneration. Has any of you heard about this incremental? Okay, I know a few hands, that's good. So what this does basically is that, let me just explain to you in simple words. So when you run the production build, it's gonna generate the static content. Now next time when the user requests, you can set a time, like within one minute, any time a new request comes in, the first request we are going to go ahead and serve the static data and any time the next request comes, first time I will go ahead and rebuild the page, for which I don't have to build the entire application next, just does that on the fly, and it's going to store the new version of the page in cache. So at build time, we get the data and we generate the HTML, that's your static page on the server and that gets served to the users. In the incremental static regeneration, let's say we have set a time for one minute. Within one minute, if the first user comes, it triggers a regeneration. Only the first user gets the old version of the page, but anybody else within that minute, whoever comes, is going to always get the new version of the page. Okay, so we don't really have to rebuild ourself, next year's does that on the fly. Okay, so how does the decouple works in next year's? We use the WordPress dashboard for content management or to update the content on the front end without having to rebuild. And React theme lives in Node.js server and also uses Webpack to bundle Babel to convert modern JavaScript out of the box. It uses server-side React application, it's SEO friendly, handles routes for you out of the box and also have built-in error handling and 404 page. So many things that you actually require by building the application next year's already solves most of the problems. We don't really have to reinvent the wheel every time we have a new project to work with. Okay, so next year's has been used a lot of enterprises, a lot of big companies, we have Netflix, Jobs, TikTok, Twitch, Hulu, you have Nike, HBO Max. So this tells us that this is really reliable. How many of you are feeling this right now? Okay, one of you. Okay, a lot of information. I know, I've tried to squeeze everything in a short span of time, but yeah, let's see how that goes. So there are some of the decoupled projects that I have worked with. One is the Open Web. So this client had over one and a half lakhs of post. So we built this in Gatsby. We couldn't convince the client for the next years because they already convinced on Gatsby. Said I wanna go for Gatsby, okay, no problem, we'll build that. This is the e-commerce website that we built called Waldo's Friends, where this entire application is built in next year's and it uses WP GraphQL in the backend and we've integrated the Payment Gateway integration and everything for this client. Okay, so choices of API. We have two choices, one is GraphQL and REST API. WP GraphQL is basically a plugin that exposes the fields to WP GraphQL schema. You can download it, it's heavily used by the community. Some of you might have already used it. You can get multiple resources in a single request. It's extensible, so there are a lot of plugins available for what you need it for. Like for Gutenberg, you have WP GraphQL Gutenberg, you have JWT authentication, for pagination, for Yoast SEO, and then for the REST API. Good thing I like about REST API is that it's already built in core. So you don't really need a plugin for this one. It's extensible and easy to learn. You don't need a GraphQL knowledge to work with REST API. Easy to maintain. Now, a lot of things that you need to do in REST API, I've already done that in one of the plugins called Headless CMS. Like for example, you need a header, you need a footer. So all those things, all those heavy lifting has been done in this plugin and if you need a custom endpoint, that's been built as well. So if you wanna use it for building your application for a decoupled, you can use this plugin, it's a free plugin. Okay, for SEO, with the WP GraphQL, you will need to use the WP GraphQL Yoast SEO plugin and with REST API, the SEO data is already available and automatically available in the REST API endpoint response when you activate the SEO plugin. So you can see that if you activate that plugin, REST API will have your Yoast head json, you'll have the schema, all the OG description title, et cetera. And on the front end, this is how I've used the REST API to make sure all of the SEO tags are available like OG image, OG site name, OG URL, your Yoast schema, all of those that are already present. So this is how you can do that in a decoupled environment on the front end. For authentication, with GraphQL, this is a JWT authentication plugin. So how you would do it is that you'll make an endpoint in next years called slash login and when this endpoint is hit, it basically makes a call to the GraphQL which basically uses the JWT authentication token and it sets that token HTTP only cookie and with that information, you can have a successful login. With the REST API, there's a JWT authentication for WordPress REST API and let's quickly talk about forms. So for forms, you can use the REST API endpoint that contact form seven provides. Okay, this is the interesting one, the page preview. So the problem with the page preview is that when you are in the WordPress environments, it's very easy because you already authenticated but when you make the coupled, the front end is not authenticated. Front end has, so WordPress has no knowledge that you're actually logged in. So for that, when you're building preview, what we really need to do is that we basically make a call to an endpoint that we build in next years called API slash preview where we go ahead and store the auth token in the HTTP only cookie. So you go ahead and log in. Once you log in, then it's going to send a server side request for the preview article with the auth token in the HTTP only cookie. WordPress gets that information so it knows that it's authenticated. It serves the response with the preview article data and it gives that onto the front end of next years. So here is how it works. You go ahead and log in and you can see the preview page on the front end of next years and that's your WordPress. You go to a post, you click on preview and that opens in the front end on next years. You don't have to keep authenticating it once you've already authenticated. It stays there for some time. Gutenberg editor. So some of the styles, some of the challenges is that the styles won't be really available for you on the front end. So the solution is that you need some of the styles like block library style min.js and then your block library theme.min.js CSS. So you can actually install these packages on the front end called WordPress base styles and WordPress block library and you can import that onto the front end and that would allow you to use Gutenberg editor styles onto the front end as well. So now you can see this is the front end and all these styles are loaded. You can see these are the classes from the blocks, WP block columns and these styles are now appearing on the front end. So you can build your Gutenberg posts in the back end and you can see that on the front end as well with those styles. Let's talk about caching. So for caching you have react, hydration and deconciliation. The HTML is used to immediately show a fast non-interactive page, initial preview of the client and server components payload used to reconcile the client and render server component trees and update the DOM. So all the hydration happens on the front end in react and Next.js does all the router caching for you. So it automatically renders the caches routes at build time. So this is how the cache looks like in Next.js. Okay, so I'm just gonna quickly move to some of the next slides since we don't have much time. If you wanna learn more about it, there's a course that you can get called Next.js headless WordPress course and you can learn about building the Next.js applications. Here's some of the references that we have and that's about it. Any questions? Yes. Can you give me this? Yeah, absolutely. Does that one of your questions? It's easiest about accessibility to introduce single-page types and accessibility. Google is the world's biggest line. Accessibility needs user, but one of the things they were saying is that there's often a struggle to get accessibility working with JavaScript rendered stuff. I don't think it's as big a problem with applications, but for regular websites. How is that being addressed? Because I'm sure that I'm out of date. That's a very good question. So accessibility is something that we, as developers, it's our responsibility to ensure that we take care of building the websites. When we are dealing with WordPress environment where it's not decoupled, a lot of things are done for us, but when we are building the rendered application ourselves, it becomes our responsibility to make sure all the relevant tax, accessibility tax are present in your HTML markup for the users. Because when we are targeting the audience, we're not only just targeting the people who can, who are capable of using the website, but we also have to look at people who have some accessibility issues. So yeah, I completely agree to you that it becomes our responsibility to make sure all the accessibility is taken care in your front-end application. Thank you. Anyone else? Just one thing, if you do have a question, just wait until I get to you with the microphone because the camera is hooked up to the microphone. So if you're not talking into a microphone, it won't be on the recording, unfortunately. Okay, so it looks like we don't have any other questions. Okay. Thank you very much. Thank you, everyone.