 We're going to get started now. This is the mic, right? Great, thanks. All right, so welcome to DeCoupled from the inside out. I'm Sally Young. I'm an architect at Lollabot. I used to do Drupal development full-time, and now I split my time between waving my arms around, telling people how to construct their CMSs and content models, and writing JavaScript applications. How do I touch this area? I'm Matt Krill. I'm a senior JavaScript engineer at AQUIS-Octo, EmojiName Pipster, and Breaker of Troubledore Comment Fields by putting emoji in them and watching them break. And my name is Preston So, and my bio is way too long. OK. So what we're going to cover in this session is what other CMSs are currently up to with their API offerings, both proprietary ones and open source. We're going to talk about some of the difficulties that we've had implementing DeCoupled architectures, some thoughts we've had about what might make this easier in the future, and then we're going to open it up to all of you. So first, we're going to look at what other open source CMSs are doing. The most popular, or most famous, OK, the most famous implementation of this is you might have heard of is Calypso, which WordPress launched. So you can manage your WordPress.com blogs with a React application. It's really fast. You can organize multiple sites as you do it. But the thing to bear in mind with this is we can actually build this right now with what we have. So the content model that's available on WordPress.com is pretty simple. It's a blog. We're trying to achieve a lot more with Drupal, with multilingual and other cool things like workflows. So we can do this right now if we want to. There's a few other ones that are pretty popular. A new one that's come out in the last year or so is called Keystone.js. It has a field API. It's very similar to Drupal. It's a node module. So you can actually require it in your application as if it were just any other kind of packages that you would bring in. However, it doesn't mean it's quite manual to set up. So if you go to their Getting Started page, like copy and paste all this code and create all these directories and everything. So that is tougher to get started with than Drupal, but it does allow quite a lot more flexibility. The other nice thing they do is, based on their field API, they can auto-generate React components to create your admin forms with. Unfortunately, they don't have any kind of relational database. And I've not tried it in production, so I don't know how well that would go for managing really large interconnected size of content. And then the other one we looked at is Django CMS. That's another popular option that has a field API type interface. They don't have a REST API as part of their core offering. It's an initiative that's being worked on only by a couple of people, unfortunately. But what they have done is said in their roadmap, they want to add headless managed mode to Django CMS, which means that any kind of configurations or anything you do with the CMS, they want to be able to do it in a decoupled architecture. So you could have a React application instead of any kind of theme layer that would then manage your CMS for you. And I think Preston is gonna tell us about proprietary CMSs now. Yes, so as we know, open source CMSs have really taken on this API-first model, but really over the last couple of years there's been some new competitors that have come into the market. How many people have heard of Contentful or Prismic or some of these other big players in the market? So these proprietary solutions are very unique, actually not very unique, in that they are all paid platforms, which means that you have to pay to use their software. None of their backend APIs or API provisioning is actually in any way free and open source unlike Drupal. And one of the things I like to say about Drupal is that we are API-first and end-to-end open source, which means that you don't have to pay any money. But as you can see, these logos are very colorful, but what exactly can they do? What are their capabilities? Well, here's an overview, right? First of all, Drupal 8 right now has some right capabilities. It has great weed capabilities. We have great APIs that you can use, various solutions that you have. We also have a couple of SDKs that are out there like Waterwheel and some other approaches that people have taken. But we don't really have anything like preview support when you need to do things like staging some certain content changes when you're doing that on your application. And at the same time, our coverage in terms of SDKs is very poor. Now just to introduce very quickly what these proprietary CMSs are. Contentful, you probably know very well, it's the headless CMS that everyone's raving about that you've probably heard a million times and you're sick of hearing so much that you just want to tear your hair out like I do. And then there's Prismic, which is really focused on the editorial experience. They really want to make marketers' jobs easier. How? I don't really know. But there are ways that they've been doing some really cool stuff like injecting edit buttons into their front ends and so on and so forth. Built.io is a mobile backend as a service that's converted some of their work into an actual content as a service solution. Cloud CMS is an interesting startup as well that focuses more on MongoDB based approaches. And then Kenneco Cloud is actually a very interesting one because Kenneco is actually probably the most similar to Drupal in that they are an ASP.net CMS that has since transitioned into being a content as a service platform. Now, as you can see, we actually are doing pretty well against these guys. We have all of these features and by the way, I'm not gonna go through each in every block of this. You can look at this, we'll have the slides, we'll have them available for you to take a look at later. But as you can see, we're actually doing quite well because Prismic doesn't have any right support. I don't know why, but neither does Kenneco Cloud. So pretty good in terms of the largest headless CMS competitors that are out there. But what about things like administrative capabilities? Things like being able to do user permissions manipulation through the API or doing things like content modeling through the API or even doing things like making an API through the API. These things are not really possible in Drupal right now. Also, one of the things that really distinguishes these headless CMS platforms is they have a whole lot of SDKs and a whole lot of reference applications and a lot of boilerplates and starter kits that you can use to actually build applications really quickly and not need to learn things like the really severe, kind of small niceties and nuances of these particular platforms. And we're really behind in this regard in that as you can see, there's a lot of different SDKs available for these platforms and that is the most compelling open source offerings that they do have. And it's really actually the only open source offering that these headless CMS platforms provide. So as you can see, there's a whole lot of technologies and really Drupal doesn't have many offerings in this regard. So the challenge for all of us is to figure out a way to make all of these boxes green by the end of today. Also, one of the things that's interesting about headless CMS is because they are platforms, because they are past solutions, they offer preview environments or also separate endpoints for preview that you can actually query to get a new piece, so a new look at your content, right? So if you have unpublished or embargoed content or draft content and you wanna be able to preview that in your application that you're building, you can either use a separate API or you can actually use a preview environment, things of that nature. And I know that Sally's gonna talk more about preview. So speaking of preview. Yeah, so in talking to a few people about this presentation during the week, they weren't necessarily sold on having fully decoupled architectures, so I just wanted to throw something in last minute, which was the decoupled preview system we built for lullabot.com, which actually was built on Drupal 7. So we've been able to do stuff like this for a while and it's a live demo, so I'm really hoping it works, or it's gonna be super embarrassing. Yeah. Okay, so... So because we're using an API, we can start doing cool things like this, where actually everything we put in can start getting immediately previewed in the front-end app in exactly the way that it's gonna appear. And images work and everything works. I don't wanna focus too much on how exactly we built this because it would be derailing it slightly if you wanna come and talk to me about it later. Please do. Yeah, so if this doesn't sell you on a decoupled architecture, I'm not sure how else I can, but yeah, that's the kind of things we can achieve and it would be nice if we could start to achieve these things out of the box with Drupal 8. Yeah, so Matt's gonna talk to you about what's difficult with actually building these kind of architectures. By the way, that preview is really awesome. I think you kind of undersold what's happening there, so. Oh, what's different and what's difficult. So if you're gonna build a decoupled time right now, there are some touch points to be aware of things that are challenging. Authentication without the use of additional modules, Drupal Core REST has some weird levels of authentication like cookie or basic auth, neither of them. Those are great. You can use simple auth and use OAuth tokens which have some of their own drawbacks. The built-in Core REST API references just like a single document at one time. There's no list support and if you want to fetch like additional resources that are includes, those require another request to fetch. They can't be returned back at the same time. Documentation, this is something we can all work on. I think that documenting how the REST API works and the advancements that we've made to make it much better, we should like write those guys down, so that's great. Tooling and SDKs, I think like Preston mentioned in the beginning, those boxes are all no, please finish that all right now. But yeah, I mean, I think we need some help on looking at the technologies that our people are using in other sort of realms and sort of like give people an example of how to integrate with Troubles REST API. API documentation, there's a couple of modules out there that provide this, but right now there's no sort of API discovery resource. We don't know, you don't even know what you have enabled unless you just go through and look at your YAML configuration and Swagger is a way to do that. That's something that you can generate. This is a module that does that and there's one Mateo with the name of the one that does. Doxen for JSON API and that's great if you're using JSON API. And routing is a problem that Sally's gonna talk about. Very accurate. I'll keep it brief, but traditionally when we've built sites the way we build them with Drupal, we leave routing over, oh my goodness, I just said it with the UF pronunciation. We leave routing over to, we leave routing over to Drupal to handle, whereas if you might have done a hello world with React or any other kind of front end framework, like typically one of the first things you'll do is you define all the routes in your front end application so you'd be like article slash whatever. And so reconciling those two things can be pretty tricky. There's a route where you can have Drupal manage everything to do with your URLs, in which case we have to have this extra service going on to manage what happens. So we can query Drupal and say what's at this URL, but what happens if we need to redirect things or change stuff around, it gets really tricky, or we can have our front end application do things, but then if I create an article on the back end, does it take anything from the title or are we just using node IDs and everything? There's not one answer to that. It's gonna be completely different for every project you work on, but it would be really nice to have some repeatable patterns that we could use for solving those problems. Yeah, so moving on slightly from that is the idea of internally decoupling Drupal. One of the things that will be nice, perhaps when we build these decoupled sites is we don't necessarily need the theme layer anymore. We could potentially build a single page application that will allow us to manage Drupal in any way and then we don't have to pin ourselves to any kind of JavaScript framework or whatnot. How we achieve that, I'm not entirely sure. We'll open it up to you shortly. One idea I think I've read about a couple of times is having Drupal in slightly smaller packages. So you could build your own symphony application that pulls in the entity API, the field UI, and users or whatever and have your JSON API on top and then not bother pulling in the other things. And also, this means that we don't necessarily have to write parts of Drupal in PHP anymore if we ever get that far. And yeah, over to you. Yeah. Great. So yeah, some questions that we'd like to pose is this a good idea? How should we handle this as a community? Is there opportunity here? Are we too stuck in the past? Is this a possibility? Should we internally decouple? Have everything be like a user service, be like everything else like that, or have an entity service even potentially? Anyways, please, Daniel. Hi, Daniel, my name. One thing I'm wondering, how can we dog food the stuff? So should we dog food our stuff? Dog food is the concept of actually using the thing we built. So should we have something in Drupal which relies on Drupal? Do we have any ideas? What could we dog food? So at least, yeah. I think one area where we could begin to see where the APIs could really use some work is in efforts like outside in or some of these things where we're doing a lot of dynamic client side rendering that need to be able to, let's say, save a piece of content out to the API, in a right to the API. Optimistic feedback. Once you make that change in that form that's in the settings tray, how do you know what changed without having to refresh the entire page? That's super wasteful to do that entire page load again when you just wanna update the title. So I think we should do something like that or make that doable. But then the question becomes, and I'm already seeing Eric reacting to this next statement, but the question is, how do we systematize all of these optimistic feedback requests and responses that come back? Do we use things like our existing AJAX framework? Or do we use things like jQuery or Backbone? Or do we move on to potentially some technologies that are more commonly used these days in the JavaScript community? Okay. Why are you just getting back to the line? I have another idea. I mean, you talked about JS, which is cool, but could we decouple in PHP? So that would require, we move a lot of discussion about whether we should decouple with JS. Yeah, so we talked about this in, no, Dublin. And there is an issue open in the ideas queue on Drupal.org that one of the things we could do is actually build a symphony app that would consume RAPI, and that would become our admin interface because we're all really great at PHP, but we're not necessarily all really great at JavaScript, so that might be a really good starting point. And then from there, we know we can build these applications and Matt can go off and build something in React and I can build it in something else or whatever you want to do. Yeah, to an extent, I think it's about methodology. Technology is just kind of a symptom, right? We do what makes sense. Hi, I'm Eric. You don't know me. So we've been hearing from Dries for numerous years now in keynotes about decoupling, but there's always that one caveat, except you lose all the great things that are in core. Why can't we start now, whether in contrib or in experimental modules, which seem like a good segue into getting this done, but include API first as part of core functional development? Because then we can have less discussions and start doing more actions and proof of concepts in developing these decoupled systems in either JS or any API consuming technology. I know it's a giant can of worms, but we got to start somewhere. Yeah, it's really hard, because it's almost like you want to set a mandate that this is what we're going to achieve to do together and we all need to work on every part of core in order to do that, not just necessarily in an experimental module. So yeah, it's really great. He's saying let's do this, but I think it's going to require quite a shift in all our roadmaps and goals. Well, I think part of the reason for the inertia, and I'm going to let Matt, part of the reason for the inertia, I think is just what I would call this kind of suspension of like, there is just information overload going on in terms of what to use, right? And I think a lot of people are hesitant to do this because if I use a particular technology like Elm, for instance, hi, I'm a tie. If I use Elm, for instance, and go down that path, what is to say that that's going to become the canonical approach, right? And so I've invested all of this time into a technology that I love, and the thing is it's going to have to be something where it's like basically a bunch of people fighting each other until something wins out. And so the worry that I have is, I feel like the part of the reason why no one's really done this yet or has not really seen this kind of approach take hold in the contrib ecosystem is because people are having this kind of fragmented overload of like, there is just so much that I can choose from, and I just don't know what to do, so. And Matt, go ahead. Hey, Ted. Hey. I know that when we started working on Settings Tray, we thought about making Settings Tray work over the API, and there were some drawbacks at the time, and I see Wim back there, and he can probably answer exactly why we couldn't use the API when we designed it to do this. I'm just like bringing in other people to answer my questions for me, but like. Great job, Matt. The reason that we can't do that yet is the same reason that lots of the check boxes in the diagram, the table that Preston was showing is our red, our not checked. The reason is simply that we don't have validation for configuration, and therefore. And we don't have a way to expose the validation yet. Yeah, well, there is only validation for configuration in the specific forms to configure things. So all the validation logic is tied to the form. Therefore, you have to continue using forms if you want to use existing validation, which means you can't use API first for configuration just yet, because we need to do all the work to have all the configuration and have validation logic and then these things become possible. So, anybody who wants to help out with that. Sit with Wim on Friday. Yeah. Is there like an issue tag that people can? There's an issue for, and I, it's, was it RGPC or done for validation, for being able to validate in configuration entities? Come on, Ted, what's the issue number? You just gotta have it in the top of your head. So, I was gonna sort of make Wim's point about the idea that the other thing that we hit is also the, even if we could, we hit two problem settings trade, even if we could have used the rest to update the blocks, then also we would have needed some way to make the form. We would have still been using the form API to make our forms, and especially because we wanted to have block plugins, be able to have their own forms, not just the ones we knew about. Then we either had to have a way to have JavaScript make forms, expose that somehow, so that like, basically rebuild the form API in JavaScript. So, I'm saying, if we had wanted to totally decouple that. And that's the thing that we should do. I'm just saying, it's the thing we should do. I wouldn't say that, but yeah. Whatever. If that validation, if the entity, if the config, say if we were doing settings trade right now and config validation was almost done, which is potentially almost done, but all now, all the block validate, all of the config validation is still in the form. Even if we had the ability, we'd still have to migrate everything out of there, out of the forms and into the entities themselves. We could have potentially done that just for blocks. So, you set up the system for config entities to be able to validate. Then all you really need it for is block. So, you move them one by one in core as you want to dog food it. So, but it's just bad timing. Cool, thank you. It just occurred to me as well. From the evaluations I did of open source CMS as we are just kicking everyone's butt when it comes to APIs. So, I hope you don't feel like we're being like sucks. Yes, and thank you to the entire initiative team, API first initiative team who are, many of whom are in this room. I've sort of been around this topic for a while. Hi, my name's Jason. Sorry, it's David. Preston. Yeah, I couldn't say Preston because he's up there. Actually, I'm the other Preston. I've been around this topic sort of like through the back and all the way around again. And for me, it personally feels a bit like a snake eating its tail, except I'm inside the snake. So, I never escape it. There's, you know, Sally's illustration of that awesome sort of glorious end state, right? Where you have these live previews fed through APIs, incorporating these technologies in a very flexible way from Drupal is very compelling. And I think it's sort of everybody's dream that we get somewhere like that. And a long time ago, I used to think, you know, the way that gets us there, that forces all these changes is if we pave the cow paths, like at the discussion earlier about backwards compatibility that Ed Faulkner mentioned, right? Let's put it to the test, let's eat our own dog food, let's build a decoupled admin app and let's see where the soft parts are, right? But that, you know, if we had done that three years ago when we first started talking about this, let's say, and we rolled the dice and said, Angular's the way to go, right? And we built it on Angular 1. I mean, Matt Davis would probably laugh us out of the room for having an Angular 1 app in our admin because like Angular 9 is out tomorrow or something like that, right? And so I think there is something to be said about the ecosystem itself being so fragmented that we are at risk when we try to place bets, but nothing less than a heavily placed bet will get us to where we need to be. And, you know, by not doing anything, we've kind of come out slightly ahead, but then of course we've also lost a lot of this momentum in these other technologies that we've sort of said, eh, you know, we're not gonna play in that sandbox anymore. But I wonder what the next definitive step can be when it means we have to place a really risky, huge bet on a technology ecosystem that's going to move forward without warning us. And if we bet wrong, we're gonna look like bigger idiots than had we not bet at all. So I think this really comes down to something that I remember that Daniel Vayner said last year when we had the much more war-like combative version of this. And the, you know, it's like, you know, what is it that we want Drupal to be, right? Because we have always said, and this is the really one of the boons of having PHP end-to-end and having this very tightly coupled system, which is that editors can do stuff like in-place editing, get their contextual links, right? Do that kind of stuff. And we've always said that, you know, Drupal is, yes, Drupal is about developers, developers, developers, developers, but it's also about marketers, marketers, marketers, marketers, right? And so the question is, if we go in the direction of not being, of being totally agnostic, right? Which is totally fine. I'm not saying it's a bad thing, it's totally fine. Then what do we say to all of these editors who are expecting a canonical front and who are expecting a canonical editorial experience that includes stuff like in-place editing, that includes stuff like preview? And it's really a question for the group, because I don't have an answer. I thought I had an answer, I don't have an answer, right? Because the thing is, yes, it's exactly as David said, we can place a bet and we can say that we're gonna, you know, serve both beasts as we have this whole time. But, you know, it's a big issue. And I think that either we're gonna have to admit defeat and say, okay, marketers, I'm sorry, but you're gonna have to choose one of these 15,000 front ends that we now have available. Or, you know, we're gonna have to leave you behind. Okay, talking from the belly of the snake again. I had a conversation once very early on when we had very early decoupled decisions to make or not make at the time. Well, with somebody I respected who's not in this room, so I hope she doesn't mind me saying these things. Sorry, apologies, I'll apologize over dinner next time. And she sort of, you know, after a couple drinks, you know, after we talked about what it would take to do these kinds of things, mentioned the F word. And that's what it would ultimately take to do this. That it's so fundamentally far afield from quote unquote, Drupal as a product that no amount of pushing or force is going to get that round peg in that square hole. And that you would, at the end of the day, by placing these bets or otherwise, tearing out things, make a product decision that makes it a completely different product but has the same genealogy as the thing that came before it. And I've really walked this back and forth in my head for a really long time, but I think she was right. I think this will probably end up forking the project if you need to go a certain way. And that you have Drupal and, you know, Drupal Ultra 64 or something like that, right? That only works with front end JavaScript frameworks and they may be composed of similar elements but they're two entirely different products serving two different audiences. So I think the idea of composing Drupal down into smaller parts internally would help with this. So if you wanted to build your API first application in Symphony, for example, you would pull in entity API, whatever you wanted to use, and have that as a slightly more manual process which is really similar to how Keystone.js works. At that point, Drupal becomes a set of those things that we provide plus extra stuff like layouts and other things like that. So I think it is possible for them to coexist. I think it's possible and like it's, you know, statistically, there's a non-zero number that statistically happens, but I think the main thrust of Drupal product direction has been to grow the monolith, right? I mean, not to coddle myself, but I think that's what Dries said at the keynote when I asked him like, hey, Drupal's getting bigger, not smaller, right? Like the actual scope of Drupal as a product grows over time and the expectations of what Drupal does increase and thus going that opposite direction is not just swimming upstream. It's, you know, it seems impossible at this point. And I mean, my response to that is in my experience, we just don't build sites the way we theme sites anymore. Yeah. Hi, I'm Mateo. I think I forgot what I was gonna say. Sorry. Are you that famous guy from the keynote? Thank you, Sally. No, I actually had a couple of thoughts about all the things that were said. I do think that we have more green boxes than those that were shown. We don't have them in core, but there are contrib solutions that reach to those points. So that's one. I think that it's okay if we don't have config entity validation in order to write config entities, just like you can do it in executing PHP, nothing kind of prevented us from creating content entities when in triple seven, the validation only happened in forms, right? So I don't see why this would be different if we respect all the permissions that creating a content entity would require. So you could create permissions from a decoupled app. If we kind of lifted that restriction in core or used some of the contrib solutions that don't require that. Also, I think that we could solve fairly easily the problem of self-generating, looking for that, self-generating forms in a decoupled architecture by exposing the configuration entity schemas and reading from that, which is kind of recoupling again, because we are, you know, having the front end aware of the backend configuration, but we are doing lightly coupled designs, which is better than highly coupled designs, in my opinion. And lastly, I think the form API is fine as it is. We need to have it in JS..(audience laughing and applauding.) Hi, Steve Perche, agency and community engineer at Pantheon. Hearing the suggestion of what if we had a symphony application that allowed us to administer our Drupal site, that reminded me that I think most of the developers in the room already do have a symphony application that they can use to interact with their Drupal site. Drupal console is a symphony application. It's a command line application. It doesn't render in the browser, but it is a symphony application that we already have. It's pretty mature already. It's very robust. It can't do everything. It can't do everything that we can do in the browser. If you try and make a symphony console command to do those form heavy interactions, you're gonna have a difficult time because you'll run into all those problems that we're running into on the JavaScript side. How do we recreate the form API in JavaScript? I don't know, I think we'd have a much easier time abstracting the form API in such a way that we could reuse any Drupal form using symphony console interaction. That, to me, sounds much, much easier, something that we can all agree on much more easily than React versus Angular versus every other JavaScript framework. We've already got it. We might as well make Drupal console as good as it can be. Thank you. When have we ever done the easy thing? So two quick thoughts. First, dog fooding. I think this has been raised on most of these prior discussions but I wanna raise it here again. Quick edits, in-place editing. That's the one thing that we have in Drupal Core that could be rewritten to use the rest API that we have instead of the deep intertwining craziness that we currently have to make it work which is using the form API under the hidden forms is how in-place editing works, by the way, if you didn't know yet. It's kind of scary. The rest API would make it a whole lot more reliable and testable and so on. But of course it means spending time on something that is already working for no visible benefit at all and that's kind of the question there. Do we wanna do that? But we do get the benefit that we exercise the rest API at least in some feature. So that's the first thing and then the second thing is more kind of a general observation. I think part of the appeal of decoupling is to reduce complexity or at least perceive complexity. The desire to have simpler code, easier to debug, use more modern tools, pick and choose what you want. But then we lose the deep integration. Like for example, in-place editing, block placement and so on, all of those things. But the reason that things are complex and part of the cost of integrating, the cost of checking that all the things together work well, integrate well, because for example, for in-place editing and contextual links and all of those things to work, you need to inject some sort of HTML in just the right place, need to be able to extend existing templates and so on. So somehow we need a module to be able to extend markup that is rendered and these things need to be aware of each other and support each other and so on. And so in theory we can do the same completely decoupled version of Drupal but then we still need to pay that cost of integrating all those things which means that we lose some simplicity and require some complexity to achieve the same. I think that's often forgotten about it and that's part of the reason that we have the complex system we have because it is so rich in how you can interact with it on the front end and how all the things actually work together in a meaningful way and we will need to rebuild that in whatever system we then end up having. So let's not forget about the integration cost basically. I'm curious how many people have done client projects that actually end up using things like inline editing. Yeah. We, I mean I personally have never used it. Just one hand. I'm not recording just one hand. Um. It. Halfway with. Yeah, half way with. Yeah, so we don't use, hi my name is Lauri. So we don't use quick edit for that definitely. So we use a fully decoupled application which implements inline editing on the decoupled application on based on Drupal. Okay, okay. So actually that brings it down to zero hands then. That doesn't count, that doesn't count. Yeah. I personally for client projects have not found anything like that useful and I would consider not having that as a feature of Drupal if we decide to do this. Yeah, tough discussions. So regarding the comment of Wim. So he said that if we rewrite everything it would cost a lot of like time and everything. I think we have to do that anyway at some point given the state of how the rendering theme system works. So maybe it would be actually better to like not try to like we do the same thing but in a different way but rather like we think it from scratch which maybe means do it in JS only. Maybe like on the long one it costs, it takes actually time. The other thing is that I think we should expose other APIs by default. Unlike what we currently do is we, like if you install WES module, yeah, nice. Nothing happens. Like you don't get any data out or if you first have to configure like that you want to expose the node resources. So I think we should expose everything by default just to enforce ourself that we are actually doing the right things and this enables like quick edit and settings way and those things to actually work cause currently they couldn't work because the stuff is not there. Yeah, I agree with that. I think that the minimal configuration model that Matteo has undertaken in the JSON API module is exactly the kind of path that core REST should go down. That's what I wanted to add. That's exactly what the JSON API module does precisely for that reason because it enforces that you have access control for all the things set up correctly and so on and remove so much a setup burden. Yeah, the other thing I think with configuration, like it seems there's more energy into talking about configuration then. Like there's more energy involved into talking about the nonexistence rather than solving the problem. But yeah, that's just my point. You may have to actually do some work. Yeah, and the third point, what was it? Oh yeah, so I was wondering whether we could build the default theme in a decoupled approach. So there was another coin initiative about building a default theme and the default configuration, so like a magazine I think it is now. And I think we could try to rebuild the same thing in a decoupled approach just to prove that we can actually build it. Yeah. Hi, Peter Willanen. Just wanted to encourage people maybe to watch the recording of our core conversation earlier where we, even though the title was about removing models from core, what we actually came to the conclusion of was kind of what Sally said was we need a much more composable approach so that you can bring in really just core and maybe there's a distribution that's the default distribution that gets you all the pretty things or even like Daniel just mentioned this new sample theme and that, do I want that for most sites? Probably not. I would really rather have a way to exclude most of the core themes and several of the core modules when I build a site. And if we could get there, maybe we could have a bit of the best of both worlds as you see us. So I have one small comment with regard to what, hi, my name is Jess. I have one small comment with regard to what Sally said, which I just forgot and it's going to be in a second. Oh, about you asked the question, how many people have actually ever used inline editing in the client side and people raised their hands and then, sorry, a person raised their hand and then it became clear that it wasn't actually a quick edit. I just wanted to point out that the word decoupled is in the title of the session and so there is probably some self-selection bias in the content of this room in that regard. So let's please not use that as a, I mean it could actually be that it's also not relevant. But I don't, I'm sorry, I don't know one way or the other but I just want to point out let's not use this as definitive. We all fall into the confirmation bias. Yes. But then the question that I have and I apologize if I say something stupid because I feel very much like an imposter in this room. Cause didn't mean to make you, okay, no, you were drinking water. So the thing that terrifies me about decoupled front ends is technical debt. Surprise that I'd be worried about that. For the recording I'm a Drupalacore release manager so. But and also specifically related to security issues and sanitization and Mateo was saying something about permissions where my heart just started going like this. I'm very scary and about related like config validation. All of these, all of these problems that we've solved and I remember I think it's okay to say this because it was before Drupalacore was released there was a cross-site shifting vulnerability in QuickEdit that we found very late in the game I think only because of the bug bounty that was really like a really bad cross-site scripting bug in QuickEdit. And so I guess my question is like how, what are your thoughts about this question that I propose since I don't know what I'm talking about and I might be. You do know what you're talking about, okay silly. Yeah, we're not the only people who have solved this these problems. The JavaScript community is huge. NPM has, I don't know how many modules, like eight billion or something. So we can start to use and leverage other people's solutions for stuff like that, which also I think wouldn't be a bad thing to take some of the burden of maintaining those off of our plate. Yeah, I mean I think just, you know what Sally said, there's a lot of, I mean I definitely agree that like technical debt is gonna be huge. As soon as you construct a re-implementation of stuff we've already done a bunch of time in a whole nother language you're gonna add a whole bunch of issues there. I think there's a lot of room for us to leverage work that's been done in the JavaScript space already and I think taking advantage of that is gonna be like helpful for us to spend time composing interfaces and less of that sort of like writing all these like custom fiddly pieces. Let's just not use left path and everything's gonna be fine. My comment was on the dog-fooding part and as I understand it correctly we want to dog-food so we can put our API generation tools under usage and under stress and discover bugs and see where we want to go. This may be more of a community comment but we have the challenge of having people that are very core oriented and very a triple development oriented and people that are very working for clients, industry oriented and if we can find the balance of having mixed teams of people that can devote their time to improve this in Drupal.org but also see this used in real clients we may get away without the dog-fooding because we will see those APIs get to use. I don't have the remote idea on how to do that. On the API first team we try to do that we put the more core oriented position I am more in contact with the industry but still we are clearly falling short so maybe someone that is doing client code that is using this can find the time I don't know how to solve this but I'm just saying that this could be an alternative to dog-fooding. Yes. Hey Chris. Still thinking? I guess the thing that I really find appealing about a decoupled approach is it becomes completely data centric which is what kind of originally drew me to the philosophy of Drupal to begin with it being very data centered and I think what we're finding as we're creating decoupled applications is that we just don't have all the data yet and in this sense configuration becomes data, validation becomes data so it may be important to keep in mind as we're running into these roadblocks that this is just something else that needs to be exposed in a way that can be used and once you have all the data you can do everything on the front end that you can do on the back end. Yep, yeah, that's exactly it. Hi I'm Costa, I work for Salas Labs. Preston I know you said you didn't want to hear about Contentful anymore but everyone can boo but I signed up for it yesterday to just see what it's about and downloaded the JavaScript SDK and had something working in five minutes, like a simple React app, actually a complicated React app that shows you a gallery or whatever so it seems like the fully decoupled approach to Drupal which I support requires a lot of work, a lot of re-plumbing of things but there's a ton we can do with Drupal as it is now so it's an intermediate step just to second what was pointed out earlier, an example install profile that uses either JSON API or GraphQL and that has a limited set of configuration and here's an example React app or here's an example Angular app but I know people have done this on their own but if you say like here's kind of like the Drupal official Drupal thing that people can look at that definitely like gives people a lot more confidence like okay I'm gonna build this thing in a certain way. Yes, yes, yes, a million times, yes. I think some people in this room might have been working on that already. GraphQL maintainer, the Poobie has created a demo site for that already so there's a decoupled, kind of a site installation which has a client-side application and a backend application and it's like kind of doing some minor things over there. It's a good place to start for anyone who hasn't been doing something like that. Hi, I'm Jesper, just lost my motor because I was gonna talk about having a profile in Drupal 8 that allows you to run in restless, headless and just go from there. That would be an awesome approach. I had a personal project recently where I was trying to figure out how to do this and getting Drupal up and running was easy, getting JavaScript up and running was easy. Coupling that together was really, really, really hard and that was ridiculously annoying for me to fiddle around with all these modules, trying to figure out which one would suit my needs the best. And my other thought was. What else? For the recording, here comes Mateo running. No, just to point out, there's an API first discussion tomorrow and this is the exact thing that we want to hear, like all the frustrations and everything. That's great. What time and where? Great. I think 10, I believe it's 10.45 to 11.45? Tomorrow after the keynote in this room. In this very room. This is, wow, auspicious. This is where it's at. But yes, I mean, yes, we're having spoken to you before about this. I mean, I think that what we really do need is a codified set of best practices alongside some kind of a distribution that install profile. Whatever it is that gets you going quickly and you don't even need to know PHP or Drupal to use it. Someone should be able to come in and say, I don't know Drupal. I don't know what the hell a node is. I don't know what any of this stuff is and bam, they have a working decoupled architecture. How much make this? So great. My other thought was that I really, really like the new theme layer. We've been working with it for over a year now. I love it. But why are we always talking about rebuilding an admin theme in a JavaScript application? Couldn't we go like halfway and then take all of these things that we now have running in Backbone and jQuery and maybe build some of them in a JavaScript framework that we select. I know other frameworks are selecting now. They're making their bets. So couldn't we go halfway? Right, because you mentioned earlier that Laravel. The Laravel community is now working with Vue. Vue, JS. So someone has put a place in their bets. So is it such a bad thing? How many people here have used Backbone in Drupal? Whatever exists in there. One, two, three, four, and ten, ten hands? Okay. Not a lot of pleasure. Not a lot. Yeah, so you're maybe talking about like a partially decoupled admin interface. Like rebuild some components in the admin interface that use some sort of JavaScript framework and the API to manage the interactions. That will also allow us to make examples, easy examples of how what you go about integrating with a decoupled Drupal. Look at this thing, we build it. It's doing in-light editing. It's already in Drupal. It comes with it. Yeah, I think that's great. I think it's totally a way to dark-fit our own API and warm people up to the idea of maybe we can keep doing more of this as we go. So I think that's an awesome idea. Thanks. Hey, thanks for hosting this conversation. I'm Matt Davis, and I just wanted to say like, I think there's a sense in this room that not just that this is a direction that we need to head in, whatever the details of it are, but that there's also a lot of urgency behind it. And I think a lot of what many of us are wondering about is how do we get past the talking about it stage to actually doing something and proof of concepting some of these things. And I just wanted to mention an idea that came out of a meeting Preston and I had earlier today of actually considering having like a separate event, like a decoupled summit where those of us who are really interested in pushing this forward get together and make it happen. Yes, and we may potentially have actually a big corporate sponsor of such an event. So we will keep you posted. De-coupled con. I've also used Contentful. It's all right, but I do like what Drupal has to offer to you. Who are you? Better. My name's Luke. I'm an engineer at Four Kitchens. That's just some commentary. I like what Drupal does better. But I have a word of encouragement because man, this is like a really hard thing to solve. So I did a training on Monday, essentially teaching JSON API modules, simple OAuth, building a small React application. The students in the training were blown away that this was possible with Drupal. So can we have a hand for core and for contrib? It's like awesome. I just was like, I went over the Drupal section of the training, which was 15 minutes long. And their eyes were like lighting up like, what, you just, you can do this out of the, you just enable a module and it works. It's really, really cool. Second thing is a question possibly comes from just a lack of understanding. So is it possible that we could kind of take like a progressive enhancement, not in the typical definition of the word, kind of approach with modules? So saying like, well, if you want to install this module, it has a dependency on this library and the kind of like using that as a form of possibly getting more kinds of experimental things in. So are you exist?