 Hi, everyone. Thanks for coming along to our session this afternoon, our showcase on Sector Plus Gatsby taking a distribution decoupled. And I'm introducing Marco and Gareth from the Sparks interactive team talking about Sector. If you'd like to know a little bit more about Sector as a distribution, we do have a sponsor showcase session coming up later in the day. Ask questions about that. But I will hand it over to Marco and Gareth now to take you through the presentation. Hello, everyone. Welcome to the Sector and Gatsby LS Drupal. So let me introduce myself. My name is Marco and I'm a Drupal developer and CIS admin in Sparks interactive. And I've been working with Drupal for the last 10 years. And with me today for this presentation, there is a great content developer and colleague. So let me introduce Gareth Pohl. Not my words. Okay, let's start. So I'm pretty sure you heard already about Headless, the couple Drupal. So just in case, let me refresh what Headless, the couple Drupal is. So essentially, LS Drupal is a website or web application where the backend part is made in Drupal and the front end is made with a different technology. So to be more precise, the backend use Drupal for the content management and the content as a content repository too, and serve the contents only through REST web services. And of course, the front end is an application consuming the contents from the Drupal backend as an API REST endpoint. But today, we are talking about a little extra on top of this standard couple Drupal. So as you can see here, in this slide, we have an extra layer between the Drupal backend and the front end. So the little extra layer is Gatsby. So sorry, I'm a bit emotional here. So in this scenario, Gatsby is consuming the... So in this application, sorry, in the solution, we still have Drupal as a content management and is serving the, as the previous serving the content as a REST API endpoint. But the application, in this case, who is consuming the content is Gatsby and not straight the front end application. Gatsby essentially consumes all content and generates a static version of the front end or site or web application and deploys it as a static site or web application. So our final front end site is literally a static site made of HTML, CSS, JavaScript, and of course, all assets. But of course, if necessary, the front end can still interact with the third party APIs, but also interact with the back end. For example, if the front end has to submit a web form is able to interact with the back end through the REST API. So why Gatsby-L is Drupal then? Okay, so there are many reasons, but I'm trying to summarize here the most important one. So the first one, our site, our essentially content repository at this point, can be consumed by more content, by more application. Of course, a front end website, but can be consumed by a mobile application and many others. And so our Drupal is just an API endpoint and can be consumed from different and various new forms of media and this enants the flexibility. And also another important point is the diversification of the teams. Before everything was made in Drupal, which is fantastic still, but in this way, you can have a differentiation between who take care of the back end and who is building the front end, give them more flexibility and not necessarily they should know about Drupal Twig and all the Drupal template system and things. And of course, very important here, and I want to stress on this one, security performances and search engine optimization. Because the site is static, you are serving a static website, you are exposing your site as a static website. This increase a lot the performances, essentially Gatsby is fantastic in creating a static version of your website where all the pages are an HTML file and all assets are optimized to be rendered perfectly and super fast. You don't have any query on database, you don't have any rendering or processing. Everything is a pure HTTP request to HTML and assets. And this increase a lot the performances. And as I said, security. So you can literally, if you don't have any interaction back from your front end to the back end, you can literally turn off your Drupal and leave your static website over there. And it's almost impossible to be attacked because there is no PHP, nothing there, which is very, very secure. Also, another problem about the coupled Drupal solution in the past, we notice search engine are not very happy because if you have an old style Drupal and you have a front end made by a single page application, thank you for this. And sometimes your search engine is not interpreting and executing the JavaScript, so it's not able to fetch all the content from your website. But having a static website, you have a very user friend, actually, robot, a crawler friendly site and it's very easy to fetch any single piece of content. And to finish, this is a good alternative to other solutions like just let me say one like Contentful, where you have exactly this situation where you are separating the content management from the front end. But this one is open source and Drupal. So you can provide a friendly back end and a friendly solution for content managing and give this freedom to the front end developers to build their own. I'm never quite sure when from Temple are going to get rid of the free plan. So, you know, open source is quite a big advantage for us. Yeah, especially economically. Okay, so let's pass the stage to Gareth. So I thought I'd talk a little bit about the original motivation of why we actually did this in the first place. And it was around two or three years ago now. I was building a few applications for one of our clients in an environment which was Salesforce. Now, because some of the data was quite sensitive, I didn't have any access to actually do any HTML, do any CSS, I had to build it separately. But then I had to help an integrator, which was a pain. And I thought, well, why can't I just have some access to this system and build the DOM on the fly and plug in the CSS, plug in the JavaScript. That's basically what React does out of the box. So the company had a rebrand, they had a new style guide. So I built a whole bunch of these components using Storybook. I built them in React. So a lot of these components had different states and different complexities. And so I thought, you know, React's a good way to do this because I could change something on my end and it would appear in Salesforce where they have all the access. So it was pretty ideal. And of course, a few months later, they wanted to upgrade their D7 site to Drupal 8. And I just created this beautiful style guide, this beautiful UI kit in Storybook. All in React. And I didn't really want to do that in Twig. And our typical, our usual Drupal theming procedure. So I kind of started looking around for alternatives. And we landed on Gatsby. So what is Gatsby? I think Marco probably covered it quite well, but from a front-end perspective, Gatsby is a static site generator, SSG. There's quite a few of them around. There's Next.js. There's Jekyll. There's Hugo. There's more and more coming out every week. Gatsby is based on React, which is great for component-driven architectures, which is what we want to be doing. And so Gatsby pulls data from at build time when you build a Gatsby site. It pulls data from APIs. It could be Drupal. It could be Contentful. It could be WordPress. It could be Shopify. It could be Spotify. You can have a plug-in for it. It pulls all this data, puts it into one GraphQL API, which front-end developers can then query and pick out the bits that they want and build interfaces and components from that. Gatsby generates static HTML markers, CSS and JavaScript. We're not shipping React to the client. We're using Gatsby. We're using Node.js to turn React into HTML and CSS JavaScript. And why do we choose Gatsby? In a slide, compatibility with Drupal. And this is the key, really. There's plenty of cool frameworks like Next.js is really cool at the moment. But this source plug-in, these source plug-ins is what you use to plug your data into Gatsby. And this makes it super easy just to I'll show you. Okay. So in our Gatsby config, we just give Gatsby a Drupal URL. And we give it it uses the JSON API, the core JSON API endpoint of Drupal. And you can pass it in some header parameters like API key or you can pass in basic auth information, which is what we do typically to go to Drupal, grab all the information from the API and then build it into a GraphQL model. And this is kind of what this looks like. So if you look on the left-hand side, you can see we've got our pages, our articles, promotions, resources. We've even got NCQs up there. We've got all our media. And we run these queries. So I can just, you can see this. I grab the tile, the Node ID, the body, run the query, I get all the information. I grab this query and paste it into my Gatsby code. And I've got everything that I need. Pretty good. So performance, as Marco said, is a big part of why we chose Gatsby. Gatsby makes it incredibly easy for me to build a site with Lighthouse scores like this. It really makes meeting our performance budgets a low effort task, which is what we all want for our users. We're not making any database requests from our websites. We don't need to worry about PHP versions or PHP speed. If there's a row script, which has gone haywire, server performance, what patching modules are installed, what version of ImageMagix there, or things like load balancing. I don't need to worry about anything. I'm a front-end developer. I don't want to have to worry about those things. Gatsby Out of the Box gives us some pretty cool things like modern media formats like AVIF, which is a new image format, which is really, really quite good. It reduces the typical JPEG by 25%. WebP, which is another is 15%, 20%. AV1, which is a new video format and high efficiency video codec, I think that one is. You get all these things out free out of the box. Data pre-fetching, which is really cool. We're Gatsby. Basically, all your links on the page, as your links scroll into the viewport, it will go and grab the link. Those webpages, the data, the gradual data from those in case you want to use it. When you're clicking around, it feels super fast. It's pretty cool. Security is a big one. It's complete static, so we don't have any slash user. There's no attack vectors that you can't start running SQL commands with a query string, or select star, or anything like that. No brute force, no injections, nothing. Yeah. Aesthetic. Yeah. What we can do with our Drupal CMS is we can block them down with things like basic org. We can IP restrict them. For further the year, which is a competition, a pretty big competition. It's once a year, and they don't make any changes to the site for most of the year. We can turn that server off, and the front end just stays. Yeah. Front end stays static with the Drupal golf. It stays there and just serves the site. In case they want to change something, just turn on the back end and then make the changes and boom, deploy them. So it's really good for when critical upgrades come out, we don't have to rush to update these sites because they're all behind these balance. Yeah. You don't care about patches or something, because just... We do care, but we're not getting up at 4 a.m. to do it. Let's say don't care, not don't care in that way, but you are not critically affected by the scripting vulnerabilities on the database of PHP or Drupal modules or something, or they find out something on PHP Drupal components, and there is no Drupal there. Drupal is just the CMS and it's offline, and you are presenting to the world just a static HTML standard host. So it's more secure essentially in performance, as we say. Okay. Hiring front end talent. So Gatsby kind of changes the game a little bit in that hiring devs is pretty hard. Hiring Drupal devs is even harder. So by using Gatsby, we're opening up the hiring pool to developers who don't need to be familiar with things like site building or theming in Drupal, with all its esoteric is the word. They don't have to be familiar with things like display suite or twig or things like this. We can hire developers fresh out of university, have just done a course on React, and we can pretty much get them up and running quite quickly. And as long as they can query for it in GraphQL, developers don't really need to know where the data is coming from, which for me is great. Yeah, it is. And issues are more clearly defined as back-end and front-end issues. So if something's going wrong with the front-end, Marco can point finger at me. Yeah. And if I'm not getting the JSON at the end point that I want, I can point the finger at you. Yeah. Dividing responsibilities is another point. Now, we can be responsible to provide a good API endpoint or provide a good dataset. And the front-end is just responsible to make it working on the front end. There is no more this continuous interaction between Dev and front where every time there is... I'm not worried about clearing caches anymore. Why is this not working? Yeah. Developer experience, just a few words on how it is working with Gatsby. So out of the box it gives you a local server environment with hot reloading out of the box. It's really, really simple. It puts your website on port 8000 and you're up and away. It ships with GraphQL, which is that interface that I showed you before, which makes it easy to learn how to use GraphQL and it just really helps you out with coming and building your queries. Once you've built a query that works, you just copy it and put it into your code. It's great. Git branch deploys is something that we're actually looking at quite a bit more at the moment. On your front-end, you check out a feature branch called Easter Egg. You push that branch up to your repository and our CI can build a subdomain called your feature branch.client.code.nz or whatever. Of course, the developer efficiency equals project efficiency equals happy clients. Did I leave an emoji in there? We know where we're leading. Okay. Some of the things that we do use on top of Sector to make this happen for us is paragraphs. It's pretty good at one-to-one relationship between a paragraph called card and your storybook component called card. So clients can refer to the storybook at a paragraph and they know what it's going to look like. It's just, yeah, a lot of paragraphs actually. KeyAuth is a module which allows you to protect things with API keys or you can identify content on Drupal based off the user's API key. So we can serve up different stuff to different users. A REST UI is just a front-end interface to the REST system in the core of Drupal. WebformREST allows us to post webforms, get the webform fields. Sometimes I like to get the fields from Drupal and build a React form from them, which just worked out pretty well. And we actually use WebformREST for bird of the year. So all the votes actually push to WebformREST via a Cloudflare worker, which I like Cloudflare. REST menu items, it just gives you a JSON tree of your menu so I can build navigations from JSON. Build hooks is probably the most important if you want to take it from there. Yeah, all of this and now make sense maybe if I give you a little bit more example. So the building hooks is another module, Drupal module, which allows you to detect changes in Drupal and also to trigger these through a webbook external URL and something. And this something is a deployment. So let's see what I need to do that. So to do that apart of those modules, Gerst just explained, we need a CDCI pipeline where, for example, we are using GitLab because we are using GitLab also for other things and we found out they have this CDCI part where you can literally create your building mechanism and your pipeline of mechanism. But you can use any of those or even more automation to build and run your Gaspi and make Gaspi working for you to create the static site. So in case of GitLab, we are using GitLab runners. These GitLab runners in our case are Docker container. GitLab provides for you a Docker image where this Docker image is there listening through a reverse port and a secure connection. And when you hit through the web hook we mentioned before, so when your Drupal website is ready to deploy your content changes and so rebuild your static site is hitting GitLab. And actually, I'll show you. So I have this little example. I forgot I have this video but I'll show you. So you make your changes on your content. Oops. Sorry. I don't know how to stop it. You make your changes on your piece of content. This is a standard page in sector. So you make your changes. You save your node entity. Then on the top you can see get detected. There is a change. And then you click this. This is the web hook. And this tells to GitLab to do rebuild the static site. GitLab now is very accelerated but GitLab is downloading, of course, Node.js and also in this container and also, of course, Gatsby. Then Gatsby is fetching all the contents from the Drupal. It's generating all the image styles, all the HTML pages and everything. And in a blink of an eye, not really but almost, is our sync to the final destination. And this made your static site. So essentially, the web hook I mentioned before was to let your site send the information to, in our case, GitLab. And GitLab is using this runner to which are Docker containers, essentially, where is all the time, each time you're deploying, downloading Node.js and then Gatsby and tell Gatsby to fetch your, add all content from your site. Seems crazy but it's like that in the modern day, virtualization makes these things happen and it's so cool. So you want to take this? Yes, sure. So as Marcus said, that particular project would ask sync the build files to an engine X server, I think. But there are other ways of doing this. You can use things like, because everything's static, these are just files, you can put them on a CDN like cloud pages, Netlify as your AWS Google Cloud. And it's good having your content at the edge because people in London are going to get a European copy of your website, people in Australia are going to get an Australian copy of your website and with Cloudflare and Netlify, they do all your cache and validation for you and it's really just crazy easy. And of course you get the performance benefits of being on a CDN and security. Yeah, exactly. So we're looking to look a bit more into this next year and start moving our static sites over to the edge. Essentially, your site will be double cached because essentially it's already static and pre-compiled by Gatsby, but also you are serving it, you can serve it in a standard, you know, patch engine X web server, but also straight from there your target point can be also straight to a CDN by passing at all, even ideally or actually possibly. You can also cut out your web server, the hosting and literally host your end point, your front end straight to a CDN or one of these services. And all these services cost $0.00. It's crazy. Yeah, so not really zero but cheap. You pay for your build minutes rather than the actual hosting. Yeah. So let's go ahead. Other considerations. So when you use Gatsby and LSDrupal solution, you need to consider this solution might not be applicable for any situation. This is working well when you have clear ideas in the structure of your website and where everything is pre-decide in terms of how many content types and fields you have and is clear the dynamic and the structure of your website or web application. So if you have this, it works perfectly because everything is smooth and there is a very good outcome of this. It might be a little bit more complicated if your website or application is in continuously change like you have new content types all the time, a lot of changes on the fields or things like that might be a little bit more complicated but not impossible. But at that point it might be probably will be more convenient to use the normal Drupal solution and then as soon as you get something in a new field or something, it will appear directly. Another thing is just to wrap a little bit. Why choose a sector as the couple Drupal? There are no reasons to particular to use sector. You can use the couple Drupal with any even with a vanilla Drupal but because we are talking about giving to the final user a good content management experience, sector is a Drupal distribution which is very friendly for the content management point of view and this for us was helpful to start with something there where who does content management is more helped in doing this process. So yeah, we always use sector to do the couple Drupal solutions but you're free to use any Drupal or a vanilla Drupal. So what's next? 10 minutes so you should probably look at questions. Actually, just before we do, if you want to learn some more, there's some good links here that this video on YouTube is about an hour long and it's very good at selling this idea of using Gatsby and it's actually very Drupal focused as well. So I encourage everyone who's interested to watch that because it is very good. Yeah, it's a very good video and I had the past to have a look. Shall we look at the questions? All right. Yeah, so if there's anyone out there in the audience, oh yeah, here comes one from Lee. So that's a good question. How does she go with content editor features like preview etc? So preview can be a bit of a problem because we have to kind of educate our clients that these things have to be built and it can take up to five minutes or so. Gatsby do have a commercial product which is called CMS Previews which has a plugin for Drupal as well. You basically click on the button Drupal which says see preview and it sends you to a Gatsby.io URL with your site which is live updating as you save your content. But as I say, it's a product that Gatsby doesn't do out of the box. It's a commercial product I believe. I've used it. It's very good. It's quite creepy how good it works. And yeah, I mean if you have a site which has multi-stage content approval review and it's been updated by a bunch of authors all the time, this might not be the best solution for you. But for a lot of clients who don't really touch their sites every day and with projects which are very front-end heavy, have an application built in, this is a good solution for it. And if you just want data from your source, just it's a really good solution for it. I want to add a little thing to this. You can choose the destination of the deployment through the webbook. And you can literally deploy your, let's say preview or your testing site in a different target. So you can preview essentially if you're happy with all your changes you can switch and say I want to deploy to the UAT version of the website and Gatsby will build and deploy over there. So you are free to navigate all your changes to share for proof reading and something like that. And when you are ready you can just choose a deploy to production and Gatsby will deploy over there. So essentially it's just in waiting time probably of saving and refresh compared to waiting three minutes. The last website we're building three minutes. And that was Bird of the Year which has tons of images and it creates different versions of those images all in three minutes. It's a different approach just to education. Actually no it's one of the sponsors of Buildhooks has just left a comment which is pretty cool. We're kind of looking to extend Buildhooks to support GitLab with their API so we can actually show our clients when things are being built through the GitLab API which is pretty cool. Nice just a question there from Jonathan. Have you tried Gatsby cloud? Yeah yeah yeah I like it. Quite an impressive product yeah I've actually done a one-on-one with one of the sales guys about what they could do for our use case. I'm not sure how they switch on some magic cloud things with a product but they manage to get build times down to under a minute sometimes which I don't know how they do that and they do the whole branch deploy thing as well so you push a branch and it deploys to that branch dot your site. I like it. I think I do prefer it to Netlify but I do like what Cloudflow are doing at the moment as well. How big of a build have we done or have you done Rala? Sorry. How big of a build I mean how many pages for a large content site is the build time prohibited? Not so much it really depends on how much images are because that's where the CPU is used creating different but because we create an avith version a webp version of JPEG version while the images are different sizes so it's all responsive. It's more about your media than the page number but I guess if you're getting into over a few thousand pages you might start to notice some problems but actually Gatsby have just a month ago launched Gatsby 4 which has deferred static build so if you host with them or Netlify if you go to a page which was created two years ago no one's been on it it doesn't build that page at build time it'll build it when someone visits it visits it so you can pick and choose your most fresh content to build at build time and then have the other content build on the fly when people actually visit. Yeah so they give you some options for only building what's been changed yeah yeah yeah cool another question from Lee um are we using caches from previous build to speed up deploys on GitLab? Yes so we'll patch the node modules and various other caches as well so it's a nice mature priority ecosystem that's really dealing with those issues those key issues around speed. Yeah yeah I'd say so yeah and just a couple more minutes left a question for you on a philosophical standpoint where do you stand on the on the the question of decoupled all the things? Do you agree? Do you have different views? I think would you ever go for a full decoupled all the time? I I have the impression but it's just a personal opinion so don't take me wrong here I have a I think Drupal should consider this approach because it's a trend out there and and can to improve the strength of Drupal we should follow this flexibility so and allow Drupal to be used as a pure content management not as a complete system essentially I'm not saying Drupal should give a specific decoupled version but it's something we should accept and go through this process and if we follow this Drupal will shine still shining otherwise if we stuck in imposing the old style Drupal probably might be you know someone might not choose anymore because it's too you know but it's working so far as adapting perfectly and I'm so happy about that. As a front end developer I just find myself and building things faster and of better standard as well I'll say yeah that's one thanks for that one minute left any last minute questions from the audience get your orders in get your orders in any final comments from either you Marco or Gareth in the minute we have left that youtube link that I shared in this question is quite it's very good you should all go watch that I think I want to say something else even it's not really related to CASP but give a try to sector because independently if you are using sector as a decoupled solution there's also a good solution out of the box and it's good not just for this purpose but for many others but I like it. Yeah I think in the next year or so we're going to do some more with sector to make it even more approachable with this approach whether it's sector headless or yeah maybe whether we branch off or not we're not sure yet but I think in the next year we want to do more of this sort of work and yeah clients want fast websites and that's what we want to give them. That's one awesome thanks very much for that team if anyone's got any questions hit Marco or Gareth up in the channel and we'll see you out there