 All right, perfect. It's 601. So let's get started. Hi, everybody. This is Ishan. I work for Shrejan. And today I'm going to talk, be talking about can Drupal be the decouple CMS that marketers love also love right so I'll talk a little bit about why I picked up marketers today for this session. But before we get into that, let's talk about decoupled CMS right let's do a quick recap about decoupled CMS and this. So this is a very high level view a very broad classification but I think for today's presentation. This is sufficient. Right so yes there could be multiple different layers when it comes to decoupling Drupal there are different approaches but at a very high level if you have to make a distinction. On the right we have the traditional approach where Drupal is responsible for both the front end and the back end so your front end rendering of the website of your web application on a web browser. You would be using Drupal's quick templating engine to render those pages right so Drupal is responsible for both the back end and the front end. On the decoupled side of things what you see on the left you have some flexibility right so you're using Drupal for storing content, managing content and then you're exposing it in the form of APIs. And in most cases you'll see modern JavaScript frameworks such as Angular, React or Vue being used for the front end. And then of course the content can be distributed and these applications are not necessarily just web application they could be native mobile apps, smartwatch apps and so on. So that's the distinction the two approaches and we'll be talking about the decoupled approach today and how we can work with Drupal. Of course you might have seen in all of these conferences over the past two, three years there's a lot of discussion around decoupled CMS and there's a good reason for that. You can see a Google trend report here like about three years ago late 2017 you can see there's been a constant spike and an upward spiral for headless content management system in terms of Google search trends. And Drupal has kept pace with it to be fair this you can see that a few screenshots here on the right is actually from Drupal.org that's the official Drupal 8 documentation. When Drupal 8 was launched, these are the features that were listed and you can see API first easily decoupled being mentioned over there. Towards the back you can see a couple of screenshots from Dries's blog post so he has been writing regular blog post. I think he comes up with this post every year where he talks about how you can decouple with Drupal and there are different approaches such as progressive decoupling, completely decoupling. So there's a spectrum of different approaches from completely coupled to completely decoupled. So there are different approaches. So he talks about that. And then on the bottom left is the screenshot from DrupalCon this year where he again talked about his vision for Drupal 10. And one of the initiatives he mentioned was to become the best decoupled CMS out there. So the Drupal community has been keeping up with the rise of decoupled CMS. But can Drupal be the decoupled CMS that marketers love, right? And why am I talking about marketers today? Because we're seeing that there is a sort of a division in the CMS world. On the left-hand side you have the marketing teams. And marketing team is a narrow term. You can think of any non-developer CMS user here to be honest. It could be publishers if you're talking about a media or a news website. It could be editors. So anybody who manages content and uses the CMS, you can broadly classify as non-developers. They want features such as the drag and drop page filter. Or they want the ability to preview content which is unpublished. They may have moderation workflows that they want to retain. And they do a lot more than just adding content, right? They also have responsibilities with respect to SEO analytics and things like that. On the other hand, you have front-end developers who have a preference for using modern JavaScript frameworks, especially people who are not familiar with Drupal. So they don't want to learn PHP or Twig just to work with Drupal. They want the flexibility to work with some of these others JavaScript front-end frameworks. And at the core of this division, I feel is this perspective, right? This point of view. So there is a point of view with a lot of new age pure headless CMSs out there, which are emerging in the market. They view content in a very narrow perspective. They think of it just as data. So there's a lot of talk about structured data, how these pure headless CMSs are able to support structured data, which is something Drupal has been doing for years as well. But if you look at the left-hand side, I think that's where Drupal plays a big role, right? So these non-developer roles that I'm talking about, the marketing teams, they are not just adding data to the CMS, right? There are a lot of other things that they're responsible for as well. So they may be responsible for creating a landing page. They have the need to change the layouts. There are compliance, whether it's editorial workflows, whether it's related to analytics, SEO. So there's a ton of different things that people do on a CMS than just adding content. Here's an example of that. I really look up to Mackenzie.com for the design. I really like that website. So I picked a few examples from Mackenzie.com. You can see this is a hero banner, right? And you can already see three different variations here. There is, on the top left, the text copies on the top right. On the bottom of the screen, you can see the copies on the left. In the middle, you see the screenshot where the copy is on the left, and the text color is black, right? So you can see, depending on where the focus area is of the hero background image, they're moving the text around. And this is text, by the way. So that's very important, right? So we know from an SEO perspective, having somebody to do this in Photoshop is not ideal because then your text and the sub-headline that you see is not part of the HTML, right? And it cannot be indexed by a search engine. So as a good practice, you say this should be text. But then you cannot go to a developer every time you want these kind of changes, right? Because just looking at Mackenzie.com, they have over 50 such pages, and they may want to create new pages like these on the go as well. So they cannot have developers do this all the time. So this is a very small example, but there are many more things like this that the marketing teams need to do on a day-to-day basis when using a CMS. So basically, we're talking about trade-offs here, right? Dries mentioned about this trade-offs between the developer experience and the non-developer experience. So which direction will Drupal choose? Where should Drupal go? Dries has made it clear that when he gave the keynote this year, he said he wants Drupal to be able to do both of them, right? Not having to do those these trade-offs. And that's exactly what we'll talk about today. We certainly don't want to go in this direction. So this is a quote taken from Preston Sow's series of blog posts. I've put in a link to this series towards the end of the presentation. This is really useful. He talks about these different realities between the front-end developer world, where all the talk is around GraphQL, the Ag, Gatsby, Static Site Generators. So there's a lot of excitement and talk about these things. But then what happens to the marketing team needs? So he talks about the front-end developer world, where some of these non-negotiable features like previewing content or layout management are just going away. So in my opinion, we don't want to go into this direction with Drupal and make it a pure headless CMS. So that's where what we talk about today as part of a demo is a Drupal distribution called Easy Content. And it is trying to address this gap and trying to bridge the gap between all these non-developer roles and the developer roles. And we'll take a quick look at how that happens. So as part of the demo, I'll cover some of these features that I'm showing you here. So you can decouple Drupal. I'm talking about completely decoupled. We're not talking about progressive decoupling or any other such way. We're talking about pure decoupled headless implementation of Drupal. You can do that and you can have your front-end on a Next.js or Gatsby or Angular, but you can still retain these features. So you can still use the Layout Builder to create landing pages. You can preview unpublished content when it comes to SEO and things like accessibility. So you can retain your control over meta tags, path aliases, schema.org. And then you can also have the configuration, example that I gave with the Mackenzie.com hero. You can have things like that, moving images or moving the text left and right. You can do all of that in a completely decoupled setup. So let's get into the demo and let's see how we can do this. Let me just pull up a new browser window. I'm going to minimize this. All right. So here is my demo site. I will log into the backend here. Okay. So this is a demo Drupal site setup using the easy content distribution that I mentioned. And I'll log into the backend and we'll start creating some content. So I'll keep it quick. Let's look at... Let's straight away jump into the Layout Builder. So here is a scenario where you may want to create a landing page or you may want to manipulate an existing landing page. It could be your home page. It could be your section page, anything like that. So I have a basic content type here called landing page. I just need to put in some title. I think that's all I need to do and let me publish it. And I'll straight away get a blank page. You don't have any pre-built layouts here. So I'm getting a blank page and I want to start from scratch. I want to use a Layout Builder to start populating this page with some components. And let me just remove this. Okay. As I do this, what you notice here on the demo site is that I have this demo site hooked up with a bunch of decoupled applications. We have a Gatsby application. We have an Angular application. And we have a React application, which has been using next year. So I've just created a blank page. But before I start working on this page, let me show you that as I did this, a blank page has also been created on these different applications. So I'm pulling up a couple of them. So I've pulled up a React next year's application. You can see I'm on a completely decoupled. This is a next year's application on a different URL. And it has just received this blank page as well. And it has picked up the URL from the Drupal backend. And similarly, I have my Gatsby cloud website. This is actually a live preview. So I'll use this for the demo because it refreshes as I make changes to my Drupal. So I have these two different decoupled applications. And I have a page created there as well from Drupal. So let me actually go back to my Layout Builder and try to make these side by side so that we can see how the live preview works. Okay. All right, I have my Drupal content type here where I will be using the Layout Builder to add three components. So I have a section already, which is full width. I will put in a hero block here. So you can see I have a variety of components available here. I will use the hero component. Let me quickly put in some information here. I am trying to create a page where it's a hero similar to what I showed in the Mackenzie.com example so that you can relate to it. So let me put in some link text. You can just point it to any dummy page. And of course I need to put in a hero media image here. So the next two components I'll pick will be very quick. This is the only one that I needed to have some configurations. So I have added a hero block and let me, those of you who are not familiar with the Layout Builder, it also lets you create dynamic section. So we had a full width column, but I can also add like a two-column layout. So now my next section gets divided into two different blocks. And on the left-hand side, let me pull in a Google map. Okay, I'll put in a map block. So let's just say next Google con at New York. I'll give in some address to pick up. And we'll add just one more component, which is a social media. So I'll pull in a tweet. So this is something that, you know, day-to-day marketing teams do, right? They do utilize such components on their CMSs. They may have to create these pages very quickly. If you have to roll out a campaign. So I will go and save this. And it does take a few seconds to deploy the changes on Gatsby. This is end of the day. This is creating a static page, right? So Gatsby is a static site generator. It will create the HTML and serve it via CDN. There you go, right? So you can see I have a Gatsby page here and it just got the hero banner. So I was able to dynamically create a page from scratch, add a full column, add two columns, and place three different components here, right? And the same thing would have happened here on my next year's application. So if I refresh my next year's application. So you can see we have the flexibility of using different technologies, right? This is server-side rendering. This is next year's. This is Gatsby. Both of them are working with Rupert's Playout Builder. So it's not just about placing components, moving them around. You can drag and drop, of course. You can change. So let's do that quickly just to show that it works. I say I don't want these in a different section. I want everything to be in one column there. So we can do that. Let me pull the hero media at the top. All right. And then let's also just to go back to the example of Mackenzie.com that I gave earlier. I can, for example, change the color of my overlay. I can make the text position center. I'll hit update. And I made a bunch of changes on this page now. And that should refresh in a few seconds. On my Gatsby live preview site as well. So there you go, right? So you can see I was able to change the color. I was able to make the text center aligned. And then I have my components in a single column now. So that's an integration that easy content lets you do. It's allowing you to use the layout builder with such decoupled frameworks, including static site generators such as Gatsby. And then these components can be very powerful, right? So as you know, with Drupal, you have the flexibility. So we have components here, which actually can be tied back with view. So it's not just about adding content to these components. You have components such as these, which can, for example, say, bring me all articles that are tagged with a particular taxonomy term, right? So you have the flexibility. You can keep on adding more components to your component library and give the CMS users this flexibility. So we've talked about the layout builder, which is an important part. But, you know, there are other kinds of content. The most important being structured content such as say, you may have something like an article, right? Where you use your traditional node edit form. So let me give an example of that as well and show you how that works. So here I have an article content type where you can see I have my different meta data fields such as title, subhead, some reference field for author. We have a teaser and we have a bunch of components here similar to the landing page, but these are in the form of paragraphs, right? But you can see there's a whole variety. You can add more. You can see that a bunch available out of the box, but all of these work with decoupled interfaces as well. So what I'll do is I'll open the preview for this page as well to show some other aspects of decoupling that I spoke about earlier, right? So let's do a bunch of things on the article content type as well. Let me pull this here as well. That's easier. Okay. All right. So let's take a look at this sample article. So we have a bunch of components already pre-populated. So this is my article showing up on Gatsby. I have text. I have images, a pool code. I have an embed code here. There's a photo gallery. So yeah, let's take a look at this photo gallery and I'm going to do some changes here to just to show again the power and the flexibility that CMS users can get even with decoupled implementation. So you can see this photo gallery right now is coming in the form of a carousel. So I'll do a bunch of things here to show how the article content type is also integrated. So one, I will drag and drop and pull the gallery to the top. Let's change the order of the components. What I will also do is I will also change the view mode. So you can have different displays of your components or your entire content as well. So right now the gallery displays are the carousel but I want to show it in a different way. This is a standard gallery that we're calling which is in the form of a pop-up. So I've made a couple of changes. I moved the gallery component to the top of the article as well as change the view mode. And this should refresh in a few seconds as well. There you go. So my gallery is at the top. Okay. There's an issue with the Gatsby preview for that view mode but let's pick up a next year's application. This one should work. There you go. So you can see on my next year's application the photo gallery has gone to the top and it's opening up in a pop-up window. So again, things that your CMS users might be used to working with Drupal for years or with new functionality such as the layout builder and these kind of features. We are retaining all of these with completely decoupled applications as well. So we've talked about content a bit, what you can do with the content, how you can use the layout builder but there are a bunch of other things as well which may seem small but are very important from a workflow point of view. And I'll highlight that next. So for example, I'll create a new article from scratch now just to show a couple of features that also get missed out when you go completely decoupled. So demo article unpublished. So the most common one is actually something like ability to preview unpublished content, right? How do you do that when you're completely decoupled? Because your decoupled front-ends have no idea about your user roles, if the content, if you log into the CMS, there's no connection, right? So that's why you tend to lose that ability. But here what I'll show is I'm doing a bunch of things. I'm going to save this as a draft so it will be unpublished. I'll also demo a couple of other things. So I spoke about SEO and things like that. So some advanced users may want to control these things, right? They have the ability to do that in Drupal. So I can, for example, change my, I'm just going to say demo summary here. I'm just going to override my meta tag for a description. Let me pick something like schema.org, right? Which is a initiative backed by Google and other companies to add schema to structured content throughout the web, right? This is really important and Drupal has a module for it. But again, we want to make sure it works with decoupled. So I'm just going to change the schema.org type to, say, tag article. So I have this control over my metadata, right? I can schedule content. That works with decoupled. Let me also change the URL. So instead of going with the alias touch and it automatically lets us say custom URL123, right? I'm overriding the URL over here. And so I have the content which is unpublished. I have overridden the URL. I have overridden a couple of meta tag information. I'm going to save and edit this. Okay, sorry. Okay, so we have a draft article. And if everything has gone correctly, if I go to my, let's pick up the next US application. And let's also see the React preview works. So few things, what we did just to recap. So you can see the URL. I had overridden the URL. I've got that here. So I have custom URL123 instead of any programmatic rule or automatic de-generating alias. I was able to manually override the URL. Let's take a look at the page source as well because I want to show the metadata that was updated. So we had updated a couple of things. We had updated the description tag. If I remember, it was demo summary. Yeah, so you can see I have demo summary in my description meta tag. I have schema.org. So we had changed the type of the schema. I'm sorry if it's too small, but I'm just going to highlight or you can see it has changed to tech article. So again, things, advanced functionality, which people may want to control through the CMS, they can do that. And of course, the biggest part and the most important piece is the previewing of unpublished. So we have done this in a way that you can see there's a hash key attached to this URL, which is like a password, which is unique to every note and it gets refreshed after every few seconds. And the only way to get this hash key is if you click the preview button from the Drupal back end. So if you log into Drupal, if you have the right role, if you have the right permissions, when you're going through a moderation dashboard, you will be able to preview unpublished content on your decoupled applications with this hash key. Of course, any other visitor who might get this URL from somewhere will not be able to, unless they have the hash key, they will get a 403 access tonight. So you're able to retain your workflow in this manner. So there are a bunch of these things that you can do to retain these features. I think that probably is the end of the demo. I can come back to the demo if there's anything else that comes up or if you want to talk about. So I'll just quickly switch over to my slides and then we can jump over to the questions. So with what we saw just now with the demo, at least you saw that we're able to retain all of this. We saw different JavaScript frameworks that were working and we were able to show all of these features working from the Drupal backend. So we feel that definitely a happy compromise and all of this is possible because of Drupal's open architecture. So you have, whether it's schema.org, whether it's scheduling, you have 15,000 plus modules available. So some of these functionality, a lot of these new-age CMSs, you don't have them because Drupal has been around for so long, there's so much I don't workflow capabilities that are already available in the ecosystem. So we feel that bringing those, leveraging those along with the coupled front-end is a great compromise and makes both sides happy. And as I mentioned, you can do all of this too. So I'll put in these links on the chat window as well, but you can take a look at easy content distribution. There is a sub-module called easy content API. If you're focused more on the decoupling implementation, such as the one I was showing today, you can look more closely at the easy content API project. And then there are a bunch of modules that are part of these distributions, like access unpublished, which if you're not looking for everything, but you're looking for just that functionality of previewing unpublished content, you can check this out. And of course, as I mentioned, going completely decoupled, if that's not your thing, if you think that's not the right approach for your project, you can also consider progressive decoupling, which is a very different approach from the approach that I have taken here or the one that I've shown here, but definitely something to check out. And that's something that's part of Dries' blog as well. Apart from this, a couple of things I would recommend reading. One is the whole series of blog posts by Preston. I'll put this in the chat window as well, but there's a whole series of blog posts he's talked about where he talks about this grand compromise that is needed. So that's exactly what I spoke about today. This is how we envision Drupal can provide this grand compromise. So do check that out. And with that, that's about it. Let me quickly check if we're a bit early, but we can have some time for questions. But even after this chat today, if you want to connect, I'm available on Twitter at LinkedIn, we can connect and please I'll be happy to learn more about your experiences with decoupling, whether you've run into these situations between marketing teams and developers and would love to discuss ideas around how you approach those situations. And of course, if you have any questions on easy content, if you'd like to get a demo, we can set that up as well and we can deep dive into that as well. We'd love to connect with different people and let me see if it's better to maybe... I don't want to show the infinite tunnels, so I'm not sure how to avoid this, but this is not too inconvenient. I'm just looking at the questions and taking a look at the questions. So please feel free to add more questions here. So, Benji, your first question is, does the distribution include the front-end component? That's a great question. So it's not on Drupal, but it is open-source. So we are trying to make all of that open-source as well. So we have... So if you go to the subproject here, easycontain, api, right now we have the next-years piece. It is completely open-source. So it's available, but it's available on GitHub, because it's not the Drupal... So yes, you download the Drupal piece from Drupal.org and then you have your next-year starter kit here. So you can set up the same demo that I showed today. You can set up the exact demo with the Drupal back-end and this demo site that I showed today. You can do this on your own using this GitHub project. So everything is there. In case you're running into anything, please feel free to reach out. Our team would love to collaborate with you. And we will be releasing... So we released this starter kit for next-years. We will be releasing starter kits for Gatsby and Angular soon as well. So that was the first question. Second one was, how do you end with the layout builder configuration? That's a great question. So we include all of that information. So I think that answers Carlos's question as well. So we are using JSON API, Drupal JSON API, but we've extended that API to include additional information. How you handle the layout information is slightly up to you. The approach we've taken is... In the case of Gatsby, we do all of this in GraphQL. But in the case of these next-years applications, I will bring up an architecture diagram. And it's not... Yeah, it looks a bit complicated here, but it's not really. So what essentially you would need is you would need some sort of middleware to do all of this. And again, this middleware, all of this information is part of the GitHub starter kit that I mentioned. So it will have installation instructions for all of this Node.js server as well. But we are using the middleware to sort of take in that layout information and transform it in a way that these front-end applications can understand, as well as we do that. That's where we cache this as well. Because changing the layout does not happen very frequently. We don't want to hit Drupal to get the layout information for a page, right? We want this to be purely decoupled and we want to retain the performance. And of course, Gatsby is a static-side generator, so it will generate the HTML. So we're doing all of this in the middleware in Node.js. But we do... Yes, we've extended the JSON API to send this additional information about the layout builder. Chris asked if you can do all of this completely decoupled, is there still argument for progressive decoupling? I mean, there is. I wouldn't discount any approach. I'm sure there are... But in our experience, this whole project started because we were running into issues with progressive decoupling, right? Specifically, whatever you do, there is still... You need to have that magic source and it's not solving the problem of front-end developer not having to do anything with Drupal, right? You still have to understand Twig as well, even with progressive decoupling. So that's why... I would say progressive decoupling use case, in my opinion, would still be there if you're already familiar with Drupal, right? If you're comfortable with the Drupal front-end and if you're looking to maybe on a couple of pages or for some critical functionality you want to embed a React application or something like that on your page, you can definitely still go with progressive decoupling. But I think from an outsider, somebody who's not familiar with Drupal front-end, it's probably better to go completely decoupled rather than trying a progressive decoupling. Next question is, you said Angular 8 would work. Yes, Angular 8 would work, React, you just... All of these work would work, Eric. The idea here is that you have the complete flexibility. Of course, there is some work that you need to do and that's why, as part of easy content, we are providing the starter kits for Next.js, Angular and Gatsby. We don't have a starter kit for Vue.js, but yes, you can definitely attempt that on very similar lines to these other frameworks. But what the easy content API module does is that it's going to provide the additional information regarding the layouts. Link to the starter kit, sure. The link is right here. Let me post a bunch of these links on the chat window. So this is the... The first one is the project, the distribution that is a sub-module, which is more focused towards the decoupling aspect. And from here, you will get the link to the Next.js starter kit. And then, of course, there is... We have a contact form here as well. I mean, you can reach out to the developers directly on ruple.org or you can reach out on this page as well. Plus, if you want to see these demos again or you want to just pass these demo links around, there are smaller versions of these demos as well on this YouTube playlist. So these are specific for different functionalities such as the layout builder previewing. So these are very quick two-minute sessions if you want to watch them after this or you want to share it around, feel free to do that. We still have about nine minutes left. So I'm here for the rest nine minutes. If anybody has any questions or wants to discuss anything, would love to do that. I think I have the ability to also pass on the controls. If anybody wants to share something or talk, I guess we can do that as well. But happy to stick around to talk more about this. Has anybody ran into these situations? Are you also seeing these kind of... Are you seeing this disconnect or this division between these different fractions such as front-end developers and CMS users? Would love to know more about that as well and see if others are also seeing this. But that's something that we are definitely seeing a lot. I'm seeing that a lot and in my company at Shrijan as well, we are seeing that a lot. Would love to know if others are also running into this situation. Great, Eric. Absolutely. At least I've seen is that sometimes some of these small things like ability to preview and publish content, all of these become real after implementing. We've seen a lot of projects where initially the thought was to go decoupled and after everything going live, then realizing that... People take some of these features for granted and it's not their fault as well. If you've been using a CMS like Drupal or WordPress for a decade now, you know some of these things just work. And suddenly realizing that you don't get this feature or I mean everything can be built. But having to say you need scheduling, yes we can do. We'll have to implement something for scheduling or we'll have to implement something like URL redirect, right? I mean that's a very... That's something that happened in a couple of projects, right? Where things like adding a redirect for a page is a functionality again that Drupal provides, right? There are modules that let editors create a redirect for a page, for a URL. But does that work seamlessly well with your completely decoupled site? It does not, right? You have to do something to make it work. Absolutely Eric. That's completely true. Everybody can see the screen, but Eric just mentioned that the unfortunate thing about decoupled is that people still think they can plug in some Drupal module and it will continue to work which is not the case. That's absolutely true. I think that's an expectation that should be set. I mean everybody should be aware of this. That if you're expecting everything to work just make sure it may not work, right? In most cases you will have to do something to make it work. So that's definitely something that you should be aware of before getting into these projects. Stop sharing so that we are not seeing all these infinite screens. But please, please feel free to add more questions. So Julian asked is there sufficient value that Drupal provides to be a good choice for headless despite the confusion? There's definitely a lot of value, Julian. I think it goes back to my initial point around Drupal lets you do a lot more than just managing content. So yes, there are use cases where you're looking at a pure headless CMS to add structured content and distribute content. But there are many other situations where you need to do a lot more. You may want to integrate with other backend systems in an enterprise, right? And Drupal is really great at integration, right? It's completely open. You can integrate with your single sign-on backend or it may be a translation service or so it provides you all of these flexibilities, right? Which you can retain. So there's definitely a lot of value in considering Drupal as a headless solution. And in fact, we feel Drupal has a lot of advantages over some of the other pure headless CMSs because of its developer ecosystem because of the modules that are already available. You're able to get a lot more functionality out there. So if it's a front-end Drupal module, but don't audience Chris, no, actually, no your permissions will work like if yes, for the editors permissions will work. Workflow, yes, but to the extent like previewing unpublished content if part of your workflow is and in most workflows that is the case, right? You would have stages where your content is not published, right? If it's unpublished, then no, there's no straight forward way to preview that content, right? There are many different approaches to do that. Some people create a preview in Drupal itself, even though the application is front-end, so they will duplicate the front-end and create just for the preview functionality, they would have a preview within Drupal which is not ideal because then you are not truly testing the content as it will be shown, right? There can always be differences between your say, JavaScript front-end and the Drupal front-end. So that's not an ideal solution. People have tried doing the progressive decoupling just for the preview, that's also not ideal. So there are definitely, you can make all of this work, but the point is that you have to do something to make it work. It's not that seamless and it doesn't work out of the box. So you have to do a lot of these things. So our attempt with this distribution is to get all of this working from day one and saving you this time, right? Great. I think we are about one minute left for this session. So please, if there's any last-minute questions, please go ahead. Otherwise, we can definitely, you know, you can reach out to me from the Shrejan page or on Twitter, LinkedIn, would love to connect with everybody and talk more about this. Thank you, Matthew. Thank you, Carlos, for coming in. Thank you everybody for joining. Have a great rest of the bad camp.