 Hello, Kontak. Hey everybody, how's it going? How's Drupal Khan so far? Oh, come on. How's Drupal Khan so far? Come on. Whoo! How is that keynote this morning? Amazing, right? Yes. So I'm just gonna kind of riff for just a few minutes while we wait for some people to come in. Just to give you a little bit of a preface about what this presentation is, this is meant to be a relatively high-level introduction to decoupled Drupal. And so if you're technical, if you're not a coder, if you're an architect, if you're a business person, if you're just a Drupal user, this session is for you. If you've always wanted to know about what the underlying concepts are behind decoupled Drupal and what this whole catchphrase actually means, this is the session for you. So how many people only heard the words decoupled Drupal this morning, Injury's keynote for the first time? Okay, we got a few. We got a few. How many people have built something with decoupled Drupal? All right, we got quite a few. All right, so this might be a little bit of old news for you. And how many people are not developers? How many people are just a Drupal Khan just to kind of see what's going on? Great. This is awesome because this presentation's not gonna be a whole lot of coding. It's not gonna be a whole lot of demoing. It's really gonna be an overview of the entire landscape. And for those of you who have seen some of my previous talks about decoupled Drupal, you'll see some familiar elements, but this is actually a complete revamp of that previous presentation that I've given in the past. So with that, let me just see the time here. Let me go ahead and get started. We'll let some people filter in. Welcome once again to introduction to decoupled Drupal. How does this view come in? My name is Preston so I welcome you today to this session. The hashtag if you'd like to use it as intro decoupled Drupal. I've been a web developer for about 16 years, and I've worked with Drupal for about nine of those years. And currently I am director of research and innovation at Acquia. So what we're going to talk about today is first of all, what is this thing? What is this decoupled Drupal thing that everyone's so excited about and people cannot stop talking about? And what is it that is so interesting about it? What is it that motivates people to explore decoupled Drupal? And why is it so interesting? We'll talk about from a technical standpoint, not too technical, I promise, how exactly the decoupling occurs from the front end, from the back end? What is it that involves developers in this system and this architecture? We'll talk a little bit about the risks and rewards of decoupling Drupal. What are some of the problems that people encounter? Or some of the advantages that people encounter uniquely when they decouple Drupal? I'll delve briefly into web services and REST APIs, which are kind of the bread and butter and the underlying foundation of all decoupled architectures that involve Drupal. I'll talk about developer experience and editorial experience. And finally, I want to end on a little bit of sort of meditation on what decoupled Drupal means for Drupal's future. And I think this will be very important, especially given what you heard in Dries' keynote today. So first of all, what is decoupled Drupal? How many people have seen the movie The Martian? Okay, great. Quite a majority of you. That's great. I mean, you know, I'm a big fan of sci-fi movies. I love space movies. And I like to use the Martian as an example of what exactly decoupled Drupal means. Because if you don't know the story of the Martian, what happens is Matt Damon plays an astronaut who is abandoned on the planet Mars. And he discovers that all of his communication controls are completely obliterated. He has no way to get in touch with mission control back home on Earth. And so what he does is he invents his own communication protocol. I won't get into the details and I won't, you know, I've already spoiled some of the movie obviously for you. I apologize for that. But what happens in the movie is that he is able to reach Earth and contact Earth by using his own kind of communications protocol. So when you think about this from the context of decoupled architecture, you can think of Earth as one contiguous unit, a single inseparable chunk of landmass that is floating around in space. It's a monolith, simply put. I'm not talking about this monolith and I'm also a fan of 2001 Space Odyssey. We're not talking about a Tower of Stone or a monument. What we're talking about is a single contiguous piece of rock, a single piece of rock, a single system that is inseparable from itself. It's inextricable. All the parts, all the components of that rock are inextricable from each other. And that's Drupal. So what happens is in the movie, there's a base on Mars and Earth will receive requests that are coming in from Mars, these messages that are coming in from Mars. And what happens is Earth actually responds to those messages with responses. And if you think about it, these decoupled bases are decoupled from Earth. They're separate from Earth. They are sort of artifacts of man on these other planets, but they are completely separate from Earth. They're decoupled. So this sentence here really illustrates what it means to be decoupled. Drupal is a monolithic CMS just like the planet Earth. The components of Earth cannot be separated from each other just like the components of Drupal, at least out of the box. But Drupal, in this case, backs these decoupled applications. And so all of these applications that are on different bases, on different planets, all consume content, all consume messages from Drupal. So what does that mean? What that means is that you can consider a Drupal site to be a single website or a repository for content, a content service, if you will. And what happens is these requests and responses, these messages that are going back and forth, these communiques, are HTTP requests or HTTP responses. Now, if that's throwing you for a loop, hang on for just a little bit because I'll explain all of this terminology. But if you think of Mars and this based on Mars as a decoupled application, this really actually helps us to illustrate metaphorically what it is that we're talking about. So in this case, we have an illustration, a schematic that really shows really well what are the different components of a decoupled Drupal architecture involving one single decoupled application. You have a site or a repository built in Drupal. The site could have a public-facing front end that is consumed by your end users of that Drupal site. Or it could be a private repository that no one has access to except for your JavaScript applications or any application that you might want to build. Now, the key components here that I want to really stress here are that the REST API serves as an arbiter, as a gatekeeper for those messages. It transmits messages from Drupal out to those decoupled applications. And on the client side, on the application side, you have an HTTP client which ingests those responses and translates them into things that applications can actually then use. So simply put, decoupled Drupal is the use of Drupal as a content service for consumption or manipulation by other applications, which means that we're not talking about Drupal as a single website. We're talking about Drupal as a single centerpiece of a vast ecosystem potentially of many different applications. So Drupal can be used to back other backend applications, like if you're writing a Rails app, or if you're writing a PHP application, or if you're writing something in Java, as well as native mobile applications or native desktop applications that can communicate with Drupal. Single page applications in JavaScript, for instance, digital signage, augmented reality interfaces, and so on and so forth. Now, what really is crucial on the Drupal side to make all of this happen is web services. And I'll explain a little bit later what it is that web services actually means as a term. But web services like the CoreRest API, the JSON API, and Drupal Contrib, and GraphQL, these are all typical entry points for these applications, these Drupal consumers, these decoupled Drupal consumers. Consumers are the applications that actually ingest content from Drupal. So this architectural diagram really demonstrates very clearly what the difference is between a monolithic and a decoupled Drupal architecture. On the left-hand side, you see a monolithic architecture, the Drupal front end that we know and love with twig and the theme layer, and everything that you are used to when it comes to Drupal, things like in-place editing. That is actually a component of Drupal that is inextricable from Drupal. But once we introduce the concept of a REST API in web services, we can actually convert the data that is in Drupal into what's known as JSON, which is a format that can be used by decoupled applications to actually introduce data into their applications. So the right-hand side shows you that the decoupled application handles all of the front end concerns. Now if this is still a little bit confusing, we're going to spend a little bit of time on these architectural diagrams. The crucial thing I want to mention here is that any application that you can imagine can consume Drupal. In this case, we have a single-page application running on JavaScript, and that could be something that's using Node.js. On the right-hand side, we have a native Android application, a mobile app, which is in written in Java, and this is also consuming Drupal. But the thing I want to emphasize here is that Drupal can serve as this centerpiece of any number of various applications that you can imagine. So when you think about it, it's just like Earth having a whole bunch of satellites and a whole bunch of bases orbiting around the planet. This is a really interesting image because what it shows is that not only can you use any language in front of Drupal, you can also actually use PHP in front of Drupal if you so desire. Now I want to take a little bit of a brief moment here and explain, well, what's with all the terminology? We've heard a lot of different words all over the course of this kind of trend. There's decoupled, there's headless, there's API first. What do all these words actually mean? Well, decoupled really comes about in a microservices architecture discussion. So when you're talking about let's make every component have a single purpose and a single sort of input and output that is really easy and make sure that every single architecture that we build is actually a conjunct of these small simple components. That's what decoupled means in this context. And what's really nice about using the word decoupled to describe decoupled Drupal is that Drupal can serve as the front end also for any number of systems such as a CRM system or an e-commerce system as well. Headless is a term that a lot of people use as well and it's usually used to refer to a single application, a single page application that often is consuming that CMS. But headless can be a little bit misleading because you can have things like bodyless or and there's a whole lot of new words that have been introduced. But the reason why headless is a little bit misleading is because headless in the original software architecture context means software that can be consumed without using the UI without using an actual visual interface. But we already have that actually in Drupal. We have an example of headless software in Drupal right now which is Drush and there will be a presentation about Drush in this room next. Drush is a command line interface that allows you to work with Drupal and operate Drupal in a headless way. And so this is the reason why I prefer to use the term decoupled because it really is illustrative of the different possibilities that are available. Now what about API first? API first typically is used to describe technology or an architecture that is focused on designing the API first and foremost. The API is king. The API is the most important component of this architecture. Now in Drupal's case when you work on a decoupled architecture and you have decoupled applications that are consuming Drupal from that standpoint, you have to make sure that the API is very robust. And so when you hear the term API first, oftentimes it means that a big focus of those developers is on making those APIs robust. Now what are some of the motivations behind decoupled Drupal? Well for marketers and for publishers, decoupled Drupal really offers that promise of omnichannel delivery, of delivering content and publishing content everywhere on every single conceivable channel. Whether it's a Roku application or your Apple watch or the screen on your fridge which doesn't exist yet and it's a little creepy to be honest to have a screen on your fridge. But these are all things that can be powered by Drupal and can receive content from Drupal. And this is a really crucial problem in the CMS space right now because we're really no longer dealing with just CMSs. We're really starting to deal with other channels, these new interfaces, these new experiences, these new environments that are now ways to experience content and consume data. All of these new devices every day have to have some kind of a data source, have to have some kind of an underlying storage system to house all of that content and all of that data. Now the other thing is that we also have channels that are coming about that we've never heard of. In the next five to ten years IoT front ends for instance will become a very large part of the way that we consume content. So when you think about the fact that all of these new channels are appearing, all of these new experiences are really changing and revolutionizing the way that we consume content, whether it's through augmented reality, whether it's through our raspberry pies, whether it's through our Amazon Echo. All of these technologies point to a future where we have to think about content in a decoupled way anyways. And so it's a good idea to think about this right away from the standpoint. Now what about for developers? We've talked about what it means to be decoupled and what it means to use decoupled Drupal from the marketer standpoint or for the editor standpoint or the publisher standpoint. But for developers decoupled Drupal offers the promise of front end freedom. How many people in the room have tried React or Angular or Ember or some of these really nifty front ends, right? So a lot of us have. And oftentimes this can be a somewhat freeing experience because of the fact that Drupal has a lot of expectations for how the front end delivery works. So if we think about what it means for developers, let's delve into a little bit about why it is that people are so interested in decoupled front ends. I want to give you a little bit of history, a little bit of context, and give you a nice kind of trajectory of how it is that developers have gone in this direction. So you've seen this before. This is once again the monolithic Drupal architecture. You have a Drupal front end once again that is inextricable from the rest of Drupal. And you have a divide here. As you can see there's a line separating the client side from the server side. Now, originally in the late 90s and early 2000s before the advent of AJAX, what used to happen is that if you had no caching on Drupal, and this is once again if you have no cached system, if you wanted to have a form like a subscribe to our newsletter form, and then submit that form and get a new state of that application, a new application state that shows that the subscription has been successfully registered, what actually happens is that you have to incur two bootstraps. By bootstrap I mean that you have to go through the entire process of Drupal twice because you're actually creating a full page refresh. You're actually causing Drupal to have to go through its entire pathway to rendering out this front of experience twice. Now, when you look at this, and once again this does get a little bit more complicated, but I want to try to explain this in the clearest way possible, which is that once we introduce AJAX, once we introduce jQuery and have all of these possibilities of going in the asynchronous direction which means that we're no longer just having full page refreshes. We're actually having asynchronous requests going into the server while our page is already loaded on the client side. Now, you've probably seen on the right side this kind of experience before, where you hit submit and instead of you having to see a refresh of your browser, you actually get a little spinner, a little loader, and then you get a little success message. And our AJAX framework in Drupal actually works in this way. If you've ever seen that little blue circle that kind of spins around every time you conduct a search, that's the kind of thing that you're seeing here. So this is an example of client side JavaScript. This is an example of JavaScript being solely available on the front end. And in the past, we had jQuery. And this is something that Drupal adopted very early on and was a very early adopter and actually led to possibly a great deal of popularity for jQuery. Now, there's other ways to do client side JavaScript as well. Because what if you want to have a JavaScript framework like Angular or Ember or React actually take over from the page for you, actually go ahead and actually hand off the page over to a JavaScript framework. In this context, the reason why people wanted to do this is to do things like client side rendering. Instead of having, let's say, just a little message pop up or just a little part of the page replaced by an asynchronous response, what if we actually re-render entire parts of the page on the client side and go ahead and actually make this a lot more powerful and illustrate application state in this way. So what happens here is that you have a JavaScript application framework that is submitting an asynchronous request just like Ajax over to Drupal, getting a response back, and of course, you see the page reload. Now, sorry, a portion of the page reload, not the entire full page. Now, this idea is really interesting because as you can see on the right-hand side here, what we're doing here is we're actually separating the page into different concerns. So on the left-hand side, we have our content which is governed by Drupal. It's the left-hand side of the layout. On the right-hand side of the layout, we have a dynamic application, something that requires a little bit more client-side state management, a little bit more of that client-side interaction. And so what you're seeing on the right-hand side is controlled by the JavaScript application framework. Now, recently in the last four to five years, we've had what many people have termed the JavaScript Renaissance, which really brought in this interesting era of innovation and development practices and new ways of actually using JavaScript. And of course, one of those is server-side JavaScript, which is the idea that back in the day, I used to write JavaScript back in the day, and people used to kind of say, oh, well, JavaScript is just toy language. It's only on the client side. You can't do anything really actually cool with it. It's not really a proper language. And that was really the result of a lot of browsers having different implementations and different ideas about how JavaScript should work. But server-side JavaScript really changed that because now, JavaScript is serious. Now, it's the real deal. Now, it's actually meaningful and weighty because it meant that client-side frameworks could be executed on the server-side. So universal JavaScript is an idea you might have heard the term isomorphic JavaScript. This is an idea that involves shared code in the form of JavaScript framework executions. Now, if you're really confused by what that actually means, let me just show you exactly what that means. So in this case, we have server-side JavaScript on the right hand side that you see here. And it's powered by Node.js. And what we're actually seeing is that we have two executions of the same framework. So if you load Angular in Node.js, it will execute on the server-side once, give you that initial state of your application that you have on the client-side. And then from that point forward, the execution on the client-side of the framework takes over. So there's a handoff just in the same way that we had before, except this handoff is able to share code between client and server. Now, what this means is that now you have synchronous requests that are going to Drupal because Node.js is executing a framework and having to render, and that goes to Drupal. And you have an HTTP request that is happening asynchronously every time the client-side updates and state. And so what you're actually seeing here is a fully decoupled example where every single portion of the page is governed by JavaScript. So this is an illustration of how universal JavaScript works in a non-Drupal setting. If you just have a Node.js- driven web service, you have a framework that's executed server-side. What happens here is that in a synchronous fashion, Node.js will execute the framework and get you the data that you need by going to the REST API or whatever data source Node.js provides. It could be a MongoDB database, for instance. It renders out that HTML. And then it actually flushes out to the browser that initial state of that HTML. From there, the JavaScript framework that's loaded on the client-side will actually perform the bindings necessary to update that state, will perform rehydration, if necessary, or other client-side state updates as needed. And from then on, any updates that are needed further on the client-side, any asynchronous updates, any new client-side updates will go through this asynchronous process of going all the way back to Node.js. Now, what does this mean in the Drupal context? What this means in the Drupal context is that Drupal actually serves as a gatekeeper, as an arbiter, of all of these different messages. Both on a synchronous level and an asynchronous level because you have Node.js executing the framework which calls Drupal's REST API and responds back. It renders out that HTML. And then on the client-side, what happens is anything that needs to be updated will also go back straight to Drupal. So this is the way that decoupled Drupal architectures using JavaScript typically work. Now, this is very powerful because what it means is that you can actually share the same framework across server and client. And this is a very, very interesting proposition for a lot of people. And for a lot of developers, it's really a very unique idea. And it's something that Drupal doesn't have. So this is what we call fully-decoupled Drupal. This is what we see as being a Node.js server in front of Drupal serving out the front end. And the front end has no control by Drupal. You've probably heard the term progressively decoupled Drupal which actually involves, rather, an interpolation of this JavaScript framework inside of the Drupal front end. In this case, Drupal still controls the entirety of the front end and still controls a lot of these issues. But from the point that the client side appears, from the point that Drupal flushes out that markup out to the browser, then you have the framework takeover from there. It's a different kind of handoff. So what are some risks and rewards of decoupled Drupal? Well, first of all, a lot of the reasons why people like to do decoupled Drupal is because of separation of concerns. This idea of structure versus presentation. I want to separate my content from my presentation. I don't actually want Drupal to have any control over my visual presentation. Similarly, I don't want my front end to have any control over how the data is actually provisioned. I want to be able to just have data structures that I can consume very easily. One of the other reasons is pipeline development. If you haven't heard this term, what it means is that you have two teams working in parallel against a single API. So if you have an API in the middle that you've already designed and built out and it works great, even if it's just a dummy API that doesn't actually work, an API designed first approach gives your front end team and your back end team independence because the team that's working on the JavaScript or the team that's working on the other application and the team that's working on the back end, the API in Drupal, can work independently and in parallel. Also, a lot of the reasons why I hear people liking to use decoupled Drupal is because you can have the opportunity to hide the CMS. You know, one of the things that I've heard from a lot of security folks, I don't know if this is actually, I'm not a security person, but keeping the CMS far from public view and keeping it so that random people can't log into it is actually increasingly a best practice that I've noticed. And also, one thing that I do want to say, which is a bit of an interesting characteristic, is easier resourcing. Nowadays, everyone's learning JavaScript. Nowadays, Drupal developers are oftentimes considered a little bit more expensive. And so when you consider that you have all of these front-end developers that are a lot cheaper than Drupal developers, you get to the point where you're having a lot of push and a lot of demand for decoupled Drupal. But there are a lot of risks of decoupled Drupal. The first is that you lose contextual administration and editing. What that means is that crucial features that were introduced in Drupal 8, things like in-place editing, things like the toolbar, or things like contextual links that have been part and parcel of the Drupal front-end for a very long time, which are oftentimes used by editors, are lost completely, because you can't actually introduce those into a JavaScript front-end very easily. Or any other native mobile front-end, for example. Also, maintainability. Now you have both a Drupal service and you have consumer applications that you have to manage. So this requires a lot of planning and a lot of thinking about how your team's gonna operate and how you're gonna manage your project. There's also an additional point of failure, because now that you're not using Drupal as a monolithic architecture and you're introducing other services and other components to your architecture, what this means is that things like Node.js downtime or things like downtime of your application server can lead to completely inaccessible content, because now Drupal is not accessible in the traditional way. So once you introduce something that's in front of your LAMP stack that is powering Drupal, it really causes a lot of problems. Also, there's a lot of onboarding overhead, because the developers who are building these applications need to learn how to consume Drupal's APIs, need to learn how to consume Drupal's content. And Drupal developers have to change focus and learn about how to make their lives easier. So this kind of transactional change is very interesting. And one thing that we see very little of, sort of, we see a lot of these days. So here's a summary. As you can see, all of these four areas, and this is once again an inexhaustive list. This is not a sort of comprehensive list of the risks and rewards, but this really demonstrates to you that it's really about thinking about what it is that's really good for you. If you're on the publishing direction and you want to be able to really serve applications that are whatever on whatever channel, then Decouple Drupal might work, but there are a lot of trade-offs. So I want to make sure that we understand that. Now what are web services and REST APIs? So once again, I talked about this diagram here, which shows that you have a REST API, which serves as the arbiter, the thing that serves out the messages, and ingests those requests from those clients. What you actually have is web services. Now, if you're confused and you're like, well, didn't you just say REST API for the last 30 minutes? What's interesting is that there's a difference between the term web services and REST API. Simply put, and this is a definition that was written in 2002 by the World Wide Web Consortium, the W3C. Web services support interoperable machine-to-machine interaction over a network, which means that it enables communication between any sort of system that you can imagine, any application that you can imagine. REST APIs, on the other hand, actually follow certain principles, and these principles were promulgated by a gentleman named Roy Fielding in his PhD dissertation who wrote that all of these architectures that are services-oriented, that have to have all of this communication across different servers and different applications have to use certain methods that are available in HTTP. And the reason why is because the entire World Wide Web is already built on this architecture, on this communications protocol. So why don't we just reuse that when it comes to these communications? Now, this is a really quick glance of the Drupal Web Services ecosystem. It's not exhaustive, and I know that this is a lot to handle, but the thing that I want to really emphasize is this. You have a variety of different web services modules that are available, various things that can replace that green box from earlier. You have the core REST API, which is available in Drupal out of the box. You have JSON API, which has been introduced in the contrib ecosystem. You have relaxed web services, which is another contributed module. And of course, you have GraphQL, which is a buzzword I'm sure that some of you have heard. Here's a little bit of an illustration of the differences between REST APIs and web services. In Drupal's core and Drupal contributed modules that are involving JSON API and relaxed, those are traditional REST APIs. But GraphQL isn't actually following those REST principles. And I'll show you just briefly why that is. The core REST modules give you every single content entity, and also by the way, configuration entities in Drupal, exposing those out to be consumed by any application that is decoupled, any application, any client, any consumer. And Views also has this new REST export display type that you can use. So unfortunately, what happens is, let's say that I wanna have a node, and I wanna request a single node from Drupal, a single piece of content from Drupal. But I also wanna request that author. I also wanna get that author of that piece of content. Right now in core REST, you have to make that request twice. You have to issue two requests from your consumer application. Now what that means is that you incur a lot more of that sort of network latency because you're having an issue two requests, you're having to do a whole lot more work. But one of the really big benefits of JSON API is that it gives you relationships. So for example, there is a relationship between authors and the content that they author. JSON API is a specification for REST APIs that serve JSON. And it's popular among JS developers and it's been adopted by both the Ember and Rails communities, which means that if you're building an Ember application or a Rails application, you can really easily consume Drupal as a back end. JSON API provides relationships, as I said. And so this really shows you, oops, sorry, there's the URL by the way for the project. And also there's a lot of different operations that you can perform on the queries for JSON API. But fundamentally, if I provide an include, if I provide an additional parameter in my request, I can actually access not only the piece of content that I want, but also the author. And in this system, any other related entities that are there or any other relationships that I need to provide also to my consumer. Now GraphQL is a little bit different. GraphQL was originally created by Facebook and it's really a query language, but you can also have what's called a GraphQL API. It limits response bloat. And now this is probably going way over some people's heads in this room. But let me be very clear about what this means. Rather than the server side, rather than the API, the web service, like JSON API or CoreRest, serving what's only available, the only thing that it can provide is a certain predefined list of content, a certain predefined list of responses, according to the request that come in. GraphQL, however, is allowing for the request to tailor that response. So imagine this, imagine that you go into a store and you're buying a cake and you want that cake to have certain things on it. Well, as a client, as a consumer, when I actually want that cake and I request that cake, I'm gonna get back whatever the store wants to give me because there are only certain parameters that I can change to get that cake, whether it's chocolate icing instead of the vanilla icing. With GraphQL, in my request, in my actual initial message to that server, to that GraphQL API, I can get back whatever I want to because it's a very flexible query language. Now let me show you what that looks like. GraphQL shifts responsibility from the server to the client. What this means is that instead of the server having limitations, the server publishes what's possible, not necessarily what the limitations are, but what's possible, and the client then publishes its requirements. If you wanna learn more about GraphQL, it's way beyond the scope of this session. There is a talk about it, I believe, sometime during DrupalCon. And what happens here is that, as you can see, I can provide a request that contains the title of the content I'm looking for and the author and their name. And instead of the server issuing just any old response that it knows that it can issue, it actually returns a structure that directly matches what I asked for. And that's a really, really compelling value proposition. That's a really compelling idea. So there's one last module I wanna talk about which is Relaxed Web Services. And one of the things that is really great about Relaxed is that it includes support for translations, for revisions, file attachments, and it's really great for things like content staging and content synchronization. It also includes things like the CouchDB API, sorry, it includes CouchDB integration, which means that you can have offline Drupal and content synchronization across an offline version of Drupal and once you get online, have content sync once you actually regain that connectivity. So I wanted to provide that overview of modules. I'd highly encourage all of you to check out all four of those examples, all four of those possibilities as you decide what web service is right for your decoupled Drupal architecture, what web service is correct for your consumers and what are they going to enjoy using? Now I wanna delve a little bit into decoupled Drupal and the developer experience. What makes decoupling Drupal so great for developers? What is it that consumers, that these front-end developers who are using Drupal solely as this back end, solely as that content service, what makes it so compelling for them to use decoupled Drupal? Well, I talked about this earlier, we've now covered the web services angle and we've talked about the ways in which you can really have a variety of different web services. Now what about the client side and what about on the Drupal side? If you are thinking about implementing decoupled Drupal or you already have recently, you've probably noticed that decoupling Drupal is really hard. There's not a lot of articles out there, there's not a lot of places, there's not a lot of resources that help you out with this stuff. So there's two things that have really been coming about in the last year in the Drupal ecosystem that really help to address that challenge, that really help to make that decoupled developer experience improve. The first is SDKs and starter kits. If you're a developer and you're writing a mobile application that consumes Drupal's content, you don't know exactly how to get that content out from Drupal, but an SDK does and maybe what you can do is use your own language and use your own approaches and use what you know about your existing technology to consume Drupal's content. Now these tend to be like wrappers of the client which allow you to make requests on the developer's behalf and process responses as well. That's what an SDK does. There's also starter kits and reference applications. If you wanna jump start, if you wanna have an application that's already a little bit built out so you can just use that as a jumping off point, you can have an out of the box experience for developers to really quickly get started and that's the real value proposition of these starter kits and references. So last year, my team worked on a new, sort of a new ecosystem of SDKs called Waterwheel and also a new set of reference applications called Waterwheel. Waterwheel is a set of SDKs that help to accelerate the development of these applications and we have a version in JavaScript and a version in Swift. Waterwheel.js and Waterwheel.swift. Waterwheel is meant to be a translator for these developers. If you're a developer and you know absolutely nothing about Drupal but all you know is that you have to get content out of Drupal somehow. What you can do is use Waterwheel to make your job easier and it helps people who don't know Drupal speak Drupal. Here's a big list of all the projects we've got in our ecosystem. We've got a Waterwheel module that helps with things like schema discovery. If you want to know more about that there's a lot of blog posts I've written about this. We've got Waterwheel.js, Waterwheel.swift. We also have several applications built in Ember and React which help you get started as well as in Ember CLI add-on. Now what about these API-first distributions? Well, if you want to get started with decoupling Drupal and you're a consumer, or sorry, if you're a front of developer and you have no idea how to use Drupal because Drupal's really confusing to anybody who's starting out with Drupal for the first time, as we know. You want to be able to help your developers use something that's really easy for them. So that's the real reason for these API-first distributions. And the most prominent ones are Reservoir and Contenta. Contenta was one of the sessions this morning. Reservoir is a project that was Aquia-sponsored and is actually, both of them are really quite powerful. And I highly encourage you to check both of them out because if you have developers on your team who are saying, well, I know Angular, I don't want to learn Drupal, Drupal's too hard, give me something that's a little bit easy to work with, Reservoir and Contenta could be the answer for you. So what does this ultimately mean? It means that a good developer experience, a good DX, means that it's easy to make APIs. It's easy to make these web services. And luckily, we have a very large ecosystem of them available in Drupal. It means that for these consumer applications, they have a way to communicate with Drupal in various ways. And by the way, you can combine a lot of these modules together and have multiple forms of web services. What else does it mean? It means that a good developer experience means that it's easy for consumers to work with those APIs, whether it's through SDKs or reference applications that are already built out. And that's a very important consideration, especially if you want to convince your front-end developers that they should be using Drupal. Finally, I want to talk a little bit about what this means for the editorial experience. What does this mean for somebody who's just a regular old user of Drupal? And for those of you in the audience who are thinking about this from a business standpoint and are making a decision about whether or not to decouple Drupal, this might be the most relevant section for you. Because we're really going to talk about what actually happens when you decouple Drupal and what actually is involved in the things that you lose and what actually is involved in the things that you will need to account for when you argue for or defend a decoupled Drupal architecture. So one of Drupal 8's core features is in-place editing. As we know, you can edit fields in their context, which means that if I want to update my title field, I can do that either in the Drupal user interface that's provided for editors, or I can use the direct in-place editing tool that's on the front-end of Drupal. The really nice thing is that if you're making a website or if you're making a responsive website, this is really easy, because both of those can leverage in-place editing. And as a matter of fact, you can use in-place editing on a mobile device. Also, if you're making applications, if you have front-ends that are being rendered by Drupal, that have Drupal as the renderer and Drupal is responsible for the visual control of that particular experience, like signage, for instance. There are a lot of examples of Drupal actually controlling digital signage. You can also use in-place editing by using this tool, by using in-place editing. However, let's say that you're working with a single-page application, or you're working with an Amazon Echo device, for instance. That's a really extreme example. But a native mobile application, for instance, you can't edit that content in the same way that you were used to before. You can't actually do any sort of in-place editing. You have to only use Drupal's administration layer. That's available in Drupal itself. Now, what about display and layout management? It's another big area that's very important. In terms of choosing layouts and managing displays of content, we can, by the way, I know that this is a very vast oversimplification of the actual layout management experience in Drupal. Panelizer is a lot more complex than this. But if you bear with me and think about this from the standpoint of, we can choose layouts, it'll be a lot easier. But if I choose a new layout, I can immediately see that reflected in what I'm doing on the front end. But what about display modes? What about things like teasers and full content displays? We know that in Drupal, you can limit a piece of content to just a small portion of text or make it have the entire full content. How does that change in a decoupled context? How does that change? If you think about building this kind of application that's up on the screen in JavaScript as opposed to in Drupal, you have to think about all of these issues in a very different way. And now, of course, one of the things that we hear all the time from our customers is what about previewing unpublished or draft content? Because I don't want this article about something happening next week to go out early. Well, currently, if you preview a single piece of content on a single Drupal site, it's trivial. It's really easy for editors. You don't need a developer. You don't need someone that you can tap the shoulder of and get them to actually help you with a technical standpoint. And soon we'll have, of course, content workspaces, which will be great thanks to the Workflows Initiative. But in a decoupled setting, right now, content can only be previewed directly on the device or through an emulator. And an emulator is really challenging, because it might result in lower fidelity. It might result in a worse preview experience for your editors. If an editor wants to have a high fidelity preview of content, let's say that you have a mobile application that's written for Android, and you want to be able to give that editor access to that unpublished content so they can see how that headline looks on their Samsung Galaxy Note. What you have to do as a developer is oftentimes, and this is usually the way that I've seen people do it, you spin up a new test environment. You push new content to that test environment. You have new data that's either published or accessible otherwise without authentication. You give the editor a URL or some kind of a new download for their application so that they can actually open up an application or go to that particular URL. And then finally, the editor can access that high fidelity preview. And so this is a very involved process. If you as an editor have to tap on the shoulder of a developer every time and say, I need a new environment, and the thing is you don't even know those words. It's a really big issue. So it's another thing to think about when you're decoupling Drupal. So decoupled Drupal means that we have to think about content in a much more structured way. We have to think about Drupal in a much more content, a channel agnostic way. We have to think about Drupal and content in a much more sort of flexible way, a versatile way, where we're not limited to the things that we experience on websites or the things that we experience on responsive websites. We have to think about content in a much more decontextualized way. Decoupled Drupal means that we may have to accept that on certain channels, on certain devices, that level of full visual control that we've come to expect on our websites is not actually possible. How do you edit layouts or manage a layout on a native mobile application? It's not possible. Decoupled Drupal means that many of the capabilities that we're used to may need to be exposed to consumers. So maybe you do wanna have in-place editing on your React application. Maybe you do wanna have some kind of layout management on your Angular application. This means that we have to be able to provide those means for any application to do that as well through those APIs, through those web services. So I wanna end here just briefly with a little bit of a meditation on what this means, what it is that Decoupled Drupal actually means, and what it really is gonna do for Drupal's future. Here's a big problem. Drupal has always been at this fulcrum of these three different ideas. We're gonna be really good for the user. We're gonna be really good for the marketer or the editor who has to edit content and manage layouts and do all the stuff that site builders do and editors do, and we also want to make sure that the developer is happy too. And we've achieved a very nice equilibrium, a very nice balance between these three personas. But at this point with Decoupled Drupal, is this balance something that we can achieve? For example, this is something, if there's one slide that you take away from this session, it's this one, which is that there's a new incongruity in Drupal. There's a new paradox in Drupal, which is that right now as a marketer, as an editor, as somebody who wants to manage something visually or edit something in place, I have access to websites and I have access to responsive websites. But if I want to do things like mess around with digital signage or augmented reality or a conversational interface like Amazon Echo, that's something that I need a developer for. It's not something that I can do by myself. I can't actually preview content on augmented reality. I can't actually take my Apple Watch and edit content on there. Not that anyone would want to actually do that. But you can see what I mean here is that what does it mean when all of these new channels and devices are appearing and editors want to have that same experience that they've come to expect from Drupal and editing a website or administering a website? Better for users increasingly means better on more devices. So for example, if you think about these two axes here, we've got what's great for developers and what's good for editors. So better for developers on the y-axis, better for editors on the x-axis. Drupal has always been at this really great kind of balanced position, which is that it's better for users if you have both of those things served, both of those use cases served, both of those personas served really well. But unfortunately, what's happening now is that a better outcome for end users who are experiencing your content on more and more devices relies on custom work by developers. More developers have to be involved in a lot of different technologies, in native mobile app technologies, in conversational technologies, in all sorts of things that Drupal simply cannot handle out of the box. So what does this mean? What it means is that we may have to be prepared to accept that the ideal future state of Drupal, the ideal way that Drupal will be in the future, might not be something close to what it is right now. We have to be prepared to accept that Drupal might actually be a bunch of different components, a bunch of different services, as opposed to a monolithic whole. But we can still call that Drupal. Fundamentally, that can still be considered Drupal, as long as we are able to provide that seamless experience that people have come to expect. So this is the great test that will dictate the next decade of Drupal. I believe very strongly that this is something that will really influence the way that we will help Drupal survive for the next 10 years. But I believe very strongly that a multifaceted Drupal, a Drupal that is made up of all these different exciting components and all these different ideas and these different approaches, is actually a more future-proof Drupal. By decoupling Drupal, by providing the ability to decouple Drupal, we've unleashed a lot of power. And thanks to decouple Drupal, this actually means that Drupal's story has only just begun. And we're embarking on an exciting journey together and I'm very excited to share that journey with you. Before I end here, I'd like to just point out a couple of sessions that are happening. These are a couple of sessions that I'm presenting. I'm gonna be talking about augmented reality and beacons on Drupal tomorrow, as well as decoupled site building, which is a little bit of that extension of what I've been talking about for the last five minutes. What it is that I mean by Drupal's next challenge. There's also a session about editorial interfaces and editorial experiences that my friend Matt Davis is presenting on Thursday as well. Please join us for the sprints on Friday, of course. And please do provide some feedback on this session and take the DrupalCon survey. And with that, thank you very much, and I'll take questions. Thank you. We've got a microphone up here. If people wanna ask questions, please don't be shy. I know it's after lunch, people are low energy, but. And please do give your feedback on this session. I do hope it was useful. I do hope that it had a lot of interesting information. Yes. Would the slide deck be available somewhere? Yes, I will be providing the slide deck this evening, and it will be available and I'll provide a tweet with the slides. Wow, was this really that? Okay, so you know everything about decoupled Drupal now. Was it really that helpful? Was it really that informative? All right, all right, cool. Thank you. Alrighty, well, we've got seven minutes left. If you wanna ask me some questions, I'll go ahead and shut things down and you can meet me on the side. Alrighty, thank you.