 Welcome to my session, The State of Hedlis and the emergence of Mac. It's awesome to see everybody here and just wanted to say it's pretty cool that we've been able to get together after so many years. And it's great to kind of see everyone again and face-to-face and hugs and smiles. My name is Josh Wahey and I'm a Director of Product Management at AQUIA. I've been a part of the Dribble community since about 2007. I really had a lot of background in history and doing large-scale Dribble deployments. And today at AQUIA I kind of lead two key parts about product strategy. One is around the Dribble 7 end of life and the other one is the headless CMS. To start things off, back in 2019 I presented a talk called Decoupled Why We're Building a Worse Will. And I was kind of talking to this community about how building headless and decoupled architectures cost the customer more money, introduced more risk, took more time. It was fundamentally not the right choice a lot of the time. But it was a really cool technology and a lot of people were using it. And so I was kind of cautioning people to find the right reason to do that. And so I was kind of almost like a naysayer to the headless movement. So almost comical that I find myself the headless CMS, a guy at AQUIA. So today I wanted to kind of give us an update since that time, right? That was pre-COVID two and a half years have happened since. And I wanted to kind of revisit that is now a better time to start adopting headless. And can I give you a state of headless and also talk a little bit about what mark is. So to do that we're going to just kind of do some level setting, what headless is, talk a little bit about what mark is. And then have a look at the suitability and market conditions for headless. We'll take a look at some of the technology that is in that space and its maturity. And then kind of leave you with some forward thinking insights about where this industry and the space is going. So to kick off into what it is. So fundamentally headless is a loose term that refers to decoupling front-end UX from back-end systems that provide, manage and control data. That's it in its most simplest form and so you could think of it as here is a business system, it's got back-end data, it has a management user interface and you're going to surface that up to the user experience independently. Those two things now become a couple that shouldn't be too new for anyone but for anyone who kind of missed it, that's what that does. When you start thinking about the values of headless, one of those things could be a single unified experience. Where now you can have two back-ends providing data to a single front-end. That could be something like a CMS and an e-commerce system and you can now merge your rich content with commerce capabilities in a unified user experience. That would be one example but basically multiple back-ends feeding into a common front-end. The inverse of that is also another value of headless. So you can have two different user experiences. In this example, Amazon Echo integration and a Google Assistant integration and they can be feeding from the same back-end. So this idea of using the same content to speak to multiple channels is called a omnichannel strategy which is something that you can do with headless as well. Another still is this headless architecture demand greater agnostic interoperability between back-end and front-end systems making open standards and protocols de facto. So in this example here where you've got a user experience written in TypeScript and another one that was written in Swift and one uses JSON API and the other one uses GraphQL and the back-end is written in PHP. So in this scenario you've got three different technologies interacting with one another over open standards and it's those open standards and protocols that allow that interoperability. That opensource software foundation. It's a foundation for what we call composable architectures. That's allowing you to kind of bring your own different parts of the piece of the overall solution into the puzzle and build that together and open-sources foundation to that. The last paragraph I have here is actually a quote from an analyst. This is, composing is when you assemble from specialty parts but putting them together in a way that optimizes for what you're trying to achieve. I thought that was a really great way of thinking about it is it's a piece of specialty part. So you're not bringing one thing that kind of does what you're looking to achieve and then you have to configure it from there. You're really building from the best of breed of the bits that make most sense for you. Another opportunity of Headless is for organizations to put multiple of these Headless back-ends behind a common API gateway of sorts and essentially produce a content service or a data service layer. And in doing so, they're able to start reducing the cost of front-end integration because now they just have to integrate with a single content service API endpoint rather than having to do two, for example in this case, CMS and E-commerce system. You could either integrate Amazon Echo integration with both of those two systems and then the Google Assistant with both of those two systems or you could put the content service in place and then just have them integrate with that one. So the cost of integration goes down also at the same time you increase your security because now everything goes through a single or consistent content layer and it kind of starts to protect your back-end business critical systems from the front-ends that you're connecting into them. Finally, another opportunity of Headless is that front-ends change much faster than the management of the data models they use. So Headless architectures allow for back-end systems to reside in organizations for longer 10 years than fashion-oriented front-ends. So in this example here, I have a user experience that was built in 2019. It plugs into my back-end and then I can build a new experience in 2022 and continue to plug it into the same back-end. And then I can manage both of those at the same time and I can continue to add more things. My back-end continues to serve those. So if you think about front-end as a general space, it's changed a lot in the last decade or two decades or however long you want to think about it, like it continually changes. Most of us here probably remember the days of IE and browser incompatibilities and flash was the thing once and that was a front-end. And what's the point in time? We had PWA's are still kind of somewhat popular, but there's all these sort of different front-end technologies that come around and you need to go and re-integrate with those things. And throughout that entire time, what's remained true is that you need to manage your content. And so by being able to decouple from the front-end, you can start to focus more on what actually matters for the business across those different front-end experiences, which is the management and governance of content. So to summarize, these are these five different use cases for Headless. Single unified experience, omnichannel, composable architectures, content service, and Headless tenure. So let's talk a little bit more about Mac. Mac is an acronym that stands for Microservices, API First, Cloud Native, SAS, and Headless. And it's a way of thinking about how you adopt Headless architectures, essentially, and some of the best ways to explain how you think about Mac is by looking at their antithesis. So a microservices, well, firstly up, first up microservices is individual pieces of business functionality that are independently developed, deployed, and managed. And that's opposed to a monolith. So a monolith often is thought about as like one Git repository, you know, one monolith project. But monoliths can actually be more like when you have dependencies between projects, the teams that can't deploy because other teams haven't done their piece yet, or data flows. So data from system A goes into system B and then is surfaced up into front-end C. So that's like content syndication or data syndication scenarios. They all are part of monolithic system architectures. One of the things that I think is really important is that data services is about isolating those data services to what they are managed and controlled around. API first, instead of API enabled, just meaning that you want to build all of your things for the API first mindset, opposed to it being a secondary thing that you add to your capabilities, meaning it may not be as fully fledged as like a couple-baked UI system. I think what it really means is don't own the things that don't differentiate you as a business. So as a business, if you can go get something that is commodity-ware, which is what things like Salesforce or CMS or CRM are, don't go and own those things independently because they are commodities that don't differentiate you in any way. So the cost of ownership is only a cost at no direct value if you don't have to own those things. Put those things into SaaS technologies and then focus on owning the parts that differentiate you as a business, which is typically those things that sit in the microservices. And then finally, headless is just about how you surface those SaaS technologies, making sure that they are delivered in headless ways opposed to more headful ways. In practice, it means that a mock architecture can look something like this. So in the bottom layer, you have, I guess, the cloud-native SaaS services, like IDPs, CMSs, CRMs, dams, economists, I hope all these acronyms you're familiar with, but these are all like the SaaS systems and they don't syndicate data between one another. They're all independent, which makes them composable, makes them pluggable. Then you have microservices that will consume those and provide more business-specific capabilities like product APIs, entitlement APIs, asset APIs. So those things are then consumed by your user front-end. It's a much richer experience. It's more oriented around your business rather than your capabilities. This might look a little bit like a model view control, MVC system as well. So your back-end systems, your SaaS systems are your model. They are your database, your storage layers. The microservices are your controls and the user experience, as it always has been, is your view. It's also worth mentioning that microservices can also appear as serverless functions, particularly called middleware between the back-end and the front-end. Just kind of no micrature, if you're familiar with the term middleware, it's often thought of as something that sits inside of a Linux box, but in microservices architecture, it is literally the piece in the middle there. Okay, so that is a loose, a highly well-overview of what Headless is and Mac. So let's talk about the suitability and market conditions of Headless. So we already talked about some good business drivers for doing Headless. There are some reasons why you'd want to do it, single unified experience, on the channel, et cetera, but there are also some other reasons why you might end up in Headless that may not be such good reasons. One such as by design, that's where you have good intentions, but you're kind of missing the business reasons why you would actually want to do it. So that could be something like front-end choice forces you to go to Headless. I see that a lot. People have decided that they go to a creative agency, creative agency creates a great-looking front-end. They decide that that should be a front-end react application or something along those lines and then CMS is an afterthought. So it's just a place to store the content and manage the content. So you're now forced into Headless because your front-end said so. And if you do that, then it means that you can't think more strategically about the business drivers and it can mean you end up implementing it in a way that doesn't give you the longevity that Headless could offer you. Market adoption is another reason maybe by design, but not a good reason. It's just because all the cool kids are doing it. And so you might choose to go and do it, but because it seems like a cool thing, that was definitely what was happening in 2019 when I gave this talk and it resulted in a lot more money being spent and a lot more risk being taken on and added value to the customer. The third one could be by constraint. So you are kind of forced into it because you don't have other capabilities. You might say, well, we don't have business justification for doing it now, but it's future-proofing. And that could be really difficult because how do you know that you're implementing it the right way to be properly future-proofed if you're sort of adopting it for other reasons? Or you might just only have front-end developers available to you. And so if you don't have back-end PHP devs doing stuff, you could be literally forced into doing all of your integration work at the front-end and so Headless makes most sense because Node is where you can do most of your integration work. I also added this quote here that by 2025, 70% of new applications developed by enterprises will use low-code or no-code technologies up from less than 25% in 2020. So that's a quote from Gartner that they suspect and I thought that was really worthwhile to consider because if enterprises are expecting to do a whole lot less coding then you really want to consider whether doing things with code in Node right now makes a lot of sense if you're thinking about its longevity. Also around suitability you might want to think about the content delivery strategy, what the use of the CMS is actually for. Are you building campaigns? Do you have a number of product pages to build out? Is it an intranet or portal? Maybe it is a mobile app or an IoT device, something like a digital signage screen, or maybe it's a brand site. You look through those types of use cases for a CMS there's also a number of different content requirements like how much pages or content is it handling? Do you need layout control inside the CMS? Do you need brand control, the ability to change color and size and padding? Do you need content components, the ability to ship little segments of content in particular ways? Should the data be structure or freeform? Do you need multiple front-ends? Or does there need to be an API that you're exposed to? Those sorts of things help also determine whether you need a headless or a hybrid or a coupled strategy for your CMS. You can see here that headless has one clear green scenario for being adopted, but all the other times it could be. It's an orange. It could be, but there are other options as well like hybrid and coupled that might be more suitable. You really have to think about the strategic drivers for doing headless because still you might find it is not the most economical choice. You have to weigh up the cost of implementation between headless and head full to determine the right strategy and direction. Let's look at the market conditions. We're going to look at three areas. The technology adoption, the market adoption and developer adoption. Back in 2019 I gave this diagram showing a kind of maturity or adoption model. You have early adopters who innovate on the technology, early majority of people that's where frameworks start getting built out. The late majority is where you get large enterprises and big prime time money coming into a project. Then you have the laggers who are only going to adopt things when it's like a turnkey solved problem. I put in here the spaces where I thought Node, Drupal and Java kind of sat in Java was just like for reference because I think between Java, PHP and JavaScript they kind of have a similar length of distance between them in terms of project maturities in the market. This is what I said in 2019. I think this is still probably more accurate today than it was back then. We'll go into a little bit more about this but I want you to keep in mind about where things are in terms of early adopters, early majority and late majority. This is a tier list that comes from the state of js.com. They did this in 2021 looking at framework, JavaScript frameworks as they are and they're kind of color coded by whether they're front-end frameworks, back-end frameworks or build tools or testing frameworks. Here you can see if you're not familiar with tier lists, S tier is like God tier, they're really, really good. A tier is like they're pretty decent. B tier, they're not that great and see they're rubbish. This is kind of how this survey is actually surveying JavaScript developers and asking them what they thought about the frameworks that they were working with inside the community. Here it's really clear that next js is a great back-end framework, it's largely preferred, as well as Vite which is a compiling or dev environment capability. Reacts definitely there in A tier. Also new frameworks like Svelte which is what Project Browser and Drupal was built out in as well as Vue.js inside of A tier. Just for time we'll keep moving on here. So in terms of usage, that top bar is React. So for front-end templating frameworks React has the most usage at 80% of developers having used it in the survey, while the next is Angular at 54% and Vue.js at 52%. So very clear that most developers in the JavaScript community have worked with React at some point. And when we look at back-end frameworks Express.js which is really just a better web server than Node.js itself is the top thing that everyone has worked with or used, but when we actually start talking about server-side static site-generating frameworks Nix.js comes up at the top at 45%, followed by Gatsby, Nuxt and Nest. This is builtwith.com looking at the top 1 million sites in the world and the technologies that they use. So the big graph here is React usage and you can see that React peaked at around 112 and a half thousand sites using it. So 12% there abouts in 2021. I've got two smaller graphs, you probably can't make out the y-axis on there, but you've got Vue and Svout and they're a much, much smaller ratio. So Vue was actually around the peak at around 60,000 and Vue was around about only at about 700. So they're much, much smaller levels of adoption, but this is a greater indication of if a top 1 million site takes adoption of a technology, it kind of shows its sense of stability. In contrast, by the way, I would say Drupal is about a fifth the size of React in the top 1 million. So there's definitely a lot more React usage in that space than Drupal. Speaking of Drupal, if we look at Drupal as a CMS contentful, which is a SAS based headless CMS, Drupal still has 10 times the amount of usage in the top 1 million than contentful SAS sites. So the SAS CMS kind of space is still really emerging for that kind of space. It kind of means it's more early majority adoption opposed to late majority or the stability isn't quite kind of there yet. So having a look at the top CMS in the top 1 million, there's a pretty good picture of how stable or resilient headless technologies are. If you look at them, you'll see WordPress is actually 30% of the market. Drupal is up there in third at just under 3%. The first headless front end Netlify doesn't show until about 0.82% utilization. So it's still really, really small. But all other headful solutions outside of Drupal and WordPress make up another 4.12%. All in all, that really means that headful solutions, coupled solutions are still the predominant flavor of sites in the top 1 million. They're not yet kind of fully in a headless space. If you look at this is a graph graphing Stack Overflow questions and engagement by language and GitHub ranks and projects. And so here you can sort of see the top on the y-axis is popularity of rank on Slack Overflow Stack Overflow, sorry. And on the x-axis is popularity rank on GitHub. As you see right at the top there are all the top languages and they are JavaScript, Python, Java, PHP and CSS, top 5. TypeScript is in there too. For those of you familiar with JavaScript community, TypeScript is TypeScript and so it's strange that it's almost measured as a second language because they are kind of almost like symbiotic to one another. In terms of top languages, you've also got JavaScript has been the top language. This is actually from GitHub from their Octaverse report. So it's been the main language on GitHub for a long, long time but the key here as you can see TypeScript of the last few years has picked up its pace. That black line is now sitting in fourth place and PHP has dropped down to I think sixth place. So it is definitely dropping in popularity as a preferred project among developers. This data comes from codingdojo.com. They are providers of developer education. So teaching people how to program essentially. And when they looked at preference of language by their education community you can see over the last five years that PHP has been the smallest and is continuing to decline. So new developers coming into our industry are prefer not to learn PHP they prefer to learn Python, Java, JavaScript, those sort of languages. And on the right-hand side is programming languages that employers were looking for in 2022. And unfortunately PHP is not on the list. It doesn't show in the graph. So it's not a language that people are looking to do things inside of. Those are other languages like JavaScript and Python. So to kind of summarize on suitability and market conditions Headless is an emerging and growing technology. It's an early majority trend still. Very low adoption in the top one million. Suggests solutions are not complete enough, like not turn key enough to reach mainstream consumers. Solutions developed on JavaScript platforms provide greater access to development resources. And Drupal and PHP needs to provide turn key node code capabilities that empower front-end developers and content managers to build that digital experience. So moving on we'll now look at technology maturity. This is just kind of looking at some of the key technological terms in the headless space and kind of give some definition about what those are. To start with there is a kind of composable reference architecture lots of different ways to deliver content if you think about you break down content delivery into store, render and serve those kind of pieces of the puzzle sit in different parts of the architecture in lots of different ways. So we have traditional Drupal where it's all done inside of Drupal there's partially decoupled where part of it is done outside of Drupal decoupled where the rendering is handled outside of Drupal. Headless and static where you're offloading a part of that static rendering into a back-end front-end and then serving it over to the true front-end and then you've also got the sort of serverless capability that's also an emerging space we'll talk about shortly. The other thing that's kind of happened since 2019 in 2019 I talked about the state of JavaScript that was presented by the lead developer of Chrome which he did in 2018 and since then the web's gotten slower so the media web page has way more JavaScript in it than it ever has had. It's got 161% more JavaScript this is by the way data from the httparchive.org and then the time until interactive has also gotten slower so although our devices have gotten faster over the last three years we've somehow managed to put more JavaScript in them that actually tanks them worse and this is a continued problem and yet 47% of users expect a maximum of 2 seconds loading time for an average website so let's talk about some of the ways that we try and fix that. This is the Jamstack kind of architecture and what that is based on is basically a back-end JavaScript process that does something called SSG that is static site generation that will go and pull your Drupal content over its API and build static renders of what you would otherwise render in the front-end the idea is that you can when it gets to the front-end it's already ready to render and you can get that first time to meaningful paint down really quick so that helps with SSG that then it gets pushed to a static store and then you serve a Node.js instance in the front-end that is going to basically store those serve those static files then frameworks like Next and Gatsby provide this thing called ISR or DSR and that's inside of SSR which is server side rendering ISR is incremental site regeneration this is a great place for 3-letter acronyms and incremental site regeneration basically refreshes that static site content as the CMS updates and it revalidates that it is so in a lot of ways Jamstack is using Node like we use Varnish today it kind of does it like that except that rather than priming the case once you've done a deployment it primes the case before you do the deployment and it actually means that you can deploy live it doesn't matter because you're just deploying static files that are ready to go so it's much higher resilience because it static files it's always fast and quick the kind of frameworks that are providing Jamstack abilities are Next.js, Next.js and Gatsby then on from there is serverless serverless is actually the same architecture but there's one key difference which is that there is an edge routing that's introduced at the top end and that edge routing is able to just go directly to the static store by being able to do that it cannot use Node.js and with serverless technology you can boot up that Node.js instance or is it that JavaScript script and run it when the request comes to that service to that SSR task with serverless you're able to basically be billed for the amount of time that you're actually using compute process instead of static store process and so you get another scale of efficiency out of that process but otherwise it's fundamentally the same thing as Jamstack there are a lot of different providers in this area so Versal do it, Gatsby Cloud does it you can use AWS Lambda functions if you're so keen to do it all yourself Cloudflare Workers also is another solution for this and Netlify Cloudflare Workers by the way also open source I dropped in Open Fasten here because I had Tom from Maisie Labs talking about it to me several years ago but it sounded like it wasn't kind of made it as far as an open source project but you can see here all the other projects are proprietary so serverless is kind of like a limited access place at the moment I think there's definitely work that needs to happen to try and make that a more of an open capability another sort of theme with this and this goes in line with what I was saying about the median page performance is as the code bases go up in size the performance goes down and so as all of these frameworks get added JavaScript applications, more capabilities and richer capabilities get added the performance starts to tank so this is another common thread another issue is something called hydration so we just talked about how you can do static site generation on the back on the back end and you can produce you can send static renders and you get a faster time to first meaningful paint but you don't get all the way to first time to first interactive fully ready to be interactive if you've ever had the experience where you've seen a web page come up and then you've clicked on a button the button hasn't worked yet that is the hydration problem and that's essentially you bring up a static render of your site and then you still need to bind all of the JavaScript capabilities because they haven't fully loaded yet and so that's something that is baked into a constraint of React this graph actually comes from builder.io who produced a framework called quick QWIK and they addressed this hydration problem by doing lazy loading of JavaScript not lazy loading JavaScript but lazy loading of JavaScript and so when you click the button the function downloads on the fly and then runs so you only download the executable code you need when you actually need it WebSockets is another technology that to be honest hasn't really matured a whole lot mainly because maybe in the content industry we don't have such a great demand or use for it but it is certainly developed into its own area so WebSockets essentially you need to push to a connection manager a connection manager is going to manage connections between you and the clients the clients are going to have open connections to the connection manager we used this with the Australian Open so we were pushing live updates of tennis scores to people who are listening on mobile phones and we actually used Abley in this case so we would publish Abley and Abley would relay that through WebSockets to all of the connected clients completely JavaScript and node based technology but a completely different use case and not something that you can sort of service with the SSR capabilities and the other infrastructures I've mentioned already so I wanted to kind of call that out here finally the technology maturity GraphQL is definitely something that has taken a deeper popularity and I took a bit more about how that's going to grow in the future or the way that analysts think it's going to grow in the future but to kind of explain this from a non-technical term if you think about it user experience now can actually start with a domain modeling discovery process so domain or data modeling was often something that DBAs once upon a time kind of owned as CMS experts we started owning it it now gets sometimes started at the UX level where the domain model is first understood that informs the user experience and the designs so that you get designs that actually make sense to implement and then you get your front-end developers who take those designs and start working with them and this is where GraphQL can kind of come in because if the domain model is understood you can sort of directly translate that into GraphQL and define that as the data model you want to work with GraphQL fundamentally lets the front-end decide and back-end dictate that and so it is much easier for front-end developers to work with and it's kind of agnostic for them to work with as well so they're less likely to care about what the back-end is and so I think it's GraphQL is often thought of as a technology but I would start to think that it's more an architecture rather than a technology because it really does change the way that you think about how front-ends and back-ends coalesce so technology maturity what about the CMS so when we looked at this headless space at AQUIA we felt like Drupal was kind of missing the mark in two key ways right one of the key things about headless is it's not really about the CMS it's not really about the back-end it's really about the front-end and we're a great community of back-end developers but we weren't doing enough to really attract front-end developers so we sort of set out to build a CMS that could cater to two key personas content manager and front-end developer inside of that we did a couple of things for the front-end developer we built an API dashboard so sort of centralized all the things that the front-end developer wanted to do instead of having them distributed across a Drupal admin administration menu that they didn't really understand or want to understand we also made sure that OpenAPI was installed by default and had Redock connected up to it so they could get access to the JSON API docks and then we adopted Next.js we contracted in Chapter 3 who maintained the Next.js Drupal libraries and they built for us the Next.js starter kit that integrated with our CMS and then provided like a great way to start building Next.js sites with Acquia CMS because we had that starter kit we were also able to build a content preview function inside of the CMS so that content managers can see what their front-end site's going to look like and it's completely integrated with content moderation so you can draft and you can preview in draft state and you can do that through Drupal access control as well. The other area that we had I guess is that's different or unique than the content management content management space is the ability to publish the omnichannel so you can publish to multiple Next.js endpoints and preview through different Next.js capabilities. Okay, so wrapping up into forward-thinking insights. Yeah, so thinking about CMS, headless CMS use cases, there's kind of two that after looking at all of the different capabilities and requirements, we've kind of consolidated them into two key market areas. One is what analysts like Gartner call back-end for front-end. That's essentially a scenario where the front-end, I've mentioned it was the front-end is chosen and then they go looking for a back-end to implement. In that kind of scenario, it's marketing-led or it's like a non-IT team that's leading the project and decision-making. It's a single-channel project so they're not looking to open up a publishing capability to lots of different spaces. Smaller budget, most likely as well. Budget for a new front-end but not like a massive undertaking of a back-end. The data aggregation is really going to still happen at the front-end so if you need to connect with third-party data sources, you'll probably do that in the front-end in the node space. That's largely because your project is probably going to have no developers on it, not PHP developers on it unless they're full-stack. Layout composition is going to be a requirement and that's going to be a requirement for the CMS. That needs to be there de facto but it's a CMS for a channel opposed to a content service and something like a media library is all they're going to really need for that. On the other hand, at the other end of the spectrum would be the content service scenarios. That's where there's more like a business and IT partnership happening on the customer side. They're looking at something that's going to transform their enterprise as a project opposed to a much smaller budget project. As such, they'll have back-end and they're going to aggregate data behind an API gateway like that content service example I showed earlier and then layout will happen and composed by channel opposed to being inside of the CMS. Composition won't be a CMS capability. It's going to be a content as a service and it's more inclined to be integrated with things like digital asset management rather than Drupal's media library. More sort of like analyst thinking here by 2025 more than 50% of enterprises will use GraphQL in production environments up from 10% in 2021. The graph on the right hand side there is of how Gartner gets the frequency of Inquiry's Gartner gets broken down by API type. It might be a bit hard to read but the big blue bar is saying OAS plus rest. OAS means open API specification which basically you can translate into Drupal speak as JSON API. So right now there is more JSON API demand and interest from Gartner clients at the very least than GraphQL but they anticipate that will change in the next three years and there will be much more GraphQL demand. So that kind of tells me as a product manager that we need to have more GraphQL capabilities as a part of our CMS verbatim. So finally kind of looking at some of these from an architectural standpoint what does back-in-for-front-end look like architecturally speaking and content service. So in a back-in-for-front-end architecture you're going to have your integrations at the bottom there, things like e-commerce, CRMs, dams and pimps they're going to be consumed by your CMS through out-of-the-box modules that you can plug in and integrate with those things and you might even do content syndication and so you're not really following a mock architecture back-in-for-front-end model. You're going to consume that through there and because you're consuming all of your data into your CMS all of that data is available for you to build and layout management with. So if you want to embed content into custom layouts you can do that and then you can expose those restfully to your front-end like Next.js to go and do its renders. The Next.js flows it up to your sort of distribute layer which is either a static site or a mobile app or a kind of IoT capability. Inside of a content service architecture however you can see it's much more complicated. This would be more of a mock style service architecture. So you have a data services layer that again a more cloud-native SAS they're all SAS capabilities they don't talk to one another and they shouldn't talk to one another out of principle or policy. So they all surface up their capabilities through an API gateway and in this diagram here I've suggested that that is a GraphQL mesh. So you kind of put GraphQL and API gateway together as a single place to consume from. That then goes into either directly to the front-end as a Next.js consumption or you can route it through a composable layout manager layer and we don't really have a sort of solution for that. In the middle there are some tools out there I'm happy to mention them but that is a key point here is that layout management is decoupled from CMS capabilities in the content service architecture and one of the key reasons for that is because you're composing your pages with more data than just your CMS and so you don't actually always in these kind of scenarios don't always want to have those two things coupled together. So AQUIA's journey on this is we kind of did a bit of analysis and figured out that we have a bunch of gaps to kind of fill up and how we can make that path for Headless. So we kind of put together a high-level roadmap after kind of analyzing that and I don't know what you can kind of see of here but this is, I guess, just kind of like a high-level roadmap. We've got over 2023 to build out new Node.js hosting capabilities integrate Webform functionality out of the box with Webform module and React components integration with Wide and Dam improving opinionated configuration management and automated development. So we've got PHP as some sort of maintenance work we have to undertake building a layout builder for Headless capabilities at least in that back-and-forth front-end scenario bringing in a Headless CMS SaaS product as a beta by the middle of next year and introducing something called I call codeless recipes. If you're familiar with Project Browser as a core initiative and another one of these recipes and if you can stop pushing those through a composer project and delivering them over a restful service you get codeless recipes and this starts to create this ability to extend Drupal without having to add code and that I think is a really significant and necessary part of extending Drupal longer term so that we're not so dependent on somebody else's PHP code to be able to extend and integrate with third-party capabilities. And then finally GraphQL support is something we also want to make happen as well. But to kind of make sure that we do this, we actually put together a Headless Developer Advisory Board. That board is really key for us. We have invite members of our community and our partners to that board and they help us with this roadmap. We basically tell them what the roadmap is present to them any new products that we've developed and demoed and then we get their feedback and help let them tell us their stories of what they've been doing with Headless, what's good, what's bad, what should change. We share with them their roadmap, they tell us if it's good, if it's bad, if it should change and it's a really great relationship to have to be able to let the people that want to use our products influence the roadmap as they should and we really want to make sure that that is a developer centric driver post to a customer centric driver as well. So we do that for people who join. So they get to provide feedback to our Headless products and roadmaps. They get early access betas. So next quarter we have plans for Node.js betas for our Node.js products. We conduct one-on-one meetings with our product teams, with those people who understand what they're doing and what they want us to be doing. And we also provide publishing opportunities on our df.acquia.com community for people to express leadership around that as well. So for us, that's a really important part of our journey. We really want people to come on board and join. For the last two quarters, it's been something that's been kind of closed and invite only but in this quarter, we're happy to kind of open this up and I don't have any partners from the APJ area APJ being Asia, Pacific and Japan, inclusive of Australia and New Zealand. So we don't have anybody in that board advising us as part of the world. So what I invite you to sign up and join. If you scan that QR code, you'll go to our landing page where you can learn more about this, read a bit more in depth about it. The sort of base requirements is that you attend a quarterly meeting where we present and demo. You fill out a survey that happens at the end. We also host optional monthly check-ins where you can just jump on a call with us and chat and ask questions and make demands and what have you done. So all the stuff that I work on, which is Acquia CMS and Next.js data kit stuff is all open source and it's all available in the community up on GitHub and so you're also welcome to be a part of that and contribute, trial it out, have a look at it and submit a report request if you really want to. So I'm not sure what we're doing for time, but happy to take questions if we have it. Yo, is there a mic? So what about using Drupal as the front-end and then into the Drupal to automatically create content items? Will that be headless as well or is that something different? Because I work at a government agency and we've got tens of thousands of documents that need to be published onto our website. So we've got a feed that feeds into our website to create content items for those sorts of content. The management of content is a back-end task. That is a back-end capability and if you're building your front-end look and feel from a back-end capability, I guess the whole premise is that you're limited to it. So you're coupled to it as well. So if you wanted to build a new front-end or the front-end that you want to communicate on changes, you're kind of up a paddle with no, up a creek with no paddle, is it cool? So that's kind of the problem with that capability. So to answer your question like Drupal's not really a headless front-end in that scenario, but it is your layout manager, it is your front-end, right? So that's not a headless architecture, that's just a coupled architecture. Paul. Thanks for the presentation, it's fantastic. So my question is slightly outside of what you presented here and it's slightly provocative as well, but it does underpin the success of what you presented here and it's touched on a point regarding PHP and it's the interest of PHP by developers and also employees. Based on that point what's your opinion on the long-term viability of Drupal? I still think Drupal's incredibly viable. It's a very mature CMS, it's got rich capabilities and the no community is not trying to solve that really. They don't need to solve what we've already solved in that regard, they're trying to provide something new, which is new front-ends in new kind of ways. I think Drupal's certainly still more viable but I think the way that we have thought about delivering it is changing. So it's not that we will get Drupal jobs where we are building the front-end out, well I mean this is the definition of headless, right, is that you're not building the front-end out with Drupal, you're building the front-end out with Drupal, you're building the front-end out with Drupal, you're building the front-end out with Drupal. So we've covered earlier at the beginning of the presentation the suitability for headless and there's certainly a space for it, so there's still plenty of space for coupled-based builds and when we're doing coupled-based builds then you still use Drupal the way we always have and do Drupal projects that we always do and you don't need to focus development time and customizing the CMS so the role of a PHP developer or Drupal developer in that project is much more minor if not completely absent. That's not to say that Drupal is not a part of it, right, so and this is kind of why there's a that push towards cloud-native SaaS, the mark architecture is that you can still have Drupal providing those kinds of capabilities. I still think that there's a big space of differentiation of Drupal and being able to create lots of different vibrant distributions of Drupal and the recipes module being able to deliver those different capabilities in different ways so I don't think that we'll have like a diminishing market for Drupal necessarily but maybe there's not as much PHP work in those headless projects I think that is something that is going to possibly happen, yeah. I'll come on, not on that bombshell. Thanks this may be two technical questions to specific, it's just for the headless I'm working in the test automation area so headless we are trying to testing the API for the headless Drupal which we not sure how to do with where is the best practice, do you have any suggestion like contract testing kind of things, thanks. What are you trying to test about the API? So we have Drupal as an API provider and they have possible API consumer like front-end applications or multiple in the future so how can we make sure Drupal release we don't necessarily sync the release with front-end applications how can we make sure we are not breaking the front-end applications that's the purpose of testing. Yeah so the early way of solving that was API versioning which is a prim and nightmare right and like if you think about a headless scenario where your headless front-end is a mobile app and now you've got all these different clients installing different versions of your app on their phones trying to interact with your API changing it, making a change to your API is freaking difficult, let alone the fact that you have to keep backwards compatibility for a long period of time as well until the attrition of those older versions have kind of churned on those platforms so it's actually a really difficult problem basically you have to think about how you introduce change to your API for example you can add fields but you can't remove or change them that might be a kind of constraint to using something like JSON API but something like GraphQL however is much more different because in GraphQL the schema is kind of defined by the client they manage their own API and their own API changes and there's no longer your problem to deal with so you still have to kind of provide the consumer services but there is this like layer of abstraction that actually de-risks the challenge of API changing I know I haven't answered your question around testing of the API but I think like I think about it and go what's it a test you have to make a curl request and it comes back with data and if it does that then it works and then there's obviously performance constraints to that or security considerations or what have you so you can certainly build up assertions around those things but I'm not kind of super clear on like a testing framework for APIs in particular but certainly to protect yourself from versioning there are certainly architectural changes like GraphQL that you could take or policies like not modifying fields that can help with dealing with those things there's a better note to end on anyone else? Yeah sorry, thanks for your talk it was awesome so I'm thinking the layout builder is kind of the biggest problem that we need to solve before we can kind of go all in with headless builds so yeah I'd like to just get your opinion on what that like middle solution would look like I guess Yeah so the key is like layout, the role of layout is different between these two architectures one can be inside the CMS and the other one, oops, cannot so that I think is one of the considerations and there are different market solutions kind of tell you which part what kind of solution you're building with headless I know there's some pretty talented guys called Stregen who have actually solved the layout builder integration so they've got some great demos of how they can use their CMS to use layout builder and expose it over an API and render that out in XJS in Angular and Vue so you can do layout building with Drupal Core and expose it so I'm not sure that that is necessarily a problem although it's not true, it's not like you have a place in the CMS where you get to do that composing but then it's another tab or a different place where you're doing the previewing of that okay I think but there are also solutions out there where you're editing what you're seeing and that is what it is and it's kind of real time informing and editing and that's kind of more like in this architecture what layout manager is going to be and also like consuming of multiple types of content so the real challenge for CMS is if the CMS exists in the microservices layer it's not allowed to talk to the other systems it can't ingest content from those systems and so it's the composer that needs to do the layout management and then you actually need to think about how do you make a great UI and the composer layout capability to there's also a learning challenge for content managers if you're a content manager and you're used to both creating content and managing the layout of content inside the same tool the idea of having them in separated tools is stupid so they'll want those two things so I can also see a need to want to compose something in the layout manager but also create content in the layout manager which suggests you might need to use GraphQL mutations or something to be able to push that data back through to the CMS or to whatever system that data kind of belongs inside of yeah so I think this part doesn't have the layout manager in here doesn't have to be Drupal right it could be something else I'm not familiar like there's like a project called Grape.js it's like an open source project that could be that composer layout manager but it doesn't have the ability to pull in GraphQL data for example or third party data to be able to build your experiences so I do think that that's a problem space to kind of mature and solve before this becomes more of a standard practice and until such a time we'll see more of that type of scenario where and I definitely think that the majority of gigs right now are like this where you do need to have layout management inside of the CMS and it's a luxury right but it's also like you've got a Drupal developer handy so it's quite easy to do a composer require and add a module to integrate your CRM or whatever it is that you need to do so there's still plenty of opportunity space for that but you can imagine from a business standpoint or even an agency standpoint you might not want to have to resource both PHP capabilities and JavaScript capabilities so if it's you just have a JavaScript developer on the project that's more economical it's more competitive right so you want the CMS to be kind of turnkey and out of the box ready to go This is probably a little bit of a naive question but Drupal seems to have a lot of good mature features for Headless it's great for administering complex content commissions are pretty sophisticated a lot of things like that so just as a pure backend system it's it's pretty ready but I suppose whenever you're studying a new project or doing something new you want to look at not just how can I make Drupal do this job but also are there better options out there I suppose I'm aware of a lot of frameworks and things like that like instance Laravel or Spring Boot things like that where you can build backends they can do exactly what you need but I'm not really aware of any other any CMSs that are actually would actually be competition as a headless solution like I think you mentioned Contentful before and obviously there's WordPress but what is Drupal competing against as a headless CMS Good question so if you were to do a Google search for top headless CMSs you'll find lots of top tens and they won't include Drupal in any of them so the content Contentful CMS is the sort of primary SaaS CMS people can use and it's free to use so it's a SaaS service cloud service but you can use it freely and that gets developers familiar with it really quickly this content stack which is more of an enterprise version of a headless CMS and completely proprietary as well and there's a whole range of open source ones so there's things like Ghost CMS or Strapi is another really common one so all the node based CMSs are interesting because they are also single page applications which means the experience of data modeling with Strapi for example is much more elegant than data modeling with Drupal and if a JavaScript developer has to choose the backend for the customer they're either going to want to choose something they don't have to manage so it's a SaaS service or they're going to choose something that they can manage which is going to be a node project Drupal doesn't come into consideration when you ask a front-end developer what's your favorite CMS to work with so that's a problem space that I have to work on at AQUIA to try and change that perception by connecting more with the front-end community and help showing that Drupal is not a traditional CMS that it's just as good as a front-end because I agree with you there's a lot of capabilities in Drupal that make it very suitable for headless development I just don't think the community is as aware of that as they could be right thanks everybody