 So, Suchi said, I'm going to be talking about static Drupal and what you can do to actually make your website static. You don't need to rebuild, you don't need to do any of this stuff. So just kind of some of the options that you'll have and some considerations that you'll need to make if you actually want to go the journey of decoupling from traditional serving architecture and moving towards a more GenStack architecture for how you're serving websites. We'll get into some definitions, we'll get into some, you know, use cases and things like that, but yeah, we'll kind of go through that. Introductions, I'm Steve. I'm a co-founder of Quant CDN. This is kind of, it's not a sales pitch for Quant CDN, but Quant CDN is a static hosting kind of Drupal integration business that we kind of started from a lot of these problems that we had with traditional Drupal hosting. We kind of moved over and were like, we don't need all of this stuff to serve most of our Drupal sites. We just need to serve the content. And in fact, most CDNs end up being a full static case anyway. So why bother going through a full, you know, hardcore origin set up when you can just serve static websites? A little bit of a plug here. So just in general, we kind of dog food the stuff that we build. So the Quant CDN website is actually using a lot of this architecture here. So it's a static, it's a Drupal site on the back end that has no public interface, you can't actually access it and it will push all of its content into the static store. And when you access Quant CDN.io, you'll just get, you know, the static representation of what that site is. Disclaimers, we're going to talk about a bunch of different technology in this. I've used some, not all of them, but it's kind of just a bit of, you know, here's what's in the industry at the moment, some things that you can look at, some things that you can go through and, you know, do your own research and validate things if you actually want to go down this path. And, you know, we'll talk about things like Netlify and, you know, Vue.js, different static site gens, things like that to kind of go through just some things that you might want to consider. In the presentation, we're going to go through some of this kind of information here. So why static? Why would you ever bother going through this? You know, you've got a Drupal site. It's working well. What are some of the wins and what are some of the cons of actually going through a static rebuild or a static kind of pivot from what you've got now? Some of the static technologies that you've got at your disposal to build static websites. So this can be, you know, from scratch or it can be bolting onto Drupal to make it work how you want it to. Some different architectures. So, you know, fully static, partially static, different ways that you can handle, you know, going down this journey as well. I'll kind of talk a bit about static Drupal, the Quant module and how that works and go through integrating into the, you know, the Quant backend or some other ways that you can use some other modules in the community that you can use for statifying your Drupal website. Hopefully we'll have time for questions, but if not, we can catch up outside and we can go through anything that you want, any questions that kind of come up throughout the presentation. So, let's get into it. Why static? What is it? Why use it? What are the pros and cons? We'll start with a little bit of a definition from Wikipedia, best place to get definitions. Static web pages. A web page is delivered to the user's web browser exactly as it's stored in contrast to dynamic web pages which are generated by a web application. I think that's kind of the key difference here is that when you've got a traditional Drupal website, any request to origin is going to make database calls, it's going to make case requests, it's going to do a whole lot of stuff in processing data from a user input to actually build out what that page is on the fly. And that's not as performant as, you know, just serving a HTML file that you've done that for already. Some use cases for static sites. So, static websites can be pretty useful in not just, you know, serving your whole website. Like that is one use case for them. But, you know, they can live alongside your current production website as well and there can be different ways that you can handle some static offload or, you know, if you need to. So, what's some of the stuff we've got here? Static archive is kind of one of the big reasons that we actually decided to build QuantCdN was that, you know, the government has a seven-year mandate that they need to keep revision history for what the website was. And there's no system at the moment that does it well. And so QuantStatic can kind of take snapshots, keep them over time and let you be able to do that. So what you can do is you can point the crawlers at your website, get a whole representation, keep moving through the years as you do that. So you've got that point-in-time reference of what the site was looking like. Disaster recovery, this is one that's actually kind of near and dear to my heart. So we've got, what we do is we kind of crawl websites, create static representations that have them that live alongside your production website. They're not, you know, up-to-the-minute, you know, replicas of what your production website is. Usually we run it like n minus one, say, day minus one kind of thing. So just kind of stand-by's in case a production incident happens and we can swap DNS and go straight to the static website to give you time to fix whatever causes your production problem. We've actually had to use this a few times with some of our clients as well, which has been super helpful, just takes pressure off all of the teams who are looking at figuring out what the actual problem is. They don't have web traffic coming in, muddling up logs and all that kind of stuff. They can get straight in and have a look at what the problem is and go through that process. The history's kind of just a piggyback off the first one. And then static front-end, which is the whole use case here, is you can actually kind of just decouple your Drupal back-end, have the front-end that's directed from a static store. Pros and cons. This is a pretty light list. There's plenty more here once you do diligence and have a look at it, but here's some of the high-level things that I like to talk about. Security, pretty self-explanatory that one. There's no dynamic systems. There's no way that someone can actually access anything important because it's just serving static HTML files to you. Performance. Same reason. You're just getting surf static HTML. There's no dynamic back-ends. There's nothing there to handle kind of that. So this kind of all ties into one thing. Performance is a big kind of umbrella for all of this stuff. If you've got performant HTML files that are being served, it's scalable. It's greener because you're hosting infrastructure footprint is lower, all that kind of stuff. Some of the cons. It's a little more complex, right? So you're running through it. You're working through just the many systems. You've got build tools. You've got crawlers. You've got, you know, save content, pushes, depending on what architecture you use. It makes your site more complicated for just general maintenance. Static. There's a funny one there because it's just a con. It's just a bit of a mind shift, which makes it a bit of a con in some use cases because you've got to kind of start using solutions for static to make it work well for you. We'll kind of go into some of these points here in a little bit in the next slides just to kind of go through it. So, you know, like, why is static sites more secure? There's nothing. There's no backend. There's no backend that's publicly accessible. So you can't hack a CMS if it doesn't exist. If it doesn't have a public interface, you can't talk to it. You know, you can put your Drupal site on a VPN or you can put it, you know, you can even host it offline and just have it locally and push your application into the cloud, be it with Tome or with the Quant module. There's no database to hack because, again, all this stuff is not publicly accessible. You can't do any of that stuff if it's not there. How can I be faster? Same thing, right? So it's kind of just building on top of all of the stuff before. You're just serving HTML files. There's no dynamic queries. You're not needing to query databases to build out representations or pages. There's no server-side processing. You're doing all that stuff prior. You can put it up front once, push it up and have it served as HTML from there. Same thing, right? So it scales better because you've got just static file store. It's just using file system IO then at that point to be able to scale outwards so you can then scale it to thousands of requests a second very easily because disk speed is much faster than database read and write speed. Things like that, right? And so just in general, once you can scale out that way, you can handle high-load traffic much better than you can with a database. How is it greener? So this is an interesting one. I did a little bit of research on this before to try and get some estimates on just general carbon usage for how much it would take to have a HHA Drupal website running. Don't have the numbers exactly right, but it's orders of magnitude less just to have an S3 bucket that can serve files when you request them. So less energy required to serve, less processing, because there's no dynamic access to it. Less data transfer because you've already done a lot of that bulk processing, those kinds of things. And this is just kind of where it ends up coming to business users. Because there's fewer pieces, there's fewer serving infrastructures. It's smaller, you've got a lower cost footprint as well. So you've got simpler hosting needs, lower resource consumption, easier maintenance because it's a static store, it's just a storage service somewhere. We're going to get into when would someone want to use a static site instead of a dynamic site? Here's just some general use cases, some things that we've kind of toyed up with when we're kind of coming through this stuff. So international audiences, and this is kind of offset a little bit by using a CDN to case your Drupal payload at the moment. So you'll have it served from edge locations to them. The problem with having a traditional CDN is you need an origin server that can handle some amount of traffic falling back through to the origin. If the CDN is either stale cache, cold cache, all of those kinds of things. So you still need to have some origin infrastructure to be able to handle higher load periods. If your website is just a brochure website, kind of those types of things, single page application type thing doesn't have dynamic pieces, it's just information. That's a best use case for a static site. Just kind of build it with Next, build it with a Jekyll, some static site generator, have markdown files that you don't need marketing teams to write it, they can give you the copy of those kinds of things. Get those going, push them up. Security focused, kind of touched on it before, but because there is no dynamic area, there's no way if someone can hack it. So if you've got a website that doesn't have a lot of dynamic functionality, doesn't have a lot of moving pieces, you can lock it down even further by not allowing any kind of front ingress into your website, into the dynamic back end, whatever that is. And we kind of touched on that one before. Static technologies, let's get into some things that you can use to build out different websites. So when we're talking about static technology stack, we kind of break it down to a few different areas. So there's the content source. Where is your data coming from? Is it coming from flat files? Is it coming from databases? What kind of methods can you use to get the static representation from wherever it's stored into a static host that can then serve it out as it needs to. So there's plenty of different ways that you can do that. Some of them are, you can use a scraper or a crawler to kind of snapshot what the browser will see, push that up. You can use a static site generator, to build out template files and push that up. You can use Drupal modules so they can handle rendering. You don't even need to change your current workflows. You can just build a Drupal thing. Use technology that you're currently familiar with and then have it render a static representation of what that site is and then push that somewhere to be hosted. And then the last thing to think about in your static technology stack is where are you going to host it? Is it going to be Azure Blob Storage? Is it going to be Netlify? Is it going to be Coincidian? There's plenty of places that you can host it. Plenty of places give you different functionality sets. Plenty of places take things on for you, give you power to do it yourself. If you're hosting an S3 directly, you might need CloudFront to serve from S3. You might want to use lenders to do certain edge things, things like that. If you use CloudFront pages or Cloudflare pages, they've got different things. They've all got roughly the same technology that you can manage if you want to do microservice with the static site as well. Plenty of different options that you can use to look at doing that. We're going to run through just some high-level sources and each point on that last slide we'll go through just some general stuff here. The content sources, as I was mentioning before, there's plenty of different ways that you can decide to author content for your static website. You can use data files to manage your markdown. You can manage that way. You can give editors access to a GitHub repo, for example, and they can create content directly with markdown files in the Git interface. Or you can go through and you can make an API back end. This is what Dries was touching on this morning with Web Services and decoupled Drupal instances for example. You can have a Drupal instance that's locked down that serves a content API that your front can read from and build out to users. The next thing that we can look at is how do we get that representation of what the static website is to a static service and a host. We'll either use crawlers or we'll push. It'll either be like a GitHub CI CD pipeline, which we'll talk about in the next one, site generators versus crawlers. These are kind of two high-level approaches for how you get your static content from wherever you're building it with. Drupal site can be crawled if it's publicly accessible or if it's not right. You can give the crawler access to it either via VPN or basic auth or whatever you want to do to do it that way. Some crawlers that can help with this kind of stuff. They're scrappy, simple crawler. Quant also has a crawler as well, so if you want it to sign up and have a look, you can build a crawler out and send it at your site. They all use different technology under the hood, so they all kind of scrape and crawl slightly differently, whether they're using Selenium and stuff like that to render webpages or if they're just scraping markup and doing that. They're all slightly different, so it's hard to choose which one's best. It's kind of evaluate each tool for its own merit and then go through that stuff to figure out which one would work better for your use case. Static site generators are much the same. It's kind of exploded over the last year and a bit. Just how many different frontend generators there are that you can use. Here's some to name a few. If you have a look, I think Netlify has a list of 64,000 or something, just different static site generators for every type of language, every flavor, especially in the Node.js space. I think everybody's first thing to do is create a framework from a framework and go through that process. You can use things like Next, Go, Hugo, if you've got a Go Development house, you can just use so many. Pick one that you feel comfortable with or that you think is fun. They all do the same thing, really. They all have different levels of integration into a CMS, so this is probably one thing that you want to consider when you're choosing a static site generator. What's the community like? How have they integrated with different APIs? Things like Gatsby has pretty good Drupal integration. If you're going to manage a Drupal site and expose content via a Web API, something like Gatsby might get you that bit there and it's just building a frontend at that point. You don't need to worry about abstracting APIs and working on integrations that way. Things like Drugs, there's a pretty good... So it uses Nuxed and then they built Drugs on top of it, which is a bunch of connectors into simple REST modules, what it outputs in Drupal. So there's plenty of places that you can use to look at that. And then there's some other things that you can look at that kind of work slightly differently. The front... Right? The right side is backwards. So your Nux, your Hugo, your Gatsby, your Jekylls, all those kind of tools kind of want you to rebuild your website with them. They've got templating engines. You've got to manage CSS, you've got to manage rebuilding your Drupal theme essentially in those languages. So Gatsby's Node, Next.js is Node, Hugo's Go, Jekylls for Ruby, all those kinds of things. So it is a little bit of upfront kind of investment if you want to move on this path. Then you come to like Quant and Tome, and they have Drupal integration. So Tome you might be familiar with is a Drupal module that can create a static representation of your website. And Quant has a similar module that does a similar thing. They work slightly differently in that Tome will create an archive. It will go through make HTTP requests to all of your website and then give you a zip file at the end of it and say, Hugo, go do something with this. This is yours now. The way the Quant module is a little more tailored into Quant's hosting offering. So you enable the Quant module and it will push your static content straight up, ready for you to serve. Just a bunch of different things that you can use to analyze and help go through this static journey because it's pretty fun once you get into it. We kind of mentioned static hosting before, but here's a bunch. There's even more than this. This is just a subset of where you can host websites. You can spin up EC2, you can use GoDaddy, you can use whatever you need. Because at the end of the day, your static website is just HTML pages and most hosting providers can do that pretty well. There is a bunch of these that do have Drupal integrations, so they can kind of work slightly differently. S3 has Drupal integrations, so you can push up Drupal files to S3 directly so you don't have to worry about that kind of thing. You can tailor your workflow and your CI CD pipeline to scrape and crawl the web content and have files pushed directly to S3. You can kind of work on that, depending on how you want to manage a static website. Then you get how pages is actually probably one of the lowest barriers, right? If you use Jekyll and GitHub pages, you can create a static website really, really simply. Now we're going to get into some a little bit more technical stuff. I'll still keep a pretty high level just to introduce the topic of static and just how you might not have to start thinking about different problems when you're working through this stuff. When I think about it, we have generally two different ways to do static, and you have a fully static site which is completely decoupled from any back ends. You potentially integrate with other services to provide form submissions and things like that if you want to do that. For example, you can create something that integrates with SendGrid if you need to send emails from your static website, rather than having a mail server and doing all that stuff yourself. You create a small form that does a submission directly and you can do all that client side or you can have a microservice to handle that. The other architecture that we've kind of started to look at is partially static. This kind of relies on your CDN or where you're serving from to be able to support some of this stuff. What effectively you do is you create your static website, you push up your static assets into the static hosting environment, but then you proxy paths back to your, for example, Drupal website. Say you build web forms and you want to have Drupal handle web form submissions, what you do is you can then proxy the Drupal web form submission URL back to your origin server and you can lock that down and say put a WAF on it, only allow BasicOr to make that request. You can do all of that kind of stuff. Now I'm panicking. Proxies is how you can kind of do partially decoupled. We've seen some pretty good examples of that. We have a bunch of clients that kind of manage that now where they push all of their web form submissions back into Drupal and manage all of that because they've got legacy process internally where their content editors know how to manage the web form submissions. They know what data they're collecting they know how to do that. So they didn't want to change everything too much, but they wanted to reduce their footprint on how they can serve and manage and it sees in all that kind of stuff with the things that static kind of really talks about. I don't think we really touched on pros and cons of a crawler, but we'll kind of go that here. One of the ways to get... So these two things here, right? So this is how you get your content from wherever it is and push it into the static hosting environment. So either crawling or using a static site generator with CI pipeline that does a build and pushes it up. So in this case, pros and cons of a crawler is it's really simple, right? Depending on your frontend, depending on how complicated your frontend is, it might results might vary, but it's much more simple than re-architecting your entire site in a different language. Crawlers will not need back-end access. They can just talk... They will basically be an anonymous user against your website. Take all of the web content. They can wait for JavaScript and in kind of event-driven stuff that you've already got in your Drupal theme, for example. Get that representation, create the HTML file, push it up into the hosting environment. So super simple to set up, very easy to go through. My leads may vary on different crawlers based on what technology they're using under the hood. One of the downside is it doesn't change when content changes. So you would have to schedule crawls, for example, or do something like that. I might remember if I can digress a little bit. Back in the early 2000s, we used to use web sphere and there was a compile stage that we had to go through as developers. Content team would write a new file and we'd have to go in and run a build and push it up to the server. So using a crawler kind of brings back some of that kind of technology. It's not good or bad, but it's just a consideration that you'd have to manage different publishing workflows if you go through the crawlers. I'd say crawlers are more beneficial if the site doesn't change very often. So if you've kind of got a content website that just sits there and doesn't need to do anything, we can reduce our hosting cost by making it static and serving from a static store. We can crawl at once maybe every couple of months or something. It might change and we need to update it. But that goes through that. On the other hand, we've got the static site generators. They're more complex because you might have to rebuild your frontend. Unless you use something like Tome or the Quant module, generally, if you're going through an evaluation process, validating what you need to do to rebuild your frontend, if you're going to go through a site redesign, it might be time to go through that and evaluate the different frontend technologies that are available to be able to kind of adapt to the changing market of frontend experiences and things like that. You can do some pretty cool stuff with the JavaScript libraries. It's more complex in that you need to have a mechanism that will push that static generation into your static host. That's when you look at things like GitHub Actions or SCICD provider that can do that stuff for you. They'll run a build in the pipeline and then they'll push the result to your host. Unless you use things like Netlify or the Quant module, which they can react to content change directly and handle that push for you based on what your editors are doing in Drupal rather than having to have a separate process to manage deployments. We've probably gone through this in a high level when I've been talking about all the other stuff because it's all pretty interconnected. As I mentioned before, static Drupal is really good if your site doesn't change content a lot, doesn't have a lot of dynamic features on it and things like that. If you're in that kind of category, you can scrape and upload, keep those sites and reduce your hosting footprint by having those available as static serving versions of those websites. That's not for me, is it? Here's some just examples of what it might look like. This is probably not the best example, it's just WGet, but I don't know who would do a crawler with WGet. That seems a little silly to me. If you want, you can use WGet and just put the markup somewhere because there's plenty more complicated things that you could do with Selenium and actually render JavaScript, have it react to what the user's doing, do it all that kind of stuff, which is a much better way. We've got an example here of what the QuantaCrawler can do, so it uses Selenium under the hood. It will actually render the JavaScript on your page and do all that kind of stuff as well. Yeah. Now, Suji's making me scared again. When you're talking about syncing and crawling, you've got these kind of questions to answer. How often are you going to upload changes? What's going to... How are you going to manage the change with your publishing teams and things like that? And when you think about like a SAS crawler, you can schedule those things so you can do that. You can kind of just work through those kind of those abilities there just depending on what your needs are. So we kind of touched on this as well, but you see here, so this is generally when you want to talk static with Drupal, it's using Tome. It's a pretty good module for just generating a static dump of what your site is. And then there's the Quant module, which kind of piggybacks off some of the stuff that Tome does, but then pushes it directly to a host for you. So here's, if you want to run through how you would do a deployment with Quant, you know, you create a Quant account, you enable it, you configure it with the configuration options that Quant will give you. And then you just kind of run two Drush commands. You see your queue, you run seed queue, which creates, you know, background worker jobs for all the content that's in your website. Then you run queue, which will have some concurrent processing of that, and that will handle running, you know, Selenium in the background and kind of doing what it needs to do to get the data up. And then with Netlify and Tome, if you're going to use that to handle be your static host, you run Tome Generate, you install the modules, you run Tome Generate, and then you get that output and do a Netlify deploy. But that needs to be a manual task that you run afterwards. You can automate those stuff, you can run Chrono if you need to, but still manual to do that deployment. When we talk about these two modules for Drupal syndication into your static host, Quant will generate the seed, you initially generate a seed and that will be like the initial output of all of the current state of what your Drupal is, and then the Quant module will track change as it happens. So as it changes a file or changes a node, sorry, your Quant will re-queue that asset and all related assets and then handle a push back on Chrono whenever you've got that configured. And then with Netlify you've got to generate that, the static output and then do the deploy every time. I think I made it. Did I make it? I don't know how much time we have left. Oh, we've got two minutes. Yeah, do we have any questions? I kind of went through that pretty quickly. So it's debatable, right? As most things are with the Internet, but generally the rule of thumb is even if you've got a 99% cache offload, you still need to have an origin server available. In case something's not cached and the web request needs somewhere to go. With static site you kind of think you reverse the paradigm, right? So a traditional host has a push. I might use my hands. So it's a pull mechanism with a traditional CDN. So you go through, the CDN will make the request origin. It'll do all of its request coalescing at the top and whatever it needs to do to handle distributing that load. It still needs to talk to your origin to be able to generate that output. Where in static sites you've done that process up front and you've pushed that result in, so it never needs to talk to it again. And so it can handle that at scale, and if you need to change something, you can push it straight in, rather than having your back end manage it that way. So it's just slightly changing the paradigm there, so it's not kind of directly pulling from origin. You can turn origin off, you can do it with static. Where do you can't do that with a traditional dynamic back end? I'm going to say no. I haven't done it with that many pages before, but it would just take time. It would just be a time thing for you then. So some of the static sites I've seen are up to like tens of thousands, so it's pretty high. And it's just kind of, depending on which method you use to generate and push, most static site generators handle building deltas. And so you keep a list of things that have been built already, and then you kind of just build the change each time. So the initial seed and the initial kind of deployment of your static site will be slow if you've got 100,000 pages. But then after that it should be much faster because you're kind of only doing what changes or what needs to be pushed after that point. Yeah, I mean that comes down to browser performance more than anything, right? Like, so it depends on how complicated your front-end application is. What it would be is that the static site would be served to your end user much faster and then all of the front-end processing would happen there. So it depends on what that front-end app is doing. But yeah, there's... So the initial payload of the HTML body is fast, then your application is as fast as it is, depending on what it's doing. That's not a really good answer, but I don't have a better one. I haven't used static site generator, so my disclaimer at the beginning, I haven't used them all. But I imagine static site generator is like Tome. And so it would work in a similar way where you have to generate the static output and then do a deployment where Quant is tracking change in Drupal as it goes and does the deployment for you as things change. So very slight difference. Cool?