 OK. Good afternoon everybody. Thank you for coming along to our talk and we're here to talk about from zero to a multilingual Next.js site powered by Next for Drupal and Drupal recipes with one command. My name is Josh and we have my colleague Mario here as well and we're both here from Wonder. We are an agency with officers in three different countries, Finland, Latvia and Estonia and over a hundred of others work there and we've been a member of the Drupal community since we were founded around 13 years ago. And yeah, today basically we're here to talk about this project and feel free to to kind of check it out while we're speaking to you as well if you like. It's available on GitHub. The link is right there and it's called Next Drupal starter kit and it's an open source template for decoupled projects or projects that use Next.js on the front end and Drupal as the CMS. Before we get into our project specifically, let's just rewind a little bit and talk about why we like Drupal. We'll hear at Drupalcon and what is it that makes it so special. Well, one of the things is that it's got a really kind of solid foundation and it's module system. And with that it delivers a lot of our clients needs straight out of the box before we have to actually write any lines of code. And what that means is that if you look at this graph here, Drupal kind of takes care of a lot of what we need to build for us out of the box. And so that we, as developers and builders, we can spend much more time focusing on the actual features that our clients need rather than just kind of putting together the things that we might have to do for every project that doesn't use Drupal, all the kind of plumbing and that kind of thing if you think back to the DrupalVill analogy, Indrease is known yesterday. And so we live in a world now where decoupled Drupal has been kind of touted as the future for a while. For some of us it is still the future. For some of us we're already working with it. But it is still quite tricky to work with at times and we found that on our own projects at Wonder where we have a number of client projects, big and small that are using the decoupled approach. Some of those challenges, for example, are with synchronising between the back end and the front end of the website. There's multiple ways of dealing with that, but whichever way you choose, you're always going to hit some kind of difficulties doing that, whether it's multiple repositories and kind of keeping those in sync. Obviously MonoRepose also have kind of positives and negatives and so on. And also there's so much choice in the ecosystem now that there isn't really any established way, any kind of one way of doing things. That has positives, of course, but it can also lead to a lot of analysis at every point that you want to solve a problem. There's a million ways of doing it and no established way just yet. And this can all lead to making it a little bit harder to switch between different projects and more difficult for developers to jump from one project to the other or to help out. And that leads to fragmentation and different ways of doing things between different teams and different projects. And so this is the point that we're at now with decoupled projects. At least this is what we've experienced, is that what's kind of being taken care for us is now smaller. Drupal is doing less for us, or in a way it's kind of doing as much for us, but there's more that we then need to add on top of it to handle all of these decoupled situations and all the things that I've spoken about. And so now the developer is a little bit less only kind of building these features over here and they're having to spend more time on the plumbing, on the basic kind of infrastructure just to get to the point where they can actually start working on the things our clients care about, which is of course the features that they actually want us to implement. And so next Drupal Starter Kit is our kind of solution to this and it's about simplying the process of creating a decoupled project and that allows the developer to then focus on building the features that matter. Yeah, so as George was saying we've had quite many of these decoupled projects over the years and at some point so we are constantly looking for ways to improve them for procedures and so on. And so at some point we found this project, which we have liked very much and we don't say it just because people from Chapter 3 are in the audience today. It's called, well, you probably, you might have heard of it. It's called NSGS for Drupal and it is spearheaded by Chapter 3 and contributors. And we thought maybe just to give you an idea we could go and pay them a short visit. So this is the website of the project and it details quite nicely what is included. And in short, this project is the combination of a Drupal module or a set of modules and MPM packages that together allow you to create this decoupled environment, right? Where Drupal holds the content, holds the users and then your users will interact actually with that next JS front end. We will not go through everything here, but I just want to say that there's quite a lot of documentation and guides. There's also quite a lot of available code on GitHub for different scenarios. So if you haven't checked it out, our suggestion is to give it a look. So if you want to get started with this setup, then you have to follow some steps, right? Install Drupal, apply some patches, enable the modules that you will need and then configure some entities, configure some content types and then create of course the front end. They have provided MPX, create commands for that, but then you get something which is kind of bare bones, right? And then it's up to you to continue. Then if you want to enable, for example, preview mode, which is of course very useful and a very required feature, then there's some more steps. And also if you want to have on-demand revalidation, there's more things that you need to configure. All in all, this is totally doable, right? But if you start thinking of having projects and trying to have them working in the same way, we thought that, yeah, but maybe we could automate a little bit of this and also build on top of it. And so we go back to the presentation if I manage. Yeah, wrong direction. So this is where we started from, right? So we thought, okay, we want to use this next Drupal. It's a very good open source project and we want to have an easier way of working with it. So we added quite many bullet points on top. I will try to go quick here. So we added some sensible defaults and adding more and more features that we always need in our projects, right? So, for example, multilingual features a bit more like what you get with Drupal out of the box. We wanted to have one repository that would have both frontend and backend in the same place. We wanted to set it up for our hosting system called SILTA, which is also open source. And yeah, we wanted to automate away all that configuration. And for that, we found Drupal recipes, which is also a very interesting initiative for Drupal core. And then also we wanted to have a bit more out of the box, right? So some default content types that we normally have, right? So page frontend, front page article. We like to use paragraphs in our projects. So have some example paragraph types for the most common things. Media items, images, videos, file, the translation of the content and the interface. We also have, we always use elastic search for the search part. Sometimes also as the engine for this decoupled. Solution. So we wanted to have that as well. Some simple support for web forms. Also we wanted to demonstrate that you can use user registration and login, which is not so straightforward in this decoupled setup. And also we wanted to give some nice example content so that when you spin this up, you don't start from an empty page, but actually from a working site. So, yeah, time for demo. So, yes. Josh. Josh. What does it mean that it's not connected to the internet? Yeah. Hey, it's loaded here. All right. Oh, look at that. We have it. Cool. Good. Basically, this is hosted on GitHub and you can go and get it. And what you see if you go there is, well, the code, right? So there's a folder for Drupal, for directory, for next, and then all the needed configuration to have a working system. We also made an effort to have a decent readme file, not one of those where it says nothing. So, yeah, here there's a detail of the features that you get and the specification that you only have really one requirement, which is Lando. So there's various solutions to have local environments. We have standardised on Lando, so that's what we are using here. So, basically, all you do is you check out this project and then follow the very clear getting started guide. All in all, basically you need to run this one command, right? Setup.sh. And that will do quite a lot of things. So, now, like in a cooking show, we have made the pie beforehand. Initially, we thought of running this live, but I guess it's good we didn't, right? Okay. So, basically, in this terminal here, we have run the command. If I find it there. Right. And very quickly, we can go over in broad strokes with what happens. So, first, the Lando setup is a spin-up. Well, if you, I don't know how familiar you are with this, but, basically, Lando is a local, a bit like DDEV, is a local setup based on Docker containers, right, in the shortest possible way. So, here, all the environment is set up for you to host this whole thing, the Drupal part, but the elastic search and also the front end part. Cool. Then, more Lando, more Lando stuff. Lando is happy and it has worked. Cool. Right. And then we installed Drupal. So, we installed Drupal starting from the minimal installation profile, the one that doesn't have anything in it, not even the blocks and stuff. And then, here, there's the recipe magic, which is something that isn't the process of being added to Drupal core, but you can apply a patch and use it already. And we have set up these recipes. And what you get out of this is all the back-end configuration. Then, we go further down. Here, our elastic search system is set up. Here, the next JS front end is built in production mode. And then, many of you will recognize this migration runs, right? And at the end of all of this, you get two links, one to access the back-end and one to access the front-end. So, let's go to the front-end. Okay. Yeah, yeah, yeah. No, what? It's blocked. That's interesting. Oh, no. It's here, but as soon as you click anything, it will not work again. Oh, no. Okay. This was the faraday cage room, apparently. I'll try to connect to my hotspot. Which may or may not work. Well, a bit of demo effect needs to be expected. Something. All right. Do I dare to refresh? Yes. All good. Right. So, basically, after all that list of commands, right? So, you started from having nothing and just checking out the project and running that one thing. This is what you get. So, it's kind of a small demo site with all the features that we discussed before. So, you get this front page that starts with a hero component. And the images are fetched randomly each time when you do the migration. So, this time we got this nice courgette. Anyway. Or green beans, whatever. Right. So, then you get some text. Then you get a listing of the latest articles. Right? We talked about the content types. And then something that teases Webform, but says you are not logged in. Then some more articles there. A link, some random faces and a bunch of logos down there. Because, of course, clicking there takes you to something that looks like a view. It's not really a view, but it looks like it. Where you have these example articles with one which is sticky on top. Right. Then, going over the header, we have a search system. And if you search here in the front end, then through ElastiSearch will give you search results. And you have a basic faceted navigation system and also a working search. So, if we type through there and we type it. Actually, it should work also if you type it wrong. Anyway. Right. So, you get some results and then you can filter them down. We've seen it before, right? But this is not super straightforward to set up. Here you get it. With zero effort. Okay. Then. You have an account menu that we stop. Where you can log in. And also we make the migration. I am the slowest typer in the world. Okay. And so the migration will create a couple of users for you to try out. So, MrTestUser1 now is logged in. And now we see that the web form is actually showing up. So. Wait. No. Josh, what's going on? This is not my laptop. Please do an A. Act sign. Which language do you have? Anyway. You're telling me you don't have the Finnish keyboard layout which is the best in the world? Okay. All right. Anyway. So, if I submit this and I get I see this success message, right? So now the web form is being submitted to Drupal. And it's saved there. We also have added an example of a dashboard page where you know, in the next yes this is generated as your own private page. And then here as an example you can see the beautiful web form submission that we just made. So, yeah, this is supported and again this is one of the features of next for Drupal. Then we have worked on the language support and basically we have our languages that we normally work with. So we both work in Finland and so while Finland has two official languages, right? So Finnish and Swedish. So those normally need to be there and also English and so basically here you can switch to a different language, right? And you will see the article translated badly by Google translate into the correct language. It seems like a sylifie but it's an example of those things that Drupal gives you, right? And you're used to that. But in the couple applications it's very common that if you switch the language then you just go to the front page for that language because it's a bit tricky. I mean that we have added to the front and set up. Then here behind the hamburger menu if I manage yes, there's a hierarchical menu which is also something that you always have to solve in these decoupled projects, right? Not super straightforward. And so there's nested things and you can then visit those pages. Pages are built again random images so hopefully nothing crazy. It's a bit like Italy. But yeah, so these pages are built with components, right? So we have some text, we have a link, we have an image, we have a video and then we also have a accordion which then has paragraphs inside it which is another thing which is slightly tricky that we thought of including. And yeah, I think that includes the front and demo, right? So let's have a very quick look at the back end. Right, so that's a rush link, so we already logged in so that's why it's at access. Doesn't matter. So now we are logged in as the user one here and this must be very familiar, right? It's just the usual setup that you get out of the box. You have a list of content here. We have our three content types and if we go for the front page, for example and then we have translations. So some time of our life has gone into creating that multilingual migration that runs in the beginning but it works. So basically if you select the front page for the site, this is what you get. This is a feature of Next for Drupal. We didn't invent this. Basically the front end site is running in an iframe there and you can see the published version of your front page, right? Then if you click on edit, you can then see the data that makes the page, right? And there's some more stuff you can preview on published things and so on but let's not, yeah, we don't have too much time. Right, so that's my thing. Then we saw that we're on menu, right? So there's nothing too magical about it. It is here. So it's done in the usual way, you know parent and then children terms and so on and it's also then translated and that's how you get it. Then last thing we saw that we submitted one web form and the web from is here and our submission is saved there. So basically this is the base of a possible project, right? You maybe don't need all of these things but using these recipes is quite a nice way and I really hope that this initiative gets to be committed because basically if you think from a development point of view what you have here is a working site that you can do rush configuration export and then commit it and that can be the start of your project, right? So your configuration is yours and then if you don't want the article then you delete it or if you don't need something you delete it but you don't start from scratch, right? And that bar is moving to the in the direction of the developer. So, yeah. Josh, Q. I'll just try to screen this again. Yeah, okay. So now you've seen a little bit of the website about, you know, what the starter kit makes for you when you first run it and now I can talk just briefly about the kind of front-end setup some of the decisions we made in terms of what packages are installed and that kind of thing. Yeah, so one thing that this next-day setup has is something called incremental static regeneration and so what that means basically is that although the entire site is built to HTML when, you know, when the website is built that build only has to happen once where all of the data for all the different pages is fetched and generated. Next time a content editor makes a change to a particular page or a particular piece of content then only that one page or whichever page matches or uses that content is then built so that means that pretty much when the content editor hits save a few sort of 100 milliseconds later or so that content is then live without having to wait for a whole build. Yeah, we also have preview mode for unpublished content so a developer or a content editor can preview that content before hitting save and putting it out there to the world. We also use TypeScript and a related package called Zod on the front end and that ensures obviously type safety for our code in the case of TypeScript and then type safety for the dynamic content that's coming in from JSON API in the case of Zod as well. Yeah and then a few more kind of opinionated decisions that we've made we've got styling with Tailwind and interactivity with Radix UI so we found Tailwind to be a really good solution for styling our components across many projects and yeah, Radix UI allows us to make highly accessible components quite easily. Login for the front end is handled by NextAuth and the search interface uses search UI which is a kind of front end set of components built by Elasticsearch and designed for use with Elasticsearch on the back end and then finally we use React hook form and we only have that very simple form example in the starter kit itself but of course all of this is about taking decisions out of the hands of the developers and kind of making a default decision which we know will work for the developers and like once that project has been spun up if a particular project or particular developer either doesn't need one of these features or they want to use something else that's perfectly fine and the idea is make sensible decisions and kind of have sensible defaults so that there's a little bit more consistency amongst our projects but then between different projects there's no kind of we're not forcing anyone to use any particular packages we just think that it's better to have a default setup than if you know what you're doing you can change that if you wish and then finally we also have Storybook setup so we have a reusable component library with a few basic components that are used for this with the idea being that again that's all set up for you that's all set up for you already so if you need to make another component of course you'll add it to Storybook as well and just to encourage that consistency rather than having some projects having it, some projects not and all of those setups differing in slightly different ways it's just so much easier to set it up once and most projects then will tend to go with that setup at least a lot of the time and then we finally have Cyprus setup for some testing as well on to the back end yeah thanks I realised I have spoiled basically everything in this slide so let's go very fast so as we said the site is using a minimal profile and then stuff is added on top using this mechanism of the group of recipes which as we said is a bit experimental but the good thing is that once you have created that initial configuration then you can decide for example to remove that patch completely and then your site leaves its own life so these will set up the admin UI and permissions for all the things to work and if you think about it there's quite a lot going on there's quite many required modules that need to be activated they are added to the composer.json that you will find there and then activated by the the recipes right then as we have seen you have these different content types that contain various fields paragraph types you've seen some pictures there videos so the media types and then the language setup is there then also the whole elastic search setup this is another thing that there's a module called Elastic Helper that Wunder has been maintaining for quite a long time and this contains that under the hood behind the scenes so if you want to see how that is set up it's a good occasion and then also all the setup needed for Next.js for Drupal as we have seen right so enabling the module creating Next.js site entity then associating that those content types with the Next.js site setting up the incremental static regeneration doing the whole simple setup creating consumer and also do this, so there's validation there at the end and also doing this thing in Lando where we host both the front and the back end you don't need to mess with those .env files which are always something that you need to pass around with developers and so on the whole environment, back end and front end is set up inside Lando and the back end knows where to find the front end vice versa So obviously this project is still in active development and we've used it for a couple of client projects so far and it seems to be working well but we're still adding things to it. Some of those things are still working well. We'd like to run the tests in CI at the moment with our testing setup it runs locally only which isn't ideal we have some challenges running in CI we'd like to solve those challenges we'd like to improve the documentation and also the hosting options so right now it works with our in-house hosting infrastructure called SILTA you can also use that because that is also open source but yeah this whole starter kit is obviously first and foremost being designed for our own projects but open sourced with a view to let others use it and 99% of the stuff in there you can already use freely but hosting is something that we haven't configured for anything outside of SILTA which is our own hosting setup we'd like to improve the web form support it's really basic at the moment it's quite difficult to do it right so we haven't tackled it yet so at the moment a lot of if any project needs web forms they have to implement it themselves we would like to have some kind of more general purpose solution but it's obviously not an easy task to solve we'd also like a more modular setup there's a lot of assumptions and things made in this starter kit and we've tried to only give you things that you're very likely to need so almost all of our sites are multilingual for example most of them tend to use these menus that have nested structures etc etc so we've kind of tried to make it work for most setups but in the future we imagine some kind of interactive CLI when you spin up the template and then you can choose for example what content types you do or don't need and things like that Drupal recipes is obviously heavily kind of used in this starter kit and we'd like to you know keep up with that as things change and also use any other features that might prove useful when they do and then as this is used in more real world client projects we'd like to identify more things that make sense to bring back to the template so that more projects can take advantage of it and then finally just expand the user base get suggestions, get feedback and contributions so hopefully that's where some of you can come in today as well or in the near future and talking of that we have a buff session tomorrow and so you're very welcome to come along at three o'clock tomorrow and we can discuss next steps for the project and maybe get see what comes out of that in terms of discussions, maybe a little bit of hands on if we want you're very welcome to come in and say hello we'll also have some swag from our company as well so what have we got things, bags hats bags, yeah so come along and hopefully I'll want to talk about this project if not free stuff is always nice as well and contribution opportunities are available all week and that's the end we've got about 10 minutes or so for questions and answers in a second so yeah, thank you yeah Trond do we have any questions coming in on the app first and if not we'll take it to the floor after first question why should we choose this next JS on top of Drupal what are the advantages and because it adds this additional layer on top of Drupal but why should we do it so yeah so I just want to say this is the million dollar question it's if you've seen the Driesnote yesterday I don't know my personal feeling is that this is not a solution for everything of course the project needs to fit and it needs to make sense with what you need to what you are trying to be yeah is that vague enough somehow or Josh what do you want to add I mean I'm biased because I'm a front end developer mostly so I'm very biased on this I don't know like next JS has a lot of things that make the user experience quite fast there's a lot of things that I think do result in better websites a lot of the time controversial to say at Drupal con perhaps I don't know and also a lot of developers want to work with next JS as well and so whether or not you kind of think it's better or not actually sometimes it's easier to have people working on this side of things as well so that's a couple of reasons from my side answer is it's complicated yeah yeah and maybe a bit related the next question is how much faster is this compared to a normal setup and at least the site that we're running currently in production built from our client is really fast so I mean we have seen it live already Trond has answered so let's move on next question do you have an optional or another recipe to install that does not come with the content or yeah so that we don't have to clean it up yeah so basically if you peek under the hood of that mysticalsetup.sh you will see that it's a list of comments and the last one enables migrations and imports the content so if you leave that out nothing will be important in terms of entities so menu items content users so that's easy ok are roles and permissions followed on to the front end so for example search results can they be different for logged in or logged out users so not in this starter kit this particular question so if it's about the search this can be can be added sorry not to be too long but basically so elastic search is proxied by Drupal the front end doesn't talk directly to elastic search if you know how it works this would be a big issue so basically Drupal is there and when you do a query you can see is this somebody was registered and should I show these results or not and we have done it in other projects and it's not such a I don't know at least so far we thought this is not a very common requirement we might rethink it then thank you next use land though in this one do we have plans to add DDEV as local environment so for me this is very interesting I know that DDEV is also very widely used and it's also I think in these contribution days and my plan is to contribution and try DDEV as well so we have specialized on land so of course for our company it doesn't make to say oh there's a new starter key you just need to change what you use but I'm pretty sure it's possible to achieve or I really hope it's possible to achieve the same thing with DDEV and I don't see why not and that would be an excellent contribution if somebody is passionate about DDEV and they want to try to make it work great thank you so this project is done with path-based translations is there support for domain-based translations and do we have client projects where this is a requirement no thankfully I think it has happened in some projects but at least this seems to be the most straightforward way and it's one of those things probably will be a good feature but it's not in this starter thing any specific reasons why opting for next.js instead of react or view okay so next.js users react so it is user react and also next.js for us has been the kind of default solution for decoupled projects until now obviously those projects have not had this kind of starter kit and that led to the sort of fragmentation of different projects that I was talking about at the beginning and so yeah we kind of use next.js by default at our company for decoupled and that's why this was the sort of obvious choice for that thank you have you considered adding next.js app director support yes we have yeah we would like to support this app directory for those who don't know it's the kind of it uses react server components which is a new thing it's only available in the latest version of next.js next.js 13 it's on our radar we haven't done anything to support it right now we don't we're sort of happy with the performance of the sites that we make with this right now but it is something that we definitely want to consider in the future and possibly work a little bit with chapter 3 as well because that's obviously something that you want to add to next Drupal which this project uses and we'd be happy to add support for that in the future yeah okay yeah that's really good to hear yeah we'll definitely check it out soon please repeat it chapter 3 chapter 3 did release just before I walked in the door here we released our first version of the app router upgrade to next Drupal and it's ready for user testing so if you go into the Drupal Slack under next you will see where it lives it also lives in our github repository and if all goes well we should have full app router support soon after it's been tested so just wanted to let that know because it happened right before I came in the door there's still one have you ever tried and what is your opinion about partially the couple of solutions in Drupal project yeah so we happen to have been in different projects where this approach has been is in use and I think again it's a very vague answer but I do completely personally I think that's also a valid approach it all depends on the features that you need and it's one more web or no not web one more tool that you can use to achieve your goals right so in our case we have different websites where for example the search is done using that elastic UI as well and that whole thing is a react app that gets loaded when you go to the search page for example and in that case we needed much more of that bar that Drupal gave us but we still wanted to build a good search interface so that was done in that hybrid or progressive decoupled approach and personally I think it's totally fine use that it's great use whatever works for the project right this is one of the ways that we do projects we have a lot of just Drupal projects we have quite many but there's this hybrid approach and also quite many decoupled ones and now some that use this specific way of doing the couple sites so these were all the questions in the app for the extroverts there's also a microphone if you feel like it but so if you have a question please would you mind walking there to that microphone round of applause thank you okay hi first of all great presentation and thank you for sharing your code I've learned a lot so chapter three for sharing next Drupal and hiring AirShot but why did you let him go so that's the next question yeah yeah I know that's another middle download question so I have like five questions sorry so I know that next Drupal maybe it's for chapter three more or less but you guys might also 30 seconds later okay I know the caching works revaluation by routes but in most cases you kind of need by tag so for instance you have let's say a news on front page and someone changes some add a new content you want to revalidate that and this is somewhat of a blocker you know just to I know you can still revalidate by path but you know it's not performative at all so any plans to support that chapter three guys so well what I can say is that we have some partial support for the feature not for the cache tags right so for example you've seen that the articles are I don't know if you remember but there's this one page with all the articles right and also on the front page there's these listings with that so basically in the article configuration for on demand revalidation we also have added these paths so you know but then the you know how will visit if you have to tell the back end where things are going to be used there you know it's the usual thing but anyway that approach works if you if you change an article you have told the back end in which pages in the front end is going to be displayed and so all those pages would be revalidated but yeah it could be of course more sophisticated as a solution but yeah thanks hopefully you guys managed something you know but the next issue that I had is the views and listing page for instance you know like on slash news all page that you want to list everything many it's like a heavy editorial website it constantly gets updated you kind of have to constantly keep rebuilding that's a next js issue that at the end of the day it's a static site you know any solution for that you know I always thought for the first page I just fetch the data you know that's what I do but it doesn't seem like yeah so do you mind if I say come to the both because this is a really yeah it's a bit of a long question but okay I can switch to the next one yeah so the answer is at least in the starter it is that page that looks like a view it's not really a view and it uses this revalidation as well and so it is very fast when it's there and then it's revalidated in the background and so on and also on the front page there's a listing of the latest articles but it's a paragraph so it's somehow inside the page so it's done on the client side so yeah again it's not super safe already but so next one is for web form I was thinking do we really need to support it I mean it can be like your own input you know you just render a react input and just hook it up you just use it as a store of data that's also one question I'll ask the next one so we can wrap it up one of the hardest part for me as a I'm a front-end developer so I just like to do this stuff but it's hard to convince first the client to pay more and the second your boss is why are we doing it like that you know so we never came up with a solution just saying it's faster and they say optimize your Drupal and it's still fast it doesn't work for us you know as a selling pitch yeah I'll answer it just quickly because I know we've only got one or two minutes and I'll just go back to this slide in case you want to continue tomorrow as well yeah like we found that decouple projects do tend to improve the websites that we make but the issue with them is that they do take a lot longer to set up and that's kind of like why we made the project is to make that setup a lot faster to kind of do you know a lot of that plumbing work for the user straight away just to kind of solve the problem that you alluded to in a way yeah I will leave it there because I know that we're about three or four minutes over time already thank you so much come to the boff tomorrow if you want to thank you