 Good afternoon, dear people. I'm so grateful to see you today at WordCamp Germany. Today we're starting the session with Mario Wolff. Mario is a solution architect attentive to digital strategies, consulting and concepts. Digital nomad at heart that loves to work from fantastic remote locations. Checking out the best coffee places, extraordinary street foods or fun co-working spaces around the world. So if you see him somewhere, so I'm sure please say hello to him. What today we will be talking about and what Mario will be talking about is the idea of decoupling your WordPress front-end and WordPress back-end and how that actually job brings a lot of opportunities and disadvantages. But who can benefit from this concept? So we will hear from Mario and we will have a quick look into the idea how it works and in this brief introduction into Headless and the coupled. One more just thing before you leave, please make sure that you are very quiet because there is another session going in track one. Thank you very much and Mario, if the floor is yours. Thank you, Mario. And thank you to you all for being here in numerous attendees. So we have about half an hour to dive a little bit into Headless. And I'm curious to know who of you know what Headless means or... Okay, so more than the half knows what it means and then who has been working with Headless in your projects? Okay, so now I'm even more curious. What did you use? Like if you just want to throw in an example of what you've been using? Mobile app? Okay, mobile app Stratis CMS. That was interesting. Yeah, and using caching you said or... Okay, we'll talk about some of these things. And if you have any questions, let me know. I think we have a question block in the end because of the microphone. So I think you know who I am and what we're going to do. So let's dive in how WordPress usually works. And I think most of you are aware of it, but... So every time somebody visits your website that is based on WordPress, a whole lot of things happen in the background before they actually see the website in their browser, which means we have a user on the one side that is requesting your website through a URL through the browser. And that will be resolved to a server that then runs this complicated package of WordPress, which is based on a web server, Apache, nginx, file system, PHP, a database. And only then we get to the level of WordPress, which is the core, the themes and the plugins. And all of that needs to rotate to deliver one single page of HTML, CSS, JavaScript, and all the media files. This means one request has to go through all these layers to be answered. And in some instances, this can be totally fine in most instances. And in some, this might create a bottleneck somewhere along the way. It could be anywhere that you have some limitations. And we talked already a little bit about caching. So the idea is if you have a project, and this is what we usually do in the beginning, we think about what we want to do, what we want to achieve. And in concept, we think about what's the best solution for our customer. And thinking about this traditional cycle, it's not always the best solution for all the projects, depending on what you're going to do. And we're going to talk a little bit about who would benefit from headless or when it gets to be interesting to use it. What is headless? And for those of you that don't know it yet, headless is the separation from the back end and the front end. So basically the front end meaning just your design, which is called the head. It's everything that you actually see in the browser. And everything else, which is your content repository, is called the body and that lives somewhere else from the front end. And then we get to another term. Both of these terms are used quite widely in different aspects. Headless is also used in other contexts. And the second term is decoupling. We already touched it a little bit. Decoupling means just ripping apart different things to make something work better. Not always the case, but the basic idea is we have the traditional cycle that we just looked at and then we split it up into our headless infrastructure where we have the body. We talked about the body that is still like our traditional infrastructure. It looks very similar to before, but now we're emphasizing on the interface, which we all know is API, REST API, or another term that now comes into play is GraphQL, which is just another interface similar to the API. To transfer data from your backend to somewhere else. Could be a mobile app or another front end web application. Some people use it for mobile digital signage. Could be anything where you want to use it. And you can do this right away right now with any WordPress installation because the API is activated. You can use the API to pull data from your existing website into any other thing you want to use it in. Options for decoupling, and we spoke about it. One, this is not like fully coupling because it's kind of like still integrated, would be caching those side. Basically saying, I have a WordPress website, it's running fine, but we're running into some performance issues. So we want to start caching the website, which is kind of saving the request that we saw earlier. So it doesn't have to go the full cycle. The web server immediately sees this request has been cached and it can give you the cached version of the website so you don't have to go through all of it. Saving performance, giving you the result immediately back. Saving time. And this basically is a kind of decoupling because it doesn't go through all of the cycle. So I just doodled it out here. Let's look at another one, and that one was touched as well. The static site generator. It's basically doing what the word says. It generates a static site from your WordPress instance. Let's say you have everything, your website runs, you have a front end, and now, I see it's still words in Italian. You start the static site generator, which is a process that runs independently from your website or any delivery. And it's a build process that picks up all the little things that you have set up in WordPress and basically builds an HTML-based website. And that one you can then put anywhere you want, which is basically the same mechanism, not not the same, but similar to the caching. But you can now decide to put it on a content delivery network or on guitar pages or whatever and deliver your website through there. Now, the question would be how you run it continuously whenever you have changes in your websites and all that, but there are solutions for that. And we're going to look at them in a little bit. This is just different concepts. And then the third concept we want to talk about is JavaScript-based. There's a term for it. It's called Jamstack. You're going to look at that too. It's basically doing the same thing, but including way more JavaScript, which gives you way more functionality to put in the front-end. So a static site is what it says it's a static site. It doesn't have necessarily interactive functionality for your users to use. Let's think about a contact form or stuff like that. And with more and more JavaScript inside of your static site, you can offer more and more options in the front-end. So this is why that would be interesting. It's also based on a build process which interfaces with your WordPress instance. And we would say a continuous deployment cycle that then puts the result of this static site, again on a content delivery network or something like that, just as a third concept. So these are, let's say, three different concepts for decoupling. There's certainly more, but these are the most common ones. And the static one, there's actually, it's relatively easy to do because there's a nice plugin for it. It's called Simply Static by Patrick Posner. And basically inside of WordPress, you install the plugin and you can say, put on, configure it and create your static website fairly easy. You get a result out of it that you can put on any web server statically and at once. So your website is, let's say, a zip package at the end. You put it somewhere and it runs. Your infrastructure becomes a little bit more complicated now because you have at least talking about one WordPress instance where everything runs your regular WordPress server where users put the content in and then you have at least one second instance where you put this static website to be delivered. This already gives you some benefits where the front end is decoupled from the back end. So you can say nobody will ever see the back end except for your editors and content editors. So security issues are less concerned, for example. So WordPress can be totally covered up. Nobody can access it from the outside. And in the front end you only have the static website which is being delivered very faster than a usual WordPress request would be. It could be less cost because delivering a static website through, for example, GitHub doesn't cost you anything and you can even integrate it with your domains, I think. It could be an interesting option for you depending on your project and that we're going to talk about in a little bit. Jamstack is way more complicated. Now we're talking about a lot of different libraries. So just to go back, Jamstack we would use to create a way more interactive front end. And the Jam stands for JavaScript, APIs and markup. So basically this bundle will create your headless website based on the data from WordPress. You can use vanilla JavaScript, you can use React, you can use View and a lot of other flavors out there, many other flavors, to build the website. The APIs, the integrated one is the REST API which is also supported by WooCommerce and ACF. It runs custom fields. For additional libraries there's additional plugins like Gatsby has its own plugin, Yoast supports APIs and then you have the GraphQL which is a totally separate its own version of an API based on more of a SQL language instead of REST API commands. And then for markup which is just generating everything, together in a readable website for the browser, there's also a lot of different frameworks. Depends all on your taste I would say or what you're more comfortable with, being Next.js or Gatsby or whatever you enjoy using. So why headless? And we talked a little bit about some advantages already. One advantage is your users, your customers, users are still used to use the WordPress backend, they can still keep using it. Everything stays the same for your content editors. You have an edit flexibility where you can work with mobile apps or like we said earlier, digital signage or all the different devices that are out there and still use WordPress as your source for the content or other things you want to use out of it. Performance, talked about that. Like a static website doesn't have to be rendered by the server through all the process that we looked at earlier. It just gets delivered in usually very quicker. The edit security thing where WordPress is not out there to be attacked. You can hide it behind any kind of firewall you'd like. You can use modern framework.js which a lot of front-end people really enjoy. Gives you a lot of functionality there. But it comes also with disadvantages. For example, we talked about the static website, the basic version of it. It doesn't give you necessarily all the functions that you're used to. Let's say your website has a functionality for contacting you, contact form or comments or everything you can think of that is requiring interaction. It's not necessarily static because somebody would have to talk to the server about it to save the information the user puts into the website. A static website by itself cannot do it necessarily. You have a form there, but the form needs to go somewhere. If you only have the form data that has to go somewhere. Now, using a static website, you have to think about how to do that. Using the simple static approach, it supports contact requests, for example. With the Jamstack, you have way more options because out of JavaScript, you can use the entire WordPress API, which then wouldn't be entirely decoupled anymore, but you could still use the API to post something to your backend and use functionality there. So you have to think about how you want to do it. Or you can use other integrations. If you use a newsletter system, for example, and you want to have people subscribing it, they usually offer you a JavaScript way to do it right out of the site so you don't need any WordPress functionality there. Another disadvantage is that there are currently less themes available for this kind of approach, but there are. It's still interesting to look at it and they're becoming more and more. There are some people also in this community that do themes for a static website or a Jamstack project. Anybody who wants to build a front-end like that usually needs a lot of knowledge in JavaScript. Matt Malinweg already said that when he introduced React to WordPress that everybody should get familiar with React, and this is an added case for that. So a lot of headless websites are based on React, which you can use here. The added complexity we talked about and now we're talking about multiple systems. Using multiple systems means also you have to maintain them and usually you will find less support for this kind of work than you would within the WordPress community. So I think we can agree that there's a lot of information about how to do something in WordPress, but not so much in all these different flavors of JavaScript or specifically in doing this kind of work with WordPress, JavaScript and all these elements included. This will also change, but it takes time, of course, and then it also depends on how many systems out there will survive and how good they're going to be documented. Now the biggest issue in my opinion is there's a lot of frequent changes in the JavaScript frameworks, be it React or be it Gatsby changes. Even Node, if you update Node from 16 to 18, your project can break and nothing works. You have to look at what happened, what changed and get everything to run again. These changes are not updating something easily. Usually they're breaking changes, meaning sometimes you start from scratch beginning and setting up your project all over again. Because when Gatsby changes from 4 to 5, it doesn't mean it's backward compatible. Okay, we talked about performance just to give you a brief insight into one of our projects. We did an analysis of how it was running and why it was not being delivered quick enough and in this case we run a New Relic report. A lot of calculation time we lost just on the PHP side. Other projects sometimes you have more of a MySQL problem and we then decided, okay, let's see how we can solve this and Headless was one way to go to do some performance. It's also interesting for your SEO, of course, we all know nowadays they look for your delivery times a lot. Security, we also talked about it, dividing back and in front saves you a lot of has, not meaning that you shouldn't take care of your WordPress anymore, but it's not as out there as it was before. Flexibility we talked about. You can use your data that you already have in WordPress so many other contexts. And now the most interesting question. For who is this interesting? For which kind of projects is Headless interesting? One thing could be your website doesn't change a lot. A lot of pages out there represent a business, like a business card that doesn't change a lot. There's no, like how many of your customers are actually able to provide like a news section or something like that. Even a news section changes once a week or something. It's simple enough to create a static website after a news post has been published and just update the static site. Websites that need to load very quickly, very good for this kind of work. The other one is security or vulnerable websites to hackers. If you're already very knowledgeable in JavaScript, you can use this. Examples could be purely informative sites, which could be like the business website we talked about, or you have a politician that is running for a campaign. It's very static. He's presenting himself, has a lot of visits, put it statically out there. You don't have to think about maintaining WordPress behind it, runs easygoing. Magazines, like usually when we publish magazines, we do it quarterly or monthly or something like that. After that, the magazine information doesn't change. We render it out statically and put it on CDN. We don't think about how many visitors we have. It's always being delivered in quick times. Lending pages and campaigns are also usually pages that need to be delivered very quickly. There you might have added functionality like you want somebody to subscribe to something. You can go as far as thinking about single-page applications. Those are usually built and rendered out as well and even progressive web apps. That's it. We have how much time left? Okay. If you would like to, we can look into a project and how it works. Basically, I quickly took our WordPress Meetup website, which is not the most beautiful project. I'm just saying this upfront. This is our WordPress Meetup Düsseldorf website. It's basically just a couple of posts telling about our upcoming events and also giving some reviews of already-happened events. That's it. It doesn't change a lot. We could easily render it out and serve it statically because there's no... I'm aware there's no contact form or anything. It's super easy to just deliver it differently. For this example, I chose Gatsby. Gatsby is based on React. I can open it quickly. Gatsbyjs.com. It has some built-in WordPress support, meaning there's some documentation on how to do it. Basically, what you need to do is install two plugins, which is the WP Gatsby plugin. And the GraphQL plugin, which gives you this added interface that we talked about. Then you can run... Locally, you can run a command to just spin up your website. Oh, not your website, your Gatsby project. What it does is it's loading like a starter, building everything up from the Gatsby sources. You need nodes for it, NPM, and what it does in the background, it puts your repository together. Everything you need to build your front-end, the base of it. Let's have a look at how a project like that looks like. Basically, you get your Gatsby site contents, our content folder, a public folder, a source folder, and some config files. Basically, what you do in your config file... Oops, sorry. It's small, right? So basically, for this purpose, you only need to change one setting, which is basically saying what the GraphQL URL is, which is your basic website, in this case, WPDUS.DE, slash GraphQL. And once you have that, you can run another... This is still the building process, almost done. But I of course prepared it, so we have more time. In your terminal, you just say GatsbyDevelop, which is the one you use while you're developing. What it does, this is the build process we talked about earlier. So at this point, it takes all the source files from Gatsby that we just installed, connects with your existing WordPress website, and builds a package out of it. So it loads everything that you have set up in your front-end repository, Gatsby, on this side, and pulls the information from all the nodes. You see it here, menu, taxonomies, comments, posts, pages, user roles, menu items. This is all the source it loads from your existing WordPress websites. And now it's building. So we're actually downloading still. So it's downloading the media that always takes the longest. And it actually already can put improvements to your files, like it generates quick loading images for you and stuff like that. It already does lazy loading and whatnot. And now it's building the bundle, writing some JSON, which then is being used to deliver the website. Oh, it's already done, sorry. So now you get two URLs for your local host, which is localhost.8000 and localhost.8000 GraphQL, which you can use. It's a browser version of GraphQL where you can play around with your data. And let's have a look at it. So this is the localhost.8000. It's basically what it did in this very easy version. I didn't do a lot of to it. I just changed a little bit how it looks. It loads your posts, the posts that we saw earlier from the website and gives you right now a basic post grid. And everything you do here now is statically happening only on this computer. It basically loads the posts right away and you see the images. Actually, here you see how it's loading the images. Right now it's so quick you can't see it, but it has preview images. So you usually see preview images before loading it so you don't have what's the name for it, the content disposition thing. And yeah, you can... Yeah, thank you. Oh, it's actually right here. Yeah, so easy-peasy one website running and maybe you can see already some issues like it doesn't have a navigation, like no menu right out of the box. You have to build it. So this is where it becomes complicated. Basically, the starter gives you this kind of structure. You can browse, you can even search. You can watch your posts. Everything is here. But now you need to get starting building your own Rondend. In JavaScript, in this case in React, in Gatsby or whatever you use. This is where the added difficulty comes in or where maybe some of you are already used to working like this but it's nothing like working with WordPress. Yeah, we are out of time. Excuse me. We can go right into the questions. Thank you. So you have all the files now and what do you do now? That's enough to do another two sessions or workshop. But I can show you quickly. Your structure is basically your source files. You have some components in here which are interesting, which is like the base layouts for stuff. You know this approach from MVC working or something like that. So you have some views in here, layout, base views. You can set up your SEO stuff. You can pull it right out of using Yoast or whatever you use already and implement it. So it's actually supporting SEO very well. You have your CSS and you can add single pages to it. You can also use the pages you already have in WordPress. And then you have your blog post. Basically the view for your blog post, your template. What I added is loading the featured image for now. And basically you see some HTML here where it loads the image, for example, into it. And then your post information, navigating forth and back. And the same thing goes for the archive. Basically you have the template for your archive, which is just a list, an unordered list in this case. And it loads everything from this query down here, which is being queried against the GraphQL. So up there you have the template down here. You have the information on where the data comes from. It pulls it through GraphQL from your existing WordPress. And then everything is being melded together. You can do a lot of more things with it, a lot. For example, you can generate your icons and stuff automatically with every build and stuff like that. Another interesting thing is it runs live. So if I have this post here and I edit something. So let's say, oh no, this is not it. On the left side we see our static site. And let's go into editing in our regular backend in WordPress. And I changed something here. The changes should be pulled, and I hope it works, into your static site without doing anything. So you can kind of work and see what you're doing. The same thing goes for anything you do in your Gatsby repository. If you change something in your CSS files, it is rendered directly into... I don't know what to change right now, but let's change the background color. So I just changed the color. And then you can see how it's rebuilding the thing. Usually it shows it directly, but you can see all your changes you do live in your browser while you're working on it. It's kind of neat. And this is just one example of a framework. There's a lot of them out there. Any other questions? Or are we done? Perhaps you would like to add something to close this session? No, I just wanted to give a brief introduction into this topic. And if there are no questions, I think the concept is understood. I don't know. Well, I'm sure there's going to be a lot of questions when these people go and have a little bit of rest and try actually this. But I'm sure they will be able to find you. If they have any questions, then for the time being, thank you, Mario. This was a great session, and I hope you all enjoyed. Thank you.