Wagtail architecture options, or should I go headless - Dan Braghis

Speaker 1: All right, um hi everyone. Uh my name is Dan and uh I work for Torchbox and I want want to talk to you about wagtail architecture options. So this talk will be less technical than you'd expect and it's kind of geared more towards decision makers in companies, but also hopefully you know uh uh there will be little bits of uh little information nuggets that you can take away. I try. Uh I guess we'll have to go with this. Uh Let's see. Okay. So uh who am I? I'm a technical architect at TorchBox.

Speaker 1: Uh what does that mean? Uh that means I help lead on projects on on big projects and also you know, make the tough decisions on architecture, but also enable people sometimes a a lot smarter than me to to do their job properly. I'm also a Wagtail core developer and I've been involved with Wagtail for from quite early on. I started by taking meeting notes and Publishing blog posts. So some of the earliest blog posts on wagdale. org are essentially meeting notes from me. And I must have been doing something right because uh I got accepted. in the in the in the core meeting. And also I I I'm a m maintainer for a number of packages like uh Wagtail Media, Wagtail Headless Preview, Wagtail Grapple,

Speaker 1: and a handful of others. So yeah, so what it is this talk about? There we go. So uh this talk is about lots of acronyms, acronyms like uh SSR, SSG, SPA, ISR. and so on and hopefully uh less uh bad animations on slides. Um so yeah so um let's take it one by one uh yeah know SSR what is a SSR that is uh when we talk so I try to distill architecture options into like three main main categories. There are more that sit in between,

Speaker 1: but I won't focus on these. So SSR, server-side rendering, and uh this is you know the the good old boring technology that we all know and it really it's the simplest um model everyone does it it's battle tested it works right and what's really good about it it uh handles uh every uh kind of use case because it has had so much uh so much uh run. Now uh next up we have um spas, right? Single page uh applications. Now when I talk about SPAs, I kind of include

Speaker 1: uh all of all of the modern frameworks uh like NUX Next. js, Gatsby, and so on. And it's a bit of a stretch because they're kind of evolved from the that concept of a you know single page application where everything is happens into this one little little page. Um but uh you know doing star uh star page applications or dynamic page applications doesn't quite have that uh ring to it. So I'm I'm gonna refer to to SP to to to that kind of uh frameworks or approach. as SPAs. So like what what is behind it? Well uh you have a back end in this case well Wagtail that provides an API

Speaker 1: and then you have a front end that consumes that API and renders uh your components, it uh renders full pages and uh provides interaction um uh for for for your side. So where where are single applications good? Well you know you can tap into a wider developer community So there all the JavaScript uh led stuff is quite uh hot, you know, right now. Everyone does it. Everyone like likes it. So you can increase the the pool of developers can can that can do it. There's also like a quite rich ecosystem behind it which which helps. So you can have nice slick uh

Speaker 1: interfaces and you can have uh smooth transitions, uh faster page reloads, also more dynamic uh applications. or or websites. And it also taps into this concept of cope or create once publish everywhere. And the idea that you have a single source of truth that is your backend that provides the API and then everything else can be you know your uh website um your application your uh publishing feed whatever it is. And that works quite well for uh for big publishers. Now to continue on on this, you know, I talked about uh modern frameworks like nuxt and next and and so on

Speaker 1: so uh these applications can be um rendered on the client side meaning everything all the logic Happens on the client side, you load JavaScript and that takes care of things on the page. And that can, you know, that has its pluses and minuses That can sometimes be uh faster, but also it come it can come with an overhead depending on the type of the application that you have. uh those applications can also render things on on the uh on the server on the server side so you you saw with uh the previous next js uh um talk, um a diagram that kind of talked about that a bit. Um

Speaker 1: some come with this kind of universal or hybrid rendering, which means uh that But they will render pages dynamically and then cache them and kind of make them static. So that kind of incremental uh uh approach. And some of them, or quite a few of them, will also do static generate generated. So what what's static generation, right? So uh static site generation takes that concept of essentially it you it take uh your data and you generate a static site meaning good old plain HTML files that don't change and Uh creating chaos. Um yeah, so

Speaker 1: and you you generate your site, y it's essentially just that uh HTML and CSS and then you can deploy anywhere and it has like unbeatable performance because you you you don't have to re-render things. It's really easy to cache and uh as it says there, you know it's quite cheap to host. And frankly, in my view, that that would that's the holy grail of of uh of uh of websites. Kind of it's we started with um static websites and kind of with sort of making that circle uh again. Now so kind of trying to visualize the different types of of these applications. So, you know,

Speaker 1: server-side rendering, you have your audience, your client, that essentially talks to your backend and your backend generates generates the uh the the resulting files and and serves them back. Uh with um SPAs or or the um you know the the the modern frameworks you have your back end you have the front end that then the audience uh audience talks to uh mostly to the front end but from time to time it will happen that they have to talk about to the back end and then do that uh whole round trip. And then uh with uh SSG essentially you have the you know you have your back end uh that generates the static content and then your audience will always hit that

Speaker 1: uh that that uh static content. Now one of the things kind of decision makers have to take in consideration is uh you know is development costs. So if we take uh server-side rendering as the baseline , uh you know what are the costs of the other options so and this is like highly unscientific because there are many factors that that uh that will influence that but generally uh if we if we take the the the traditional approach at 1x if you try to if you do the static side generation j that incurs slight uh a slight additional uh development cost be it uh adding additional module for example loctel bakery

Speaker 1: or you know whatever your uh uh tool of like uh next jazz or knox jazz uh has the capability right and then if you look at spas uh then the cost can increase and that there are a variety of factors you know how familiar you're team is with the product, you know, whether it gives you all the capabilities or not. Then there there come the the hosting costs, right? So if we take uh SSR as the or uh server side rendered as the baseline, then hosting uh statically generated uh sites it's like really cheap. Really really really cheap. And then SPAs, the cost is higher because you have your back end

