Submind YouTube summaries
Thumbnail for Beyond Headless - How Drupalists, Front-End Natives, and LLMs All Win with Next.js

Beyond Headless - How Drupalists, Front-End Natives, and LLMs All Win with Next.js

Watch on YouTube

Video summary

This webinar, co-hosted by the Drupal Association and Pantheon, explores the evolution from traditional decoupled architectures toward a component-driven open web powered by Next.js. As user expectations demand interactive experiences akin to native applications, JavaScript has become the dominant language for modern development, yet Drupal continues to offer robust, reusable back-end structures such as content models and permission systems that do not require front-end developers to know PHP. By separating the content management system from the presentation layer, organizations can leverage the optimal technology stack for each function: front-end teams specialize in JavaScript with Next.js while back-end teams manage Drupal, thereby reducing the need for hybrid specialists and streamlining complex development projects that once resembled costly "science experiments." The integration of these technologies is significantly accelerated through tools like Pantheon's starter kits and DDEV, which allow users to connect a Next.js front end to a Drupal back end in under thirty minutes using pre-configured recipes. This approach not only enhances efficiency but also provides remarkable flexibility, enabling content managed in Drupal to simultaneously serve multiple channels including websites, mobile apps, and digital signage. Furthermore, the convergence of Drupal's Canvas component language with Next.js React components creates a shared underlying codebase that facilitates seamless data flow between visual editors and modern front ends. Although full automation is still emerging, CLI utilities are being developed to sync components between the two platforms, while AI models increasingly adopt front-end patterns to help generate maintainable and secure code based on pre-approved libraries. Successful implementation of this hybrid architecture requires a strategic balance between technical rigor and the practical needs of editorial users, ensuring that content editors can easily manage their experiences without needing direct JavaScript expertise. While non-technical editors rely on visual builders like Canvas for creating layouts, upcoming authentication mechanisms will soon allow Next.js sites to link back to Drupal for content editing and user-specific gated content, bridging the gap between visual creation and backend governance. The community is collectively adopting these standards to reduce divergence between tools such as Paragraphs or Layout Builder, fostering a unified ecosystem where development pipelines are respected and the user experience remains central to project success. Looking ahead, the discussion highlights ongoing efforts to build long-lasting structures rather than relying solely on AI-generated content that may lack durability, with new webinars planned for AI integration and starter kits set for release at Drupalcon Roderdam. The session concludes with an invitation to attend the conference in September, where further advancements in multi-site configurations and higher education course registration systems using Next.js will be demonstrated. Ultimately, the webinar advocates for a future where Drupalists, front-end natives, and LLMs all benefit from a streamlined workflow that respects both development complexity and editorial simplicity, ensuring sustainable growth for the open web.
Read the full video transcript
Hello everyone. Welcome to the co-hosted Drupal Association and Pantheon webinar for today. Um we're going to give it a couple of minutes as more of the attendees join. Uh we know we've got quite a few folks registered, some who will attend live and some who will check out the recording. So we'll just take a minute or two here. Um, while we're getting set up for that, um, I do want to invite you to, um, you can hop into the chat, introduce yourself, where you're coming from, all of those things. Um, we'd love to know who you are and where you're joining us from. Um, throughout this presentation, you're also going to be able to use the Q&A feature. Uh, it's one of the toolbars in the Zoom toolbar down at the bottom of your screen. um to ask questions, upvote other people's questions, all of that kind of stuff. Um it looks like humidity might be a theme. Um >> yeah, because uh yeah, Portland's pretty humid today, too. >> Really? Usually I think of Portland and I mean I grew up in in Eugene and humidity is not something we had >> that bad, but we're having some weird summer weather at the moment. So, I don't know. Tim, welcome from Wilsboro. Nice to have you here. All right, some more folks jumping in, but pretty shortly here, we'll just go ahead and get started. >> Yeah. >> And make sure that it's ready. There we go. Couple more in. All right. So, one more time with housekeeping and then we're gonna go ahead and jump in here. So again, thank you everyone for joining. Um we're expecting more attendees to join live as well as a bunch of folks to be watching the recording afterwards and that means there will in fact be a recording. Um we're also uh have it set up to do an AI summary and we have the Q&A open. So in your bottom toolbar you can use the Q&A tab to ask questions or upvote other people's questions. And finally, I encourage you to chat with each other. Let us know where you're from, all those little details or share your own kind of stories and experiences related to this topic uh using the chat window at the bottom as well. Uh but without further ado, we're going to jump in and get started. So the topic for today's webinar is beyond headless. How Drupalists, front-end natives, and LLMs can all win with Nex.js. Moving past the painful days of decoupled into a component-driven open web. There's a lot to unpack there. It'll be an interesting conversation and I think um a lot of us understand kind of the history of Drupal in headless decoupled spaces and also how rapidly things have changed uh in the AIdriven development world. Um and so there's a lot of good places to uh to talk but I'll start by introducing myself. Uh I'm Tim Lennin Hanet on drupal.org and the CTO of the Drupal Association. Um and really glad to be co-hosting this webinar with the Pantheon team. Uh Will, I'll hand it to you to introduce yourself. Just come off mute there. Uh and then we'll go to Josh. >> Thanks, Tim. Uh hi, I'm Will Jackson. Uh I am coming from Aken, South Carolina. I have been working in the Drupal space for just about 20 years since uh roughly Drupal 5. Uh sort of flex days and uh been over to CCK and uh so I've been around for a while. I've been working largely in uh an agency support uh realm for um most of that time but I've been with Pantheon uh beginning this year and um yeah it's been great. I've focused mostly on Drupal in the past few years. I've been diving deeper into uh the Nex.js world and uh really exploring what we can do with uh the LMS and the the new robots that are available. So it's uh very exciting to be here. With that I'll pass it over to Josh. >> Uh yeah, thanks thanks Will. Thanks for hosting, Tim. I really appreciate um this and opportunity and yeah, there's a lot of words and jargon and we'll get through all of it, but hi, I'm Josh, co-founder at Pantheon and prior to that was a Drupal agency founder and owner myself. So, have been doing this for a similarly long number of years and, you know, really enthusiastic honestly about what the future of the open web holds in this sort of brave new world that we're all starting to inhabit. Um, so I would, um, I'm just going to go ahead and dive into some content. Uh, Will's got a little bit of demo to show, which will be great. And then, you know, we can kind of go back and forth and talk about what's happening in the industry, and we'll take questions from, uh, from the audience. So, just to to to start off, um, why is JavaScript eating web development? Um, like I think this is something everyone uh can acknowledge. Um, and you know what's interesting to me is when I take a step back and look at what is driving just the rise of JavaScript as the sort of the lingua franca of the web. Um, it's it's like a lot of things that actually originally drove the rise of Drupal in the early days of my career. You know, if I go back 15 uh 20 years, you know, building with uh Drupal offered the the the a kind of a a a competitive edge in quality and performance. there was this really, you know, at the time comparatively large ecosystem of talent um compared to, you know, everybody else who had kind of built their own thing in a tiny little niche. Drupal had this large open source project and all these people professionalizing around it. Um, you know, AI wasn't a driver uh back then. That's that's the the the new thing. uh but it's I think it's worth acknowledging uh and celebrating that like the the the way in which people get the most out of the open web from an experience level you know I think about this as not just websites but like um like what my kids do on their iPads when they get 30 minutes of free time and they go open they open a web browser they go to a uh one of the many domains they know where there are games they can play and all that's just happening over the web in in browser for them and they and they love it and there's all kinds of cool innovative things that you can do with front-end technology now. And you know, um Tim, I'm I'm like kind of curious your perspective on like uh if you're seeing this in your in not just in your Drupal world obviously, but just like in your own kind of everyday world where there's this rising generation of talent. >> Yeah, absolutely. So, um you know, the the immediate example that springs to mind is my my brother-in-law, and he's not that much younger than I am for that matter, right? like you know I just turned 40 and I and I was in hardcore in the PHP traditional HTML CSS like um first generation of of of that level of development and in Drupal 4.7 I think or something was my first version whatever it was and um and he's you know only a few years younger but his his kind of entire technical career is JavaScript focused is primarily designed around building um what we would now call web applications more so than websites and with a with a strong focus on building from a sort of front-end first perspective or from a UX UX experience first perspective, right? This concept of of building um component libraries, interaction libraries and all of these kinds of systems. Um, and obviously I think he was at the front end of that particular wave, but but kind of every generation since. This is this is what people are are primarily learning in in both formal education and when they're when they're self-eing. And it's really interesting because it's flipped around some models and like lots of kind of technical progressions, it's done some new things really really well. Like again all of the interactivity um of all of this all the application like output that you get um but it's also kind of left behind some things. So I, you know, uh, at every family gathering, I'm talking to him about this kind of stuff, and he's redoing a lot of the same things that are part of the backend structure of this. Every time he's, it seems every time I talk to him, he's writing rewriting a permission system for for whatever the latest JavaScript project is, or he's rewriting a data model, or he's trying to decide, you know, should um should this object contain all of the fields for this thing, or should it be two separate objects and all this kind of stuff. and and we always have these conversations around how you know the the fundamental content model modeling, permission structures, entity structures, you know, one of the powerful things about the Drupal side is those are reusable, well architected, built on 20 years of experience. Um, and um, that doesn't mean you have to do all of your work, even your front-end work on PHP. That's why we're having this conversation. The whole concept of of headless development, decoupled development, whatever the the the term dour of the day is, is that you can use some of those like fundamental structural decisions and still build all that interactivity on top. Um, and I noticed in the chat someone mentioning uh HTMX as well as another another layer to this uh conversation and the new interactivity that's being added outside of specific JavaScript frameworks. So anyway, I just think it's really interesting. I think it's an important way for that Drupal can remain relevant and not only remain relevant, but actually bring what might be considered our old ideas to what this new most common development thing is and really give them a leg up when it comes to content structure, permissions, and everything else. So yeah, it's been been a real interesting experience for me trying to be the uh the gray beard evangelist to be like, "Hey, you know what? You can do all those great things, but you can do more, too." Yeah, totally. I I I feel that. Um Will, just since you're you've had that, you know, like a long arc too and and you said you'd spent a lot of time more recently in your professional career sort of walking in this world of of front end. Any observations from you on like what this, you know, what's driving this change and what it's meant for the practice of professionals in the space? >> Yeah, absolutely. Um you know Drupal's been around for a very long time and Tim as you were mentioning you know the 20 years plus um with a lot of the thought and um effort that's gone into these systems. So things like the permission system the user authentication system um there's there's a in the caching system too which all of it just really lends itself for um you know working with platforms like Nex.js JS and um and Josh as you mentioned uh or um I have a a cousin who um few few generation behind me um but he went through the the route of like the boot camps and um a lot of those are really focused on Node.js JS and exclusively that I remember I was trying to tell him about Drupal years ago when he was getting started in that and he was like oh you know just not really interested he was focused on uh JS10 like you were mentioning he's he's rebuilding a lot of the systems that already exist and exist well in Drupal that have a lot of support uh that have a lot of sites and um you know folks working on that. So I mean like security updates and things that uh you typically would have to you know really focus on you know really pay attention to uh on a on a you know per application level you know going with Drupal it allows you to you know leverage that uh open source ecosystem um and not to mention the contributed market uh with uh contributed modules being able to extend that functionality to um you know further uh enhance the the site too but out of the just out of the box Drupal core does so much that uh really complements a lot of the uh some of the challenges that you run to when getting started with Nex.js and other node platforms. >> Totally true, Will. And uh you know, Josh, maybe we should step back even further for a minute here because we have some total some total newbies who are who are on the call who are learning about this. Would you quickly define what the heck we even mean by decoupled here, right? We're talking about the advantages of Drupal. We're talking about the trends in JavaScript. Could you talk about what we mean by this bridge a little bit? I know we'll go into it in the presentation, but >> Yeah. Yeah. just to level set I mean for for people who who are joining the call and and are trying to learn I think you know historically and we'll talk about this more later you know sort of Drupal was you know the the complete stack you needed for the website it it both serves as the thing that holds the data holds the content it's the editorial user experience and it's serving the outwardly facing public uh side of the website too um and then you know there's just been this movement in the past uh you know over the past decade really as the way in which that outwardly facing layer gets built has evolved the technology around that has become very JavaScript driven. Um there have been lots of different approaches to hey is there a way we can use Drupal to manage our editorial experience and manage our content and our structure but let the modern front end be natively itself. And so you end up with an architecture where there's sort of two layers to what you're building. there's a core underlying often we call this a headless CMS because it's not serving the actual content to the front end. It's just it's just providing information that then the JavaScript uses to deliver the actual existing enduserfacing experience. Um and so the reason why I think this is a great conversation to have now is not because this is new because I think the practice around doing this is converging. Um and so that's where I want to introduce Nex.js. Right? Nex.js JS is a open web success story um that it's rapidly outpacing um like SAS tools like web flow um any other JavaScript FL framework like there is this sort of you know deserved reputation of JavaScript frameworks being having a flavor of the month kind of uh aspect to them but Nex.js JS is just actually leaving everything in the dust. And the reason for that is, you know, JavaScript and then you layer on top of that React. That's where all your components come from. Reusable. There's tons of open source components. That's one of the reasons why it's so fun and fast to build with this stuff. And Next has just found the winning formula for using a component-driven uh uh approach to web development to create sites or apps or things that are like kind of in the weird uncanny valley in between where there's a bit of both. Um and you know there's this uh uh the company behind Nex.js is called Verscell. It's a great company. They do a lot of cool stuff, but they're not they don't own that market, right? It's actually open source and the open web is the majority of what's going on with Nex.js. JS uh and so like we're um obviously as a platform uh moving in the direction of supporting that because that's where the practice of a lot of our customers and and users and partners is going. But I just want to raise awareness as you know for people who have been hesitant because they're not sure what to invest in. I mean, I'm not going to tell you there's a right or wrong answer, but I I will say um when you look at technology adoption, sort of moving with this kind of pace, it's a fairly safe bet to say that if I invest in learning and uh understanding Nex.js, those skills will serve me well uh in the future. Um, and the thing that I think is really interesting is that in the first decade or so of doing this, it was like a big heavy lift to build this way. It was kind of like, you know, you had to invest a lot in engineering. You know, you would think of if you were an agency, right, proposing a decoupled architecture, it's going to cost twice as much as if you just did it the oldfashioned way. It would be twice as hard to manage. There's all this complexity. um and you end up with a sort of like a science project at the end of the day. And this isn't specific to Drupal, by the way. This is the whole industry. We the whole industry went into composable, decoupled, headless, etc. And there's real value in doing that because, you know, the the sort of one one-sizefits-all solutions are I mean almost by definition somewhat limited. But the lack of guard rails around how you do this work I think created a lot of people where they ended up feeling burned by the approach. And so I think that actually there's a little bit of a less ambitious way to look at how Nex.js and Drupal come together where it's not trying to be an infinitely extensible integrate all the things build a super complicated architecture. It's actually just rethinking what do we mean by building the front end for a website and like essentially an alternative approach to that to traditional theming um which is again using this outside in approach uh Tim that you mentioned and allowing that to kind of define uh what is necessary to deliver the end user experience and then now with like a little bit of good open source code maybe a little help from some AI to to match patterns you can actually very rapidly put together uh a a Drupal backend to match that front end. Um and it's not something that is a big engineering project. If the front end is well defined, that's a big if, but increasingly that's like not hard to do, then the back end can just say, "Oh, I see what you need. Let me give you what you need." Versus the the way it used to work was it would be, "Hey, here's all the stuff inside Drupal. What do you want to do with it?" And then that creates a big challenge on the front end to actually figure out how it should work. So, I feel like this is a we're on the cusp of something where we're we're developing a new approach. Um, and this is driven a lot by what's happening inside Drupal Core and with Drupal CMS and Canvas. Um, but it's a it's a potentially a a really interesting way to think about this classic problem of quote unquote theming that has always been in, you know, at least in my experience, one of the places where, you know, it like it's the sticky part of a lot of projects. And it's a place where things can like scope can kind of expand unexpectedly. And Will, I can see you nodding. And Tim, I'm I'm curious if you have, you know, from your perspective, any thoughts on that? >> Yeah, I I would add to that, right? because one of the things that has been true in the past is and and it wasn't wrong is that people have thought about Drupal as a monolithic um kind of application for doing website development and if you've been following it closely and for those folks who've been doing decoupled previously and are just curious about the the latest evolutions one of the really exciting things both about this version of Nex.js JST decoupled but also about the way the architecture of canvas is built in Drupal CMS and several other kind of um more contrib related initiatives about front-end design and theming is it is this more kind of componentized you can choose your front end your front-end developers can work in their natural language and in their in their natural sort of frame of mind without having to also be PHP developers also will be Drupal developers and that level of expertise. And on the Drupal CMS side with canvas, we describe it as like you can just give a JavaScript developer the code component editor and they're they're writing they're they're writing native JavaScript and they might not know anything about about the the bones of the Drupal of Drupal underneath. And similarly, when you're going this way for this fully interactive application with Nex.js, JS this this truly interactive experience. Um you you now have that kind of separation of concerns that lets people specialize on the technology they have instead of having to be these hybrid specialists who know everything. >> Yeah, absolutely. the um and just a further that too. I mean there's uh the flexibility of just node JavaScript and uh react you is is um a bit more than what you can typically do with um you know PHP twig and uh what's coming out of the the standard uh CMSs. Um and it hasn't happened as much in a while but you know this looks and feels like a Drupal site was a common term that I would hear years ago. Um but now that we have more flexibility and you know with the frontends and less less so since you know Drupal 9 and 10 and really um you know some of the um more modern updates with uh theming layer have come out specifically with canvas um you know it's there's just a lot more flexibility than what it used to be and specifically being able to uh tap other resources or other talents that are um you know specific to JavaScript. they're very familiar with JavaScript but you know like you were mentioning you not as familiar with Drupal and then they have to kind of onboard to that as well just makes it uh makes it to where there's a lot less friction. >> So I want to move forward ahead just to kind of um uh get us to to Will's quick demo because that's obviously a a important thing to show. But I think the the future that I'm seeing is, you know, this world where I think what native front-end developers are looking to do is, you know, they they they have a place there's an architectural place for them in the Drupal canvas. But I I think many of them they don't want to use the component editor. They actually are used to having their own repository. like they have their own they have existing workflows that that already work and they're working in many times building these design systems and they want to manage through that and I think there's a world where meeting them where they are and having a workflow that allows them to just do that and then kind of transpile that to to Drupal kind of automatically also gives us the the pathway to do some really interesting things with AI because when you can provide AI with a a library of components and you know say don't don't just write code just figure out how to assemble it with these pre-approved building blocks, you can end up with stuff that is much more durable, much more maintainable, um you know, much safer that you can actually govern. And so I see this future that that is not very far off. This is where we have a little demo today. We'll have more demos to show uh circle Drupalon uh Roderdam about this. But the the idea of of really d bringing kind of safe structured generated front end uh into the picture and then meeting that with the safe structured governed content on the back end uh that that can come from Drupal. Um so you know I think the production ready version of this that that you know we we're we've built today and we're evolving with the customers is you know um something that like gives you know prioritizes still the front the the editorial user experience. That's a big problem with a lot of decoupled builds is because these layers end up separated content editors don't really know what's going to happen when they click publish and that's a kind of that's a non-starter for most teams. um the idea that we're managing two code bases and we're we're sort of saying both code bases can have a full DevOps like cycle. Whether that's like a mono repo with two code bases in it or you actually split your repos, that's sort of a a matter of taste. But this idea that there's pipelines that are aligned and that we can do things like manage the cache across these different layers and make sure that things are performant and that they're ready to scale. And then I think also like uh as a as Pantheon as a platform that that serves, you know, already serves today, you know, billions of pages of Drupal a month. Um we really want to be able to provide people building this way with like accountability around their stability or their performance and their security because one of the problems that happens is when you integrate multiple vendors, you sort of can have those uncomfortable moments where something isn't going right and everybody's kind of pointing at the the person next to them. And we think that if we can provide all these things together in a vertically integrated way, it's going to help a lot of people build really cool web experiences using this combination of technologies. And uh oops. So this is and this is sort of my pitch that I just gave um about all these good things. Um but basically, you know, if you're interested in moving in this direction, if you're interested in evolving your practice in this way, we've built some great starter kits. Um, you know, if you're if you're with Pantheon, uh, and you're an agency partner or you're a customer of ours and you have access to the multi-dev feature, you have access to Nex.js. Uh, and we have these great starter kits that I want to turn it over to Will to sort of show off if you're new to this world and you want to explore what's possible. Um, he's done some great work to make that really easy, uh, to to get started quickly. So, let's break for that demo. Okay. So, can everybody see the screen? >> Yep. Perfect. Uh, so yeah, this is uh one of our early previews of our uh starter kit demos. And uh this is a basic uh sort of one to one. So, one Drupal site, one uh Nex.js site. And with this uh we are serving the content from Drupal. So, I'm already logged into Drupal. I've already got it set up. It's a uh pretty quick install process. There's a um custom profile, standard Drupal installation process. Uh but uh this is what it looks like when it first gets started. And we've went ahead and added some sample content. Um and these are these nodes are articles, events, and basic pages. So article and basic page are just what comes out of the box of Drupal normally, but we've added an additional content type for uh our events. And if we look at uh one of these and just edit, this is the one I was looking at earlier, but um standard editorial experience, you know, we have our title, our body, uh we have an additional field for our image and uh an additional field for our tags. And on the Nex.js side, when the site is built, it is uh there's different ways to set this up. The way we have this demo set up is that it'll query uh the Drupal site and grab all the content, pull that down and index um some of the static pages, but then also some of the um content that would be updated more frequently such as events and articles. Uh those would um uh be able to be uh they're not static, so you would be able to edit that within the Drupal site and see the the updates in real time. Uh so on this page for example um this is just our post page. But if I go into this how to choose uh the right digital experience platform and um this is the the content here. If I go back to my Pantheon site, this is the the article and uh just making a small change. I'll add an extra period here and save. What that's going to do is um just make that content available for the nextJS site. So if I scroll down, I'll see that my one little period change for for quick demos uh was successful. Um and we can see that here. And uh this is again completely apart from uh the Drupal site. Um the uh URLs are managed. So if we go here, it's the same URL. Uh so the same path for the content is what would be posted here. And um and this works for the rest of the content too. So we go to events. Uh we have our go live event that's coming up uh later this year in October. Uh if we go here, this is the content here. But the nice thing about this is that it does separate um the front end from Drupal. Uh so there's a lot that we could set up with Drupal. Um again, this is a a quick demo just to kind of show you how everything is wired together. Um and uh from there, there's just a few modules that are enabled. Um there is the uh next module and uh that uh has a pretty quick configuration. Uh you would just typically add a next.js JS site and uh give it a name, give it a base URL. There's the draft URL and secret uh as well as the revalidation URL and secret. Uh part of our uh starter kits is that that custom installer will handle some of that for you. It'll provide you with the ver the um secrets needed to copy into your clipboard and paste over into the um the site creation process with the Pantheon, but it makes it really simple just to kind of get things going. Uh so you could be up and running uh in 30 minutes or less um between with the headless headless uh Drupal site with Nex.js and then we would go into our content types and this is where you would set up and you know content type specific uh revalidation. So I have all three set up here and just taking a look at uh some of the configuration you're able to target which sites because one of the things that's cool about uh this setup um typically when you're working on a website you have you know the the the monolithic site you have the front end and the back end all working together. The nice thing about having it separate is that uh now we have a Drupal site that has content, but we could have multiple front-end sites. And uh the cool thing there is you could have multiple channels and it doesn't ne necessarily have to be a website. It can also be a mobile app. It could be um I've seen some folks use digital signage um in you know physical locations. uh all this content could be saved within Drupal and then uh made available to those other applications uh to uh consume and to demon you know display um whether it be a website, a digital billboard or or a mobile app. Um and it's it's a nice way to make make more of your content, especially if you already have a lot of content that's already in your site. Uh so if you have a a pre-existing Drupal site, um one of the things that we did with our demos is we focused on uh you you know leveraging a lot of the great functionality that's coming out of Drupal. Uh so one of them being the the recipe initiative and recipe API. Uh so this is built entirely with recipes. So the initial setup with the configuration is with recipes, but in our case for our demo, we also have our content that's being added in recipes to to speed things up a bit. Um but uh it's really simple to grab that recipe and uh add it to an existing site to add that base configuration if you wanted to go ahead and start playing around around with uh Next.js using that content that you already have within your site uh making that available to a new front end. So it's something that you could really explore if you're already into it like if you especially if you already have a Drupal site um and uh but if you want to get started uh from scratch we have plenty of starter kits that we'll show you along the way. And just to underline that, well, the I thought that was really cool the way you set this up. So the we have a if you don't have anything and you just want to play with this stuff, we've got this sort of complete end toend setup. Copy and paste the secrets and you get this essentially can get the site that you're looking at right now with some demo content in it um in like you know 30 minutes or less. But also you built this with recipes and the the the core of just adding all the the um the API components is its own sort of very simple recipe that could be added to an existing Drupal site. So if you just wanted to experiment with I've got a site, I've got my content. What would it be like to expose that to a modern frontend? This is a way to do that. And again like you could do that in a in a sandbox in a in a dev environment, in a multi-dev environment. It's a way to to sort of get your feet wet with this. Uh that's that's pretty easy. >> Absolutely. Yeah. Another thing too is that our all of our starter kits come prepackaged with uh DDEV as well. So um the the there's multiple um uh starter kits. So there's one for Drupal, another one for the next.js site. So there's two separate repos that you could um that you would be able to download and use. Both of them have DD um configuration for them. So it's really easy to get set up. Uh there are scripts provided to you. So quick setup. I mean it's one command you after the clone to uh initialize the site test it um and uh yeah and getting in and then getting in you know launching it shipping it out to Pantheon just a few more uh commands. So um you know between uh Terminus and uh the dashboard it's really easy to get started and yeah especially with you know pre-existing sites. So if you already have content built up um and you are looking to explore it to see what that looks like you can grab one of our recipes try it out. It's a quick Drush command to install it and enable it. Um may need to do a little bit more tweaks. So like there's um if you're installing the Drush command, it will ask you for uh your URL. So like what is your your backend URL that you're um or your sorry your front end URL because part of that setup with um uh Nex.js or with the Nex.js module uh is that you would add your site. So um it would you know it's this configuration that she would have to add, but it's it's very quick. So it's and it's for the most part it's just what's the URL and uh API draft that's pretty static. Uh your key you probably want to get a stronger key than next.js Drupal. Um we our starter kits uh when you install them uh they will uh automatically this is one I created before we added that additional cryptography but um it'll automatically create those revalidation keys and secret keys for you. Um and then as well as give you the environment variables that are typically available to you here on um you know once it's set up but we make that available to you on the initial setup too. So just makes it reduces that friction just from getting started um you know by a lot. So >> cool. Thanks Will. um really appreciate this and and like I would uh just for anybody who's excited about this, it's also um we're uh at the beginning of building this um I'd say like um I can throw if you don't mind I'll throw my screen back up. Um like I'm just convinced that the the future of the web is going to involve building more and more things this way. Uh, I think like we're going to move into a post theming era of Drupal and there's going to be two different ways that that happens. Like they're not unrelated, but I think they'll they'll be distinct. Like I think there's an amazing amount of work being put into, you know, sort of Drupal CMS and recipes and the marketplace and all these things. It's this batteriesinccluded experience where you have everything you need in one simple package. Uh, and everybody can be happy with that. You know, pick a recipe, build from there with canvas. you can there's some AI embedded in there you can use um it really empowers editors to do a lot on their own and I think like in the perfect world you get to a point where it doesn't require any custom code uh for implementation and people aren't thinking about the universe of modules which can be somewhat confusing to lay people and they're thinking more in terms of these recipes and things and that's a super exciting future for Drupal to to be able to deliver everything you need in one package and then I think there's this other approach which is going to be in combination which today I'm I'm we're for foregrounding Nex.js but really it's just that componentdriven front end and making those things fit together really easily in a way that's easy to govern where where you're going to have dev teams probably on your front end and on your back end. Um and those dev teams are are they're both getting everything they want from the experience and your content editors are getting everything they want from the experience. This is where, you know, people are really trying to push the envelope with what that experience is to the end users or where they're sourcing their data from or if there's deep interactivity, what that results in. You know, that's not something that you're just going to install a recipe and necessarily get out of the box. Um, there's going to be real development work put in on the front end, on the back end, on those integrations, but we're going to do it in a way that, you know, is a lot more easy to get started with, a lot more structured. I think we know a lot more now based on the past 10 years experience of what good pipelines look like, how to structure caching and the CDN. Um, you know, other sort of common pain points from the sort of first wave, maybe not even the first wave, but from that that first big push into decoupled. Uh, and and I think we're going to be able to show people sort of the better way uh to do this. Um, which I'm I'm really excited about. And and I see there's a question in there which is a really good one that we should get to. Um but just you know I think throwing out our opinions um um you know from the Pantheon perspective you could have your own. I think when people are thinking about the the the world of decoupling and if they want to if it seems like they want to take advantage of full advantage of modern front end. I think these lessons are evergreen and they apply honestly to any technology. Like I could I could put these slides up for a you know if I was doing the same an equivalent talk to a WordPress audience, right? Or or or to someone who's thinking about doing it all from scratch, god forbid. Um you know like first things first know why you're getting into this. I think a lot of times we end up in situations where technology decisions are driven by technology enthusiasm and it often doesn't end well because the um the desire to move towards new and innovative things is understandable but if you can't ground it in a strategic rationale um you may end up missing the mark or ending up realizing that you don't have all the allies you need or realizing that there's no long-term commitment to what you tried to do. So really, I think as a uh, you know, this is one of my gray beard moments. It's like make sure that you have your team behind you and that we all understand what we're getting out of something versus it's going to be cool. Like it should be cool, but you have to articulate it a little bit more fully than that. >> Yeah. There's a lot of hype chasing that happens where where the new hotness comes out in terms of the technology and and a lot of times uh folks want to adopt it for adoption's sake and and it's really important to take that step back and say there's real value to adopting it if we do it in the right way and that's and that's what we need to pursue. 100% 100%. >> Absolutely. >> Um I also want to call out I do see a raised hand I think from Hashim in uh the chat. Please use the Q&A button uh which will be in the toolbar at the bottom. You might have to hit the more button. you can throw your question in that way. >> And the other two things I think about this are, you know, um just not missing out on the rigor around managing multiple code pipelines. Like I think the the in this world of the coupled and you know making modern front-end developers and and Drupal or other backend developers all happy, it's kind of like everybody is actually doing like in a perfect world, they all want to be able to do their own DevOps and they should, right? They should have their own testing frameworks. they should have their own automation. Um, and kind of giving, you know, not making either of those uh sides of the development equation be the winner or the loser or the first class or the, you know, the the the second class citizen uh is is super important because if one of those two parties ends up having to compromise a lot, they're they're not going to do their best work. They're probably going to be grumpy about the whole thing and that again erodess the the both the technical and the human dynamics around these projects. And then the last piece is like, you know, not only do you need to make all the developers happy, but again, it's it's just worth hitting over and over again. If we're in the B business of managing content and creating things that go out on the web, the there are going to be lots of people that need to do that that are not developers. the editorial user experience is um is existential to any one of these projects because if it's not intuitive, if it's not pleasant to use, if people are afraid to create with it because they're not sure how it works, it will just won't be adopted. And if you put a bunch there's nothing worse than putting a bunch of time and energy into building out some technology or some solution and then realizing that it's not being adopted. So I think sometimes we we end up because these other two ch the the the technical challenges can can be so uh difficult. We end up running out of time or running out of budget before we really get to thinking about the editors and the admins. But but that is you can't you can't you have to almost put those people first uh and make sure that they're happy with what you're doing well before you get to the point of trying to launch something. You bring them in early in the process. Make sure their needs are really being met and validate that along the way. And I think that reinforces some of the things that we've said earlier, which is to say like again 20 25 years ago even right when you're starting from PHP development and frameworks like Drupal, we were originally thinking not outside in but inside out. We were thinking about the fundamentals of content structure. We were thinking about the the um content types and how to construct views and what the API layers might be all all sorts of things. And like you say, it could come into the situation where it's like all the UX gets squeezed in with the dregs of the budget. Um, but one of the great things about that JavaScript generation of developers is they've they've already started thinking about it in totally the opposite way with this more outside in approach. And um the other kind of interesting consequence of that is because that has been the dominant development mode during the emergence of AI, most of what AI is trained on doing follows that model. It follows these patterns that it's learned from the more common JavaScript development world of of this sort of outside in focusing on sort of UX component experience things. So, so we're finding that inversion of priorities towards uh front-end look and feel and towards editorial experience happening in the emerging tools and um figuring out how to enable them by again your previous slide was awesome about showing the the canvas versus the um the kind of um uh uh front end uh oh not front end what I leading edge is what I mean of of other development and this speaks to the maturity of headless solutions and decoupled solutions. Right. Um as you as you said sort of 10 years ago there was a lot more of like the science experiment of how to do that and um now there's a lot more sort of alignment of patterns and standardization of patterns and and ways of doing things and more separation of concerns so that you don't have to have all that expertise at once. So I think that's I think that's really good. And um I won't go too far into this because we're going to go to a couple calls to action for y'all in the Q&A in a second here, but speaking of the AI side of things, um >> there's a lot of interesting things coming up on that front as well and a lot of things interesting things of course that already exist. It seems like not just daytoday, but even like every six hours something new comes out related to this. It's there's a lot of shifting sands and a lot of change. Um but there are some really cool developments coming up that relate to how we kind of accelerate this and also towards how we guide AI towards um more rational structures and towards I think you used the word durability. Uh Josh earlier because we've seen the ability of AI to generate vibecoded beautiful gorgeous but kind of throwaway non-durable sites. um whereas building uh things that are actually durable in the long term is something that there's uh some emerging techniques. So in our our next webinar we're going to be talking a lot more about that. Um and I think that's going to be really really interesting. >> Yeah, I'm excited to do that. Um we'll be talking um just kind of what's going on in general and then again the Pantheon perspective. We're very closely partnered with Google Cloud Platform and I think their AI strategy is is and it's their own fault, but but it's misunderstood uh by most of the market at the moment because people just see it as like this this like three-way model race between, you know, the anthropic OpenAI and Gemini when in reality what they're doing is actually much more interesting than that. Like Gemini is cool, but like the actual Google Cloud Platform approach to AI is really really um exciting to me. And then that's my sandbox to figure out how to apply that to Drupal. And again, there's this there's these multiple dynamics. There's inside out, there's outside in uh when you when you think of AI and a lot of uh exciting stuff happening there. We're also building towards some cool demos for Roderdam. But hopefully we'll be able to showcase some of that ahead of that in uh in the next few weeks uh with you. Um so yeah, definitely looking forward to that. So stay tuned. More webinars, more cool stuff coming. Um, and like the calls to action here, like we it's like that's probably we've talked about all this over and over again. We don't need to belver the point. It's easy to get started on this stuff with Pantheon. Um, again, if you have access to multev, you have access to Nex.js. Uh, Tim uh Will's got his uh starter kits, which we're actually previewing a little bit here right now. They're not being pushed out yet, but they they will be, and if you want to get access to them, you can you can find them today. But we're going to start blasting all that stuff out in the coming weeks. Um we have a team on our side that's here to help if you want uh to talk about migrating some things or just doing an office hours to to spitball and then we are bringing in you know we use the Drupal cons as a natural rhythm milestone for us to bring a bunch of things to to market uh and so we're going to have a lot to share and show at Drupalcon Roderdam and the team will be there uh and happy to meet people live but um let's let's get off screen and get into um the the question I Tim put in there is uh Tim Sharp, sorry. Uh was a was a really good one and it speaks to >> um I'll answer this a little bit and then Will maybe you can chime in um a bit as well. >> Let me iterate the question out loud for the sake of recording and people people listening that way. So Tim Sharp asks, are we able to create visual page building experiences for our users with NextJS Next.js? Does that replace canvas? Does it somehow work with it? What's the how how do we capture that in the kind of decoupled context? >> Yes. So, um what we showed today in the demo that that Will was showing is not that yet. So, what we're showing now is sort of the the sort of fundamental any Drupal site could take advantage of this because you have a bunch of structured content and you want to make it available to be um uh rendered using modern front-end technology because that's how you're building the user experience. uh but you just have your sort of like Drupal as as it's been throughout most of its history with great structured data in nodes. what is possible and we're I'm looking forward to being able to demo um by Roderdam uh maybe sooner um is a world where because the the language of canvas in components and single directory components and the language of modern front end in react components is actually the same thing. We are now finally at this kind of magical moment that many have uh envisioned for a long time where it's the same code on both sides. Literally the same code on both sides. And now you can then easily see a world where I'm using canvas to manage a layout and maybe like not necessarily just thinking in terms of the node edit form and like structured content there, but I'm using canvas to think about what goes where on a page and what properties have what settings. It's a different mindset for how the data is structured, but that can be very easily and naturally exposed to a modern front end that just renders it all natively uh in its modern front-end way uh to the end user. And there's um there's uh some work to be done solidifying that sort of what would be a you would you would call an API contract between the the front end and and that back end. Um but that is um it's it's fairly the it's fairly straightforward it the because again we are using the same code in both places and this this sort of language around components and their properties is spoken on both ends then it's just a matter of like uh essentially having a little Nex.js package that you can do npm install and it knows how to uh essentially get its marching orders uh from Drupal canvas. And on the other side, there's an easy way on the Drupal end to run a Drush command or or something that just reads from a design system and populates canvas with the right set of components and the right set of properties to so that a human can drag and drop wherever they need wherever and then they have the right uh bits that are editable or not editable. Right? That's the other thing about this this world where you have the library of components defined in a design system. It's not the wild west. You can say this can be edited, this can't be edited, this is an appropriate color selection, this is not an appropriate color selection. You cannot change the font to comic sands. Uh and uh and so getting those two components both the the the way to set the contract and then manage it from front to back and back to front is like that is a we are inches away from that being fully automated. And once that's done, it's going to be so easy to set up projects that leverage both of these tools to their fullest ability and give the developers who work on both sides of the line everything they want. I think it's going to be amazing. It's going to be magic. >> Yeah. Will, do you have something to add to that? >> Yeah, I I think Josh, you said it very well. It's very well said. Uh, one thing I would like to mention too, there is there are with our templates, one of the things that I'm looking into is exactly that being able to get more par between bridging that gap between [clears throat] Drupal and Next a bit more. Um, there are a few plugins uh there's like a CLI tool that's fairly new for um managing uh Drupal canvas uh components. So having that would actually or having a comp a tool like that uh would go a long way for being able to uh keep those in sync. uh making it to where you could reliably be building your um components from the Drupal site and then being able to push that out to the uh Nex.js site. Um but yeah, it's some currently it's not implemented yet, but it's on our radar and we're very excited about it. >> It looks like we got one one more good question from from uh the audience. Quick quickly before we get to that, I do want to also add one of the really exciting things about this is this is something where the community at large is rowing in the same direction, right? So, as Josh already alluded to, right, a canvas is is is using some of these same fundamental ideas that also enable what we're talking about with next and all of these other kinds of things. And I I happen to know that the Drupal CMS team is also looking when they're looking at their recipes for site templates, they're also looking at can we construct a headless starting site template. And all of these kinds of things that can work together, which means that this is less of a situation of are you picking paragraphs, display suite, layout build, it's less of one of those kinds of divergences and more of a we're all kind of collectively adopting this as a standard. And I think that's an important thing to note as you explore this um that you can have more confidence in it. Yeah. Couple more questions from from Tim Sharp. I'll go to the the first one. Will, this is for you. You mentioned being able to connect to multiple sites and applications. Um yeah. Uh could you could you give some examples of what that would work and and approximately the how we don't have a huge amount of time, but a quick overview? >> Yeah. Yeah. Uh so very quick the uh configuration I was showing and I see if I can share it real real fast here because I still have it up. um here. So if we come back to the Nex.js configuration, when we add a site, uh it's as simple as adding a site. Uh now you need a site in order to um you know receive that information. But as far as a Drupal side, uh if you come in here and add a new site, you give it a label uh and give it a base URL of what the new site would be. um the draft URL and the secrets uh those could mostly be shared between the environments. Um not not a good practice to do that, but to get it going and test it out locally. Um the main thing is just the the URL. That's the thing. But if you want to be able to test the draft and the functionality of um being able to edit content and seeing that, you know, as a as a draft mode, uh you would need to add a little bit more. Um on the Nex.js side of things, whenever you're setting up the site, uh there are the secrets. So similar to like local invariables or environment variables for a next.js site or node application. Um those variables uh for this the second um you for the example of a website for the second next.js site would just have the um the backend URL and they would all use the same backend URL. And um and then and as far as setting it up with uh other applications as far as um you know like web or mobile applications or you know I think the other example I gave was digital signage. It's just however you're managing your environment variables there. You would just be able to call back to uh the back end URL. >> Yeah. So you know I can I I can think of a few examples as well like the digital signage one is a big obvious one. various kinds of use cases I've seen in the higher ed space for example where you have um course registrations and all this stuff that all the students are doing and then you have digital signage in your lecture halls or outside your classrooms that are showing which courses are there and all that kind of stuff. That's that's a kind of common type of case that the more advanced um uh IT departments in some universities are are starting to explore. Um, and there's there's other kinds of things that could be could also be in that same higher ed use case, but in sort of government or or um other kind of uh constituent engagement management platforms where you might have a site that is the the the front end for users to interact with some information and you might want an entirely separate one which is almost not exactly an internet but an internal portal for accessing that same kind of stuff. that might have different types of interactions. Maybe it exposes more sort of bulk reporting data and things like that as opposed to a user interface for individual users. There's a variety of kinds of things. Um, and I'm sure many many more that um, a lot of creative folks have explored. Um, one more question. Thanks again, Tim. And I think this is probably what we have time for. just on the headless demo. Um, it didn't it didn't expose an edit button that would get people back to that that back end in Drupal where they would actually make those changes. Um, so what are what are sort of the solutions like that or how do you change or like what's kind of just again this is sort of a user experience question. What do you imagine is the kind of the best practice for making sure your editors can find what they need as easily as the end users can find what they need [snorts] >> and will or Josh? Yeah. >> Yeah, absolutely. That's a great question. Um, and one that you're used to. I mean, typically if you're on a Drupal site, you would you have your view tab and your edit tab and being able to quickly edit that content. One of the things that we would need to do on the NextJS side is authenticate or be able to associate your session on the Next.js GS site with a session, you know, with an actual user in Drupal. Um, the starter kits themselves don't have that baked into it yet. Um, got some plans to eventually have that. But, uh, once you have the authentication, uh, piece there and you're able to authenticate, then you could add components for, um, you being able to edit the content to be able to go back into the back end that would only be visible to um, that authenticated user. And um and using that same connection and the same API um and you know user uh the user APIs within Drupal, you would be able to um you know do things like show gated content or show dynamic content for that specific user. Um but uh yeah, it's out of the box it's a little bit more setup. Um but uh it's not much more. >> Yeah. And I'm going to sneak in one more here and then we'll truly wrap up. So Wen makes a good point um just his commentary really which is just that Nex.js JS is great, but the people editing the site will be non-technical and the need for that visual page builder will be um really important and at the moment that may keep a lot of people closer to canvas or site studio than things like Nex.js and I think there's an important point to make here which is Nex.js is for building that front-end component layer. That doesn't mean that the content editors are being told they need to become JavaScript experts, right? the user interface for them is still ultimately going to be I think in most cases something like what Josh described as this this effort towards still being able to provide a visual site editor whether that's canvas directly with some kind of new API layer that makes it work in this decoupled environment or whether that's you know some other sort of visual site builder um but yeah that's definitely still known so in a to some degree just to clarify um because I think it relates to your comment wa we There there are sort of three of these personas. There's a there's a a maybe a backend developer persona, a front-end Nex.js developer persona. Sometimes those are the same, and an editor persona. And they they definitely all have those distinct needs that need to be accommodated here. Yeah. And and in a lot of cases to be honest the um the reality of um landing page building is is a infrequent operation whereas you know creating managing events managing the kind of uh structured content that Drupal's always been good at is the day-to-day operation for editors and we didn't show it here but it was up in the comments. One of the things that's really changed in the past few years is the way in which you do drafts and previews has become really well well trodd territory. So one of the things that used to be a problem is I'm I'm working on an event or I'm working on a blog post and I like literally have no idea what it's going to look like if I hit post. Uh now you can get through that uh really easily. And uh and then the next frontier is yes what about assembling a page that's not a piece of content but it's a pastiche of many pieces of content and so forth. that is that is what the uh is being worked on right now and I'm hoping we'll be in a place to demo uh demo soon. So stay tuned for more. >> Awesome. So with that I think that puts us in a really great place to wrap up. So I want to thank my co-presenters Josh and Will for um bringing this content to you all and to those of you listening to the recording. Speaking again of which we will be sending this recording to all registrants and you're also welcome to share it with anybody else. Um, and uh, I think we'll send over the slides and um, you'll be able to reach out to contacts um, I think either it'll be in the slides or somewhere else uh, with Pantheon if especially if you're already a customer and you want to try out those starter starter kits that will showed off and things like that. And um, I want to encourage you look forward to the next webinar where we again have some pretty cool um, things being set up around how the architecture of emerging AI tools can integrate into this. And I would love to invite you all to Drupalcon Roderdam uh coming up uh just towards the end of September. So if you haven't seen that yet, you can go to events.rupal.org, get registered and we would love love love to see you there. So thanks again everybody and uh we'll let you go for now. Have a great rest of your day. >> Thanks all. >> Thanks everybody. >> Bye-bye. Bye.