 Hello everybody and welcome to the headless and the content authoring experience roundtable. I'm Kim Pepper, tech director and co-founder of previous Next. Today's roundtable will be kicked off with a presentation by Stuart Clark. Stuart is the senior developer at Reality Loop and has been actively involved in the Drupal community in Australia and internationally for more than 15 years. More recently his focus has moved to decoupled Drupal development and is the project lead of the Juxt.js framework. So following Stuart's initial presentation, we're going to do a roundtable discussion. So it's a slightly different format from what you've had today. We've actually got a number of esteemed panelists who are waiting and ready to join at the end of that talk. But we'd also like you to participate by asking questions in the Q&A tab at any time. Then during that discussion session I can do my best to add you to the stage to ask your questions. So this has to be one at a time. So we'll just see how we go with that. We might end up just me reading those questions out. This roundtable is sponsored by previous Next. And previous Next are a team of Drupal design development and hosting experts located here in Australia. And as you might have heard Dries mention in the keynote where long-time contributors to the Drupal projects in terms of code contribution, community organisation and helping to run events such as Drupal South. We're also a sponsor of the Code Sprint tomorrow which I hope you will attend. I'd also like to take this opportunity to mention currently hiring front-end and back-end developers. So contact us through our website or send an email to jobs at previousnext.com.au if you're interested. So with that, over to you Stuart. Thank you very much, Kim. Good afternoon everyone. I am Stuart Clark and this is Headless and the content authoring experience. I am a Drupal developer as Kim said at Reality Loop and I've been using Drupal for about 15 years. And as of recent, again, as Kim said, I have been working on a fully decoupled Drupal framework called DRUXT. That's generally what you'll find me talking about. So again, as Kim said, the format today is we're going to have an open discussion after this initial lightning talk. I do encourage everyone to talk amongst yourselves in the discussion forum, use the live Q&A and get involved in some way in the conversation as a whole. So this is what I'm going to be covering today. A little bit about the terminology about headless, decoupled Drupal as it stands. The technology including, of course, DRUXT and go through some demo before we go into a discussion. So the terminology, the first thing I want to talk about is the traditional CMS and that's something that everyone should have some understanding of because the traditional CMS is really just Drupal. It's Drupal running in a lampstack and the idea is that your content authoring, your content rendering and your content storage is all done in Drupal. And it's powerful. Like you can't deny that Drupal as a content management system is an amazing thing. But as the technology in the front end realm advances, Drupal needs some form of decoupling so it can use that technology. Progressive decoupling is one of the more common ways of doing that. It's something that I personally don't have a huge amount of experience with. So that as part of the discussion today, I'm going to bring in some guests who have more experience that they can provide some context. But progressive decoupling is very much like your traditional CMS. The idea is still Drupal running inside of a lampstack. It's still the content authoring is done inside of Drupal. The content rendering is done inside of Drupal with the assistance of JavaScript. And the content storage is still inside of Drupal. This image on the slide you can see here is taken from a, I believe from a blog post by Matteo from Lullabot's progressive decoupling made easy. And this is an example of using progressive decoupling on the authoring experience. So the ability to drag and drop JavaScript blocks into the interface. The alternative to progressive decoupling, which I do have more experience with is fully decoupling. And fully decoupling changes the architecture a little bit, because you're no longer rendering your content inside of Drupal. You are doing your content authoring in Drupal. You're doing your content storage in Drupal. But the content rendering is done inside of a Jamstack. Be that Gatsby or Druxed or any of the available frameworks on the market. And this gives you a lot of control over what you want to do with the rendering layer. A lot more control because you can just use your view or react components directly in rather than trying to move them inside of Drupal's rendering system. You have control of the router system. So you can have components that live outside of the router system. And it can take the full advantage of the front-end framework in that case. So, you know, next or next or Druxed. And unfortunately, the downside to this fully decoupled approach is that there's not as much skill transference. You don't have to know Drupal to go fully decoupled. It's kind of the point. So that does mean that your Drupal developers who have a large amount of experience building front-ends within Drupal, that knowledge doesn't necessarily transfer. Although it can. And the other side of fully decoupled is that it doesn't necessarily have to be content authoring in Drupal as well. It can be content authoring in the front-end. And that's headless. So this is one of the reasons that I wanted to talk about terminology first is I see a lot of different opinions on what headless is and what decoupled is. A decoupled site doesn't have to be headless, but a headless site has to be decoupled. Because if you're still doing your content authoring in Drupal, it's not headless. It's simply decoupled. So the idea of decoupled, of headless, sorry, is fully decoupled plus a decoupled authoring experience. Hence the title of the topic today. And this here is just an example of a prototype that I've been building alongside this session. And I will go through shortly. But the idea here is that Drupal and your database still lives in your LAMP stack. Your jam stack is where the author comes to make their changes. So editing on the front-end. However, the important thing to take from this, and it's not in this graph here, is that your authoring front-end does not necessarily have to be your display front-end. So the benefit of decoupled, the benefit of headless, is the ability to have multiple different applications for multiple different purposes. Decouple the presentation layer and you get a front-end. Decouple the authentication layer and you get an authoring experience that can potentially be taken offline and taken with your content authors instead of coupling it to your presentation layer or coupling it to your content management system. So the last one that I wanted to touch on is serverless. And serverless is, this is my concept of serverless around the idea of Drupal and the idea of fully decoupled headless. And this is something that I put together for a talk recently in Drupal Camp Colorado on using Tome as a way to do static things, but not necessarily Tome as a static site generator. So Tome is a Drupal module that lives in the back-end. So if we have a look at this chart here, we can see we're doing content authoring in the Jamstack and we're doing content rendering in the Jamstack. But to make this serverless, Drupal itself along with the database and a module called Tomesync is running inside of a Gitpod instance, which is a cloud IDE. So that means that you can spin up an instance of Drupal with your content coming from Tomesync into your database inside of Drupal. So you can do the development as the author within the Gitpod instance, make all the changes you need to, and then deploy that static content to Netlify. After doing so, you can then turn off this whole Gitpod instance here. And that results in Drupal not running in any way whatsoever, but a fully deployed static site running on Netlify that a user can browse to. I'm not going to give you a demonstration of some of that, but I'm going to risk trying to do some live demos if time permits. I'm going to jump to the technology before I do that and talk a little bit about Drust itself. So Drust is a fully decoupled Drupal framework. It is open source. It's all at drust.org. There's some links in the end that you can have a look at as well. It provides server-side rendering and client-side rendering using the Nuxt.js front-end framework, which is built off of UJS. It also is a static site generator, but it's a Drupal-centric framework. So it has support for things like entities with schema support so that you can manage your displays in your Drupal instance, but have the front-end understand how Drupal wants your content to actually be rendered. So support for decoupled menus, decoupled blocks, decoupled views, and a decoupled content authoring experience as well. I would be remiss if I didn't mention Gatsby. However, I have never actually personally used Gatsby. So again, I have people with me today who can hopefully talk to this a little better than I can. But Gatsby is another highly popular static site builder that uses React instead of View. And it has strong Drupal integration. I mean, most people who have worked in the decoupled space know of Gatsby. So I probably don't need to go on more about that. And lastly, as we're running low on time already, I think, here's some resources that I will leave on screen. But I'm going to jump across to a quick demo. So this is a Git pod that I'm running at the moment. And it contains a running instance of Drupal and a, that was there, and a running instance of Nuxt. So this is the Drupal site here that you can see. And this is running from within this pod. This is a front-end, which I will reload, that is consuming the data from that backend. So you can see here two pieces of content and a whole bunch of stuff inside of it. So if we have a look, the whole idea of headless is that you have to be able to edit your content in the front-end rather than the back-end. So I can just double-click here. And that opens the editing experience and loads in this particular form. This here is built up with paragraphs. So this here is a paragraph field. And we can drag and drop these around as you are doing paragraphs. And we can close that to have a look at what it would look like once we've made the change. We can click this instead of double-clicking. We can change the title here, test one, two, three. And we can also add additional paragraphs. So as long as your site is configured correctly in Drupal, this can consume the data that you've made available to it so that we can just add in some additional things here. And you can either edit them up here or down here, although this is still a proof of concept. So it's not a fully fledged product, but it's an example of one of the approaches that could be used to build headless sites with Dructs as a framework. To follow on from that, if I just hit save, that probably won't work entirely, but I'm going to have a look at the back end here. And I'm going to go into this tab here. And I don't think it did save because it's a prototype. I'm just going to reload and do one more test. And if I get a second demo fail, I will not do it again. So I'm just going to change the title of this and go, hello world, how are you? And I'm going to go down here and hit save. And if that worked, there shouldn't be any display because I haven't built it yet, but that did work. So now we can see here that in the back end, this is actually posted to Drupal. And Drupal via the Tome Sync module is automatically exporting the files that have been updated. So the node has been updated. And if you have a look here, you can see the title has been updated. And now as the site builder or the person running this particular instance of Drupal, I have the choice to actually commit these changes so that next time when I spin up an environment from this particular code base, that content is there and ready to go. So the last thing I just wanted to show before we get to the discussion phase is just a couple other little authoring experience experiments I have done with this technology in the recent. So there's two here. This is the Drugs.js YouTube channel. Please like and subscribe so I can have a better name space. But at the moment, 21 subscribers at channel slash whatever that is. Link will be in the end of the slides. So this here is an example of a site building experience. So this is not content authoring per se, but it's the idea of being able to drag and drop your regions from a sidebar on a front end wherever you want and move them around. And it gives you an exact demonstration of what they actually look like live. And if these are supposed to look different in different places, they will look that way as you move them around. On content, however, this is an experiment called the edit bar, which is very similar same sort of concept book. I'm just going to turn off. I have extra audio coming through. Is that me? Let's go again. Okay, so let's have a look at that. And we can see that this gives you a live reactive editing experience within your actual piece of content. So one of the biggest issues I hear from content teams is previews, especially with decoupled. And I've seen many different iterations of preview systems built within Drupal to show you what your decoupled site should look like. I haven't personally gone that approach because I don't believe in the future that people will be building their content in the back end of Drupal. They'll be doing it in the front end in some manner or a front end. So this way, instead of having to build a preview system into Drupal, you just see the changes live. So that's pretty much it. I think lightning talk wise, I think we can go back to you. Okay, I don't know if I... Okay, thanks, Stuart. Okay, so now we get to the discussion part of this session. And I guess people will be getting added to the screen shortly, but as they are, I'll introduce some of their panellists. So we have Jack Taranto, who's a senior front end developer at previous Next. Max Pokanowski, who's application architect at Intermedium. We've got Brian Gilbert, who's a polymath and also a founder of Reality Loop. We've got Si Hobbs, who's solutions architect at NewSouthWales.gov.au and finally Lee Rollins, who's a Drupal core commuter, a member of the security team and lead developer at previous Next. Welcome everybody. Yeah, so this is the part where you get to ask questions. The overall intent of this is to kind of try to simulate a bof where we're all in a room in a round circle and we're all having chats and discussions. So it's not meant to be like a presentation that's supposed to be more of a discussion. So yeah, please go ahead and ask your questions. And maybe the panellists want to kick off with any questions that they might have of their own or comments that they have on their own. I guess I'll try and start something. So I'd be interested to hear what the others have to say about the various approaches they have. I'm going to assume that most of us use probably a paragraph-based approach to content layout. And like for us, I think we find that it's a really good balance between having a lot of control over flexibility but still constraining the design intent so that content editors can't break out of that and mess up the front-end of the site. And now with Drugs, we get even more value for that because it's component-based. We can reuse those components, which you can do in Tweeg, but it's so much better in the front-end. So yeah, discuss. Can I ask directly to Lee then? Lee, from your side on what Brian said, like how do you approach things with Gatsby in the case of content authoring and that side? Yeah. So yeah, with Gatsby, paragraphs is what we use for that. You're kind of limited to a... with templates for how you're going to lay things out so you know ahead of time that this particular paragraph is going to go here or they're going to be all used in sequence. And when you make your GraphQL queries back to Drupal with Gatsby, you're only doing that in your components to render them in place. So whilst traditionally you'd be used to using paragraphs or layout builder and having full control over the order of the components with something like Gatsby because the React template defines where things go. You know, you're going to make scope to queries and fetching the data that you need to go there. But yeah, so before you had drag and dropping things around that's something that you're going to do with Gatsby because the order of content is going to be dictated by what you've got in your React component. Yeah. Yeah, that's an interesting point and I was going to ask that which is the approach that I've taken in Dructs is to try and use as much of the information from Drupal as possible and use it to direct what happens on the front end but not necessarily restricted to either like as you say, React components. With Dructs you've got wrapper components for each level. So an entity display types, you'd have a template, a view component for entity node article default and entity node article teaser, etc. But it still allows for the back end to have a say if the front end wants to listen to what the back end has to say. Which opens up the ability for site building still to exist without necessarily cutting it out at the front end. Okay, I've got a question from the audience. So Tini asks, anyone have any live production headless Drupal sites? And I assume that by that it means like using the full... Yeah. Brian raises his hand. No, no, I was going to say just again to clarify decouple does not mean headless. Yeah. That's a very important part. So are we asking headless? Yeah, that was the question. It said headless and I assume that's what the question was. Because I'm assuming there's plenty of decoupled Drupal sites out there. The one example which isn't necessarily great because it didn't, after it was deployed it didn't have a huge amount of buying actually bad things about it. So it's like, you know, it's a good... But the work safe Victoria site that was basically JSON API with a view front end. So the full Drupal site but it had the editing back end. That's one example that's live. It's still live. It's been live for a few years. Very fast in terms of the searching hits solar directly. So the search aspects are really, really fast. But some of the maturity around maintaining platforms like that especially when a lot of it was hosted on Acquia and the tools that Acquia provided was before it's time for sure. It was trying to deliver on a brief and perhaps should have pushed back on the brief but it worked. I am curious to hear as well though like headless headless like if there is anyone doing content editing in the front end with Drupal as a production or close to production sort of thing. Yes. Yes. Speak. Yeah. It's not a public site. It's a business application for the company I work for. But we're very close to fully releasing the data editing framework. So Drupal is handling all of the data entity model using the entity model in Drupal handles all the permissions. We've got GraphQL doing the API and we utilized a data editing JavaScript framework called DevExtreme that allows us to work with that data in tables and lists and hierarchical breeze and all kinds of fun things. And so we can point that through GraphQL at our Drupal database and our staff can edit the data directly on the front end and it's working really well. Way better than our previous approach. What do you, this is I guess a question for the panel, but what do you see as the outstanding challenges or limitations to this approach? I know Stuart's not going to say, he's going to say none, but I'm interested in what the panel has to say. I think even if Stuart thinks it's none, it's really time or finances to do the work, really. Yeah. I agree with that. Resourcing like Drupal does a massive project. I've been working on and off really for my entire career. So I don't think there's anything that can't be done. It's just do it. That's it. And the bigger the project it is, the harder it is to get to that stage. I mean, at the moment, drugs is primarily my vision. So I've got the ability to move fast, but I'm trying to ensure that it consumes everyone's visions and does what everyone needs it to do. And as we get to that, the questions start to be about like what sort of defaults that do you need to provide? Like Squarespace and Wix and so on keep coming up. And I've been building this, I mean, myself and Brian have, has probably nearly every Drupal developer out here been working on that sort of like SaaS product for ages. Like let's make something that's easy to build sites. And I've been doing that through building a framework, but more resources, more development time, more documentation, because as Dries said, it's not about the code. The technology is great. Like I can swear by the technology, it's fantastic, but people need to be able to use these things and the project needs to be able to be managed and it needs to be presented to people so that they understand that these things are out there. So exposure, resources, that sort of thing. I'm interested to hear what Lee has to say on the Drupal backend side and what needs to be supported to allow, I guess, more of that, which content editing experience from a fully decoupled frontend? Yeah, I think one of the things that you often overlook when you throw at the baby with the bathwall that is all the things that you get for Drupal that are just a module away and a good example of that would be Webform. For example, I'm yet to see a, you know, decoupled solution that lets content editors define forms in any shape that they like. Jess, the students with his hand. You know, so these kind of things that we've sort of had for a long time take for granted to have to recreate later, but there's another one. So yeah. I guess from a... Sorry to jump in. I guess from a frontend developer's perspective, what would... I have a question for Jack. What would you see as being something that you would need in order to be able to, you know, build on top of as a frontend developer? Like, what are the foundations that you would need there to make that a good experience for frontend developers? For the... Are you talking about for the admin content editor? Yeah, I mean, ideally the whole Drupal bathroom experience would be headless, but it would be, I guess, built by the community. You know, it would be like a frontend interface that's, you know, fully decoupled, but you're basically building, you know, doing all your Drupal site building through that. That would be the dream, I think. I guess what kind of scares me when we've got headless sites is, yeah, there's no... Like, there's no standard process to how people are, you know, editing and working with sites. That's quite, you know, some applications, I guess, where you just need to send certain data back. But like, I couldn't imagine something where you're like editing layouts and paragraphs and things like that. And then, you know, looking at every Drupal site out there, having to reinvent the wheel by creating their own interfaces to do all that kind of stuff. Yes. If we're working towards a framework that ended up in core, you know, that was part of, you know, part of Drupal that we're all using, I think that'd be awesome. Can I just interject on that one? I really strongly oppose the idea of putting a framework into core. It really limits what you're going to be able to do in the future. I don't disagree on the reinventing the wheel every time. I think that's an important part. I think a framework should allow one to be used as a pure framework so you can reinvent the wheel. But two, at the same time have same defaults. And that has been one of the parts that I've strived for. But putting the framework in core will limit how things can progress in the future. There's no reason why you can't use view and react alongside one another. There's no reason why you couldn't have a view and a react front end, back end, you know, front end for back end, for different specific tasks. Having a default one, the Drupal community builds, I think that's a great idea. Having the framework in core, I don't think personally. Yeah, I think we're just, we're in a situation where the, you know, the editor experience in Drupal is getting rapidly out of date. As far as the JavaScript in there goes, and there's a vast amounts of it, you know, and it's all built on jQuery predominantly, you know, which is a framework for the old days. But yeah, I mean, where do we go in the future with that interface? How do we modernize it? And then how do we standardize that? There's got to be a framework, doesn't it? One of the things that I come back to repeatedly in discussions is that the, again, personally, my opinions count for me, not my company and not my framework, just for me. But I would like to see standardization on the actual pipeline of data within Drupal because at the moment, a decoupled site does not have access to the same amount of information that a coupled site does. PHP has priority access to certain things. Blocks is one of the biggest examples of that. The decoupled blocks integration I've got with Drugs, it knows the block regions because Drupal tells it that information. It knows what's in the block regions. It knows when they're supposed to show up. So as far as my front end can do things, it can make it happen. And it knows the configuration as well. So taking into account like the branding block, the branding block, if you decouple it, it will tell you, I want the logo. I want the site name. I want the site slogan. But it doesn't tell you what those things are. So if you want the logo, you know, you know, the block is configured to show the logo. But if you want the logo, you'll have to hard code that yourself. Ditto for the site. Does the shooting use JSON API on? Yes, sorry. When I talk about decoupled, I'm talking about JSON API and I'm talking about using the data that Drupal makes available out of the box without adding any specific extra modules. And that is one of my core visions. And with the other topic that you mentioned before about web form and submitting stuff, and you also touched on that, Jack, if you do use the JSON API, when you do do a CRUD request, a post to push whatever, I mean a post, yeah, post to patch whatever. If there's validation issues inside, if you don't have the right permission to be able to make this item published, Drupal already knows that. So as long as you format the JSON API request that you push back to the system, it knows how to handle it and it returns the results if you've got validation issues. The JSON API in Drupal already tells your front-end that it's there for you to consume that data as it is. There just needs to be more and it needs to be standardized. So GraphQL and JSON API and Drupal or PHP all have access to the same level of data. Interesting. I remember, I think it was, Gabriel Solis had a blog post, it was probably six months or more ago where he was talking about, it's not enough just to have the content, a content API coming out of Drupal because there's all of the, there's all the kind of the, I forget what he called it, he put it like the machinery I guess, things like layouts and the structure of the page which is kind of, it's not really content, it's really the configuration of Drupal. So I guess how do people feel about that? Should we be trying to split that off into its own piece and treat that separately from what content is? At the moment, it is already there in the JSON API. So when I talk about schema and stuff like that, that's data that comes from the JSON API. So entity view display, entity form display, all of that information is exposable in the JSON API already. Editor is a resource that contains all the information about WYSIWYG, which buttons you choose to have available for which display modes. A lot of this stuff is there. It is, as you say, it's tangled up within the content because anything in Drupal that is considered a content entity is exposable via the JSON API already and most configuration is set up as content entities. Okay, I've got a question. It's probably the access layer, right? So by default, most of those configuration entities are behind what we consider elevated permissions. So, for example, the managed view display would be behind the permission that has restrict access on it and you probably don't want to be exposing that to your front-end, but in order to put it ahead of the site, you have to. And so, yeah, there's no real distinction in Drupal's permission system between being able to view that information and being able to edit it. So I'm interested to know how you're getting around that. And that is the one case where there is currently a custom module or contrary module, I should say, which is the Drux module itself. All it does is a very few minor workarounds. And I want all of these workarounds to be documented and turned into issues at some stage. And I want to kill the Drux module in the back-end because it doesn't need to be there. It shouldn't need to be there. But the way it does it is it adds an additional permission, which you can assign to any role. So if you have a specific back-end building role that is used by a OAuth user at your build time, then it would be able to consume that information. It's read-only information as well, because I agree that information has, you know, not really being considered as how it should be used outside of Drupal. So it's read-only. It's available to that permission. Yeah. Okay. I want to make sure we get to a couple of questions that we've got posted here. So we've got a question from Joshua Lee. It says, last time we were looking into Gatsby, there was a concern of content editing on the fly. Gatsby requires the deployment to Netlify every time the content is updated. Is it still an issue, or has this been resolved into the market? In the market. I'm going to talk to that one if you like. So, first of all, you don't have to deploy Gatsby to Netlify. You end up with static pages, and you can deploy it wherever you like. You can host it at it. There's three we're hosting preview sites out of CircleCI artifacts. You can do what? It's just HTML. There are use cases for Gatsby where you're going to hit hard problems. And one of the hard problems is if you've got a lot of content. So, you know, if you've got 20,000 nodes and 20,000 files, you know, and you change one piece of content and you've got to rebuild your whole site. You know, you do find people in the issue queues for Gatsby, or sorry, in the GitHub queues for Gatsby saying, you know, it takes eight hours to run a build, and it's just not feasible. But there are, you know, solutions. So, Gatsby 3 is added a fast build feature. So, basically, it does a diff between the incoming props and the last time it was built against the cache, it doesn't rebuild pages that haven't changed. So, that helps. There's also a fast builds module that Drupal has. So, every time you make a content change in Drupal, it keeps track of things that were edited. And then when you run a build, it makes a call back to Drupal and says, tell me what's changed. And then it doesn't bother, you know, if you want to change one piece of content, it doesn't bother rebuilding the whole site again. So, there are things happening there. But yeah, look, you do have to look at the top content that your site's serving and how frequently it updates as to make the decision whether it's right fit for you. And at the end of the day, Gatsby is just, you know, it rehydrates into React app. So, you do have dynamic content that's updating regularly. You can just use that as you would in the client-side rendering and make, you know, APR requests from your components from the browser. Yeah. I'm also interested in how I think Next.js is doing or can do static site generation, but also server-side rendering. It's got this optimized static rendering where it can basically... I'm just wondering if people have got opinions on that. Next or next? Maybe next. I mean, they both have different approaches. So, I am primarily Nuxt. And I have used Next a slight little bit. But Nuxt, the way Nuxt works is it has different types of build modes as well as different types of targets. So, you can build a Nuxt site in server-side rendering. So, it will have to run on a node server. And it will render all of the page on the node server, before serving it up to the user. So, if there's any asynchronous data that's already going to be there, you can do non-server-side mode, which is still running node, which will just serve up enough HTML to inject the client-side application into the user's browser, which will then do what it needs to do to load in all the data progressively the same way that it would do in the server-side behind the scenes. Then you have the two different static modes. You can have static mode with server-side and static mode without server-side. So, static mode without server-side simply generates a couple pages, like a 200.html file as your wildcard fallback. So, any pages that don't resolve a static HTML file in the deployment will hit that 200 file, and that 200 file will then load in all that additional data client-side. So, in client-side only static, that's basically what gives you that one file. In server-side static, it will generate a HTML file for every discoverable piece of content that you have within your site. I could show you a video of that if you wanted, but it probably doesn't really matter, but that's the way that the Umami demo works. It will hit the home page in static. It will find all the links that are on there, and then it will go through every single one of them and create a HTML file. Now, when you actually browse to that site, the HTML file will have just a very small amount of rendered data, which serves up the full page really, really quickly, but then it rehydrates it as a view app and Nuxt app, so it re-engages the view extor with all the data, so as you start navigating around, it just progressively loads in the things that you want. Okay, well, I think we've got time for one last question. So, Michael Cooper asks, I'm interested in security and re-usability of the advantages of creating all content on one really secure main dribble backend and then being able to use that content on multiple front ends. For example, a research unit site and a portal for prospective students to show the same event without having to syndicate or duplicate. Which of these applies and has minimum DevOps burden? All decoupled, I think. As long as you've got an API to consume that data, you've got a registry and then you can build anything with anything to consume that data. And Drupal comes with JSON API out of the box, so it is already that out of the box. There are DevOps overhead with all of these approaches and it depends on whether you want to pay someone for that, so if you want to go and say Gatsby has Gatsby Inc, which is a managed service and that has a cost associated with it, you can build the same things as Gatsby Inc with your COI pipelines, but then you've got to have your own DevOps over here. So it just depends on whether you want to manage yourself or whether you want to use a managed service for that. And I guess one of my questions is, in terms of the Drupal project, do you see the fact that there isn't going to be, like, well, if it's open to develop an admin, decoupled admin thing, front end without trying to target a specific technology that will end up fragmenting the community and we won't get that kind of critical mask, because I believe at the moment there's still a shortage of people working on JavaScript and front end in core, so we've got a pretty small pool of people who are contributing at the moment. What are people's thoughts on that? I think the value there would be in working together to come up with the concepts for what the decoupled front end could how it could work and that done collectively because invariably it's going if it's going to get implemented centrally, it's going to be something and then there'll be other people who want to use a different technology, but at least if a lot of that work's gone into the usability of how the components work, then people can port those to their frameworks if they want to, would be one approach. Okay, all right, I think we are almost out of time. Thank you Stuart and thank you panelists for joining us and thanks for coming along to the session. I hope you enjoy your rest of the afternoon and come to the sprint tomorrow. Thanks.