Speaker 1: which you have to host somewhere, but you also have the front end. Now, what are the uh disadvantages of uh static site generation? Well, if you want to have dynamic functionality, dynamic content. such as I don't know search, pagination, and you have to do additional tricks to to uh kind of account for that. Also if you have a large website then kind of you can have page build delays. And if you you're also trying to paginate, that kind of exponentially increases the number of pages that it has to generate. So it's a trade-off that you kind of want to consider. So if it's a few hundred uh pages, sure that's that's gonna be fast. But if you have tens of thousands

Speaker 1: , editors may not want to wait, you know, five, ten , fifty Minutes, whatever it takes. So, what are the disadvantages for single page applications? Well, there is an additional development complexity because all of a sudden you have different uh tool chains and different methodologies and different technologies to to kind of account for. And also you kind of have an additional layer in terms of like the deployment. You have there are different kind of ways of doing uh of deploying your your backend and the front end. Um so here are some like rules of thumb right so

Speaker 1: uh if you want like if the your main like driver is security go for it uh statically uh generated sites because at the end of the day what the public ever sees is a bunch of HTML files they cannot do anything with it Now if you um you know you you want like a Dasnaziest uh the the most modern experience, the smoothest experience and and and a lot of dynamic stuff, you probably SPAs are are the thing to go. And then uh well for everything else, uh forms, A-B testing, personalization, um, and uh

Speaker 1: handful full of others right go with the good old trusted technology so server side rendering um yeah so again if you want to and also if you want to uh optimize for developers speed you know go uh with server-side rendering because that's good old trusted stuff user experience and also just fancy nice new stuff uh SPA and then security SSG. Right. Um now I I don't have time to go in all of the considerations because you have to think of you know SEO does your uh framework or does your technology allow you to uh do a good SEO search uh you know uh uh

Speaker 1: Dynamic elements and also previews. Like, does it solve previews easily or do you have to jump through a lot of hoops? Anyway, the main question probably a lot of people are asking nowadays is like, well, should I go headless? And it depends really. And you know, our recommendation is to to start with uh server-side rendering because that's just works. But while you do that, you want to like enable the APIs and kind of build something with the with the APIs with the with a view to potentially expand to you know more dynamic single page applications. Now and really SSG is that holy grail and if you can and if it matches uh what you need then go for SSG.

Speaker 1: But your mileage mileage may vary and you should kind of look at this and and see how that fits into your context you know your experience with the different technologies the resources that you have uh and you know the the what what the developers can and want to do. Oh yeah, one more thing. So you've heard it mentioned earlier, but we Like our team put together a thing which is called Are We Headless Yes? Uh Are We Headless Yet? And it's a status side that kind of keeps track of whether Wartel is headless ready or not. And that's available at are weheadlessyet. wattel.

Speaker 1: org. Uh please go. There are uh a few areas we'll keep up Updating that, post links to relevant issues, blog posts, news, and so on. That's all. Thank you very much. Thank you. There's a question.

Speaker 2: Um so we've got a question from online from Kjaten. Um would it be we uh would it be realistic to consider static site generation strategy for a site was 150 KU plus unique pages where dozens of unique pages are created every day. A news large news site for example.

Speaker 1: Again, it depends. What's the build time for that? What other capabilities you are you adding? to to to to your site. If it's just like a an archive of things, sure thing. If you want dynamic pagination and and um yeah Yeah, more than a search, you have to put the you know the work into making that happen. And sometimes that's not realistic. Um but the options are there. There's uh you know Django Bakery and uh that that will or Wagtail Bakery which is built on Django Bakery that will allow you to do this. I know that uh Mozilla used to run in a uh uh a statically generated a website for I think

Speaker 1: MDN, so Mozilla uh developer network. Um but they eventually switched to to good old uh server-side rendering because of paginational search. So again, it it it m it it can work, but it depends on how how much you want to invest in in it.

Speaker 3: Yeah, I'm just wondering um if you ever thought or would advise on combining the options. For example generating static pages for not much visit like archive pages. And using service vendoring for well the difficult stuff like search pagination, almost every site would want that, I think.

Speaker 1: uh with uh with JPL and their uh they have the main JPL website is a headless website and it's built with Nux JS. And some of the dynamic dynamic areas there, I kind of use a hybrid approach where we kind of piggyback on on on on uh on uh elastic search for example. to to build to kind of to have that hybrid approach where with uh more statically generated content and and more dynamic uh areas of the the website. So it's it's one of the many possibilities. I kind of tried to try to distill these in like three main, but there's everything in between. And um People do that.

Speaker 1: People will do that. And there are ways. And sometimes we even with like with Next. js you saw there's incremental uh static uh rendering. Which kind of does that. So there are ways to to to go around it. Any further questions?

Speaker 2: static site generation in the first place. So um they ask how should I make my blog static such that the user never hits the database backend but only accesses the static content

Speaker 1: Um well I mean again my answer will be it it depends. But yeah Try uh you know you can try Wagtail Bakery, for example, and that will bake your Wagtail site into a like a static one. Uh and then you can uh put in some, there's like little Lunar. js or other services that could allow you to search for things. Did I get that right? Um yeah. Um I think in in a lot of cases, right. you also won't have a degree of uh experimentation on play uh because you can you cannot make a choice unless you've tried uh several of the options

Speaker 1: and you kind of know what's involved in them. And I I wouldn't kind of s recommend to peop to people to kind of go, yeah, go jump and do headless or or or I don't know even uh server-side rendered you know with uh with wagtail if if your strengths right are in in in a different area so try to play to the strengths to to your strengths to to your capabilities