 So I am Sean Ryu, I'm a senior architect and front-end developer at therefor. Therefor is a digital agency based in Toronto and we specialize in building enterprise communication systems using open-source web technologies, so Drupal, and of course a whole bunch of other things. Okay, so what I do, so generally speaking I work with clients to establish strong information architecture and content strategy for their CMS projects. So information architecture, Drupal, we look at planning content types, planning the site architecture in general. I also work with front-end technologies to build accessible websites and web applications. So whether that's using Drupal or using other technologies like Angular. And I also engage with clients through a process of discovery to determine the best content strategy for their business and user needs. So that's working with designers and other developers and the client to figure out the best content strategy and digital strategy for their needs. Okay, so what I'll be talking about today is decoupled Drupal. I'm gonna go through a quick primer on it just in case you're not familiar with the idea, although I'm sure a lot of you are. Actually, does anybody, does everyone in the room know what decoupled Drupal is, basically? I'll give a primer, this is a primer. I just wanted to see familiarity's sake. Okay, so generally Drupal's sold as a standalone solution. So this is one-size-fits-all website, front-end, data store, content management interface. This is very familiar to clients. We have stuff like WordPress that also serves the same purpose. So our presentation layer and our content management is all just one pile. So in Drupal 8, we've got some new sexiness coming. We have RESTful web services, which maybe doesn't sound sexy, but it is. We have HTTP basic authentication and serialization, modules built in the core of Drupal 8. So what this means is out of the box, we can build an API with Drupal, a REST API, RESTful endpoint. We can provide authentication so we can post content, we can retrieve content in a secure way, and serialization, we can basically serve JSON or pull in JSON. Decoupled, this is actually a computer science term, not just a Drupal buzzword. Basically, decoupling files is the separation of concerns. So separation of concern design seeks to encapsulate our code or data into component functionality with defined interfaces. So you might be thinking Drupal modules sort of offer this, but it's kind of unidirectional with Drupal because everything is just for Drupal. It's not really encapsulated in a grander sense. So decoupled Drupal, so Drupal can serve as an API to allow us to separate our presentation layer or content creation layer and the content model from each other, potentially. So we can create, we can separate the Drupal theming layer from the content behind it. So we can look at Drupal as a content modeling service, we can look at Drupal as content management and API. So there's a few different models for this. So we have situations where we might look at Drupal as a content management interface and API with many endpoints. So an example of that would be we have Drupal, which is being used to create content and manage content, but then we have multiple, one or many endpoints, such as maybe an Angular application or a native app, which pulls in content from Drupal. We could also have a model where Drupal is an API in Datastore and a tool for data modeling, but isn't used for content management. So in this case, you might have an Angular app which could post content to the Drupal Datastore and retrieve and display content from the Drupal Datastore, in which case Drupal is just an API, the client never even needs to see it. And then we can also look at Drupal potentially as an API to API interface. So very often there's benefits to a MySQL-based database schema versus a NoSQL thing, which you might be using if you're creating a Mongo app. So if you have a joint needs for two different types of Datastore in an application, Drupal might be that API to act as a bit of a middleware to pull and push content from different sources. So is that kind of clear to everybody? The whole idea of decoupled Drupal? Okay, cool. Okay, so why is it exciting to us as developers and designers and digital strategists? So developers, so generally speaking, developers are excited about new technologies when they get to work with them. So there's new technologies like Angular and React and Famous, which lean heavy into JavaScript, which we want to take advantage of. Drupal doesn't always opt for that directly. So another reason developers like this sort of decoupled model is when we separate our concerns, it allows us to focus our efforts in a more distributed way. So that means that you can have front-end developers and back-end developers working on different parts of the project. So say you have like a mock API for your data model. Back-end developers can work on building the API. Front-end developers can work on building the front-end without really running into each other, which is nice. It also allows us, web developers, it allows us to focus on sort of the fundamentals, the HTML, CSS and JavaScript, which is usually either what the user engages with, well, generally exactly what the user engages with, whereas with Drupal, sometimes we get caught up in database queries or PHP. And then we also, as back-end developers, we get to focus on APIs and integrations, which is kind of the meat and potatoes of back-end. Server-side stuff's obviously a big part of that, but the APIs and integrations is kind of the exciting back-end work. So designers, designers can like this too. So, I mean, I had sort of an overarching theme here that designers and developers can like this together because designers don't get as many nos from developers. So part of this is about the flexibility that a decoupled model can offer developers and designers. So we can move beyond the page-centric model of building websites. So generally speaking, a Drupal website is a bunch of pages. It's a bunch of routes and each page reloads. But a designer can start thinking about more challenging, like more application-like or dynamic models. So states and transitions become just as important as what the page looks like. User interface design shouldn't be about skinning or theming. We want to break that paradigm completely and we want to think about human behavior and the actual needs of a project. And another thing developers might like about this model is there's less time between that design and sort of the initial front-end prototypes. So it's easier to get a front-end built when you're not having to worry about Drupalisms. It's basically as simple as that. And then digital strategist. Digital strategist might also like this model because it allows us to focus on the content data model instead of sort of getting caught up in Drupalisms and Drupal content types. Often if we're architecting for a Drupal site, we're thinking what module are we gonna use for this field, what module are we gonna use for this front-end component. This just lets us think about the data model in kind of a more platform agnostic sense. So it also offers this sort of idea of a component-based architecture. So generally we're able to isolate things that we build a little bit better because again we're not thinking about how it impacts the Drupal site as a whole. We can build a component over here, a component over there for various content types or displays or features and which offers better scalability because we can sort of add things in a more distributed way. And also digital strategies like this because we can focus on the business logic, not the limitations of the framework. So with Drupal, sometimes we get caught up in well, what can we do with Drupal? Can we, should we use this module? Should we use that module? Ideally we're just focused on the business logic. Clients would prefer that most likely. Telling them that you're gonna activate a module doesn't really make you sound all that valuable. Telling them you're gonna solve their business problems is a good way to present value. Okay, so now we know why the developers, designers, why we as agencies or developers enjoy this model or are excited about a model like this. So let's start thinking about how we can start cultivating the right kind of clients for this model. So while you're browsing RFPs, some things that you might wanna take note of in terms of spotting the right client. So we generally for this kind of project you want a client to be unbiased. So what this means is they know what they need but not what they want necessarily. Sometimes you might get an RFP that says we want a Drupal site, fair enough. But if a client comes to you and they're very focused on individual needs that they have, then okay, now we can experiment. We can look at applying the right solution with their just applying the solution they asked for. So another good thing to try to spot for is distributed organizational structure. So certain organizations are gonna have really distributed structures. We work with a lot of unions. Unions have a tendency to have regional offices, national offices, and also Quebec offices. They have locals. They have basically a very distributed model for their organization and there's actually a really strict governance model in the way it all comes together. So organizations like that work really well for this sort of decoupled model because we can centralize content management and content distribution while having multiple front end end points to actually represent all these satellite offices. So a client with good long-term thinking. So sometimes clients just want a website. They want it in three months. Sometimes clients, they want a website in three months but they're also thinking about their long-term initiatives. They wanna build an app at some point. They want their content in multiple places. So long-term thinking is critical because that will help them to understand the model. So we also have to ensure that our clients are technical enough. So basically if you have a client that references the idea of API integrations in their RFP, they may actually be more receptive to this kind of model because they already understand this idea and value behind integration. And then another critical thing. This is like if you work in Agile, this is always sort of critical but not every client is receptive to it. We wanna be able to work really closely with our clients to build strong data models. So the idea with DeCouple, Drupal is that we're more focused on building the data model and ensuring it's rich. We can't do that if we can't get access to the client. Okay, so the right project. So another thing from these RFPs. So some things just high-level stuff that we can spot that may actually be a good trigger. So publishing workflow. If there's a big emphasis on publishing workflow, DeCouple might make a lot of sense. And the reason for that is that we can actually focus our efforts on Drupal as just a content management interface. We're not worried about the view-centric components of building a Drupal site. We're just worried about modeling a really good publishing workflow and a really good content model. So projects with multiple integrations. Again, if the client's referencing APIs, they probably get it. Then data complexity. So when we have highly structured data and really complicated data sets, not just blogs and articles, it really makes sense to start thinking about an API early on because there's probably a lot of different ways that that content's gonna be displayed. And if we're just simply creating different display suite view modes, it's not really answering the call of the data. And then another concern, if the client is looking to scale, like straight up, they just know that they're going to be scaling their project and the project that they're working on is part of a bigger picture, then it probably makes sense to consider this kind of model. Okay, so we took a look at some things that we might try to spot in an RFP. So we're writing our proposal. And at this stage, we're basically, we're trying to convince the client that we have the expertise and the know-how to deliver their product. We're not necessarily gonna get really specific about solutions, but we wanna start thinking about what we're actually gonna do for them and sell them that expertise in the right way. So some key points that we can use to sell this kind of model. So say we're going at them with a RESTful web service built in Drupal 8. Here's some value points. A well-structured API allows for greater data portability and interoperability. So clients are always concerned about their data being locked into an ecosystem. They're also concerned about times in the past where they've gotten burned by having all of their data in a site that just sucks and then they can't get it out and they have to rebuild it every five years. API offers data portability because fundamentally you have a model that's built on REST, which basically is designed to allow content to come in and out. So another key value point, having an API that lives at the center of their digital ecosystem, a lot of clients are gonna have these weird distributed systems where they have a CRM over here and they have three websites and they have an intranet. The idea of an API may lead to this idea of a more centralized ecosystem for their data because an API doesn't always have to be public-facing data, right? It's just a mechanism for pulling in data from different sources and interacting with it and serving it up. So and on that topic, this whole idea opens up avenues for their content to be distributed. So a lot of clients will get excited about the idea of building a native app or building multiple websites off of one platform. This actually comes up a lot for us. So that's a big value add to approach things through a RESTful model. So selling Drupal, obviously we're at a Drupal conference. So we're all interested in that. Why is Drupal the right solution to this kind of model? Drupal offers arguably the best open source content management solution. With, we've got solutions for internationalization, advanced user hierarchies, content moderation workflows. All of these things are content management centric and they're fairly advanced. So out of the box we get a lot of functionality. And then with the decoupled model with content management for Drupal, we can actually securely hide that from public access which is actually a value add for a lot of clients. Drupal sites get hacked. That happened a lot last year. If you didn't know that, you probably have a bunch of hacked Drupal sites that you haven't been dealing with. So everybody laughed because everybody dealt with that last year. Yeah, so the nice thing about this decoupled model is we can sell clients on this sort of walled garden for their content. The content is hidden back there and we don't have to worry about anyone hitting it or hitting an open PHP form and taking their site down. So we also have the value that content can be sourced from other REST endpoints or other endpoints in general and then the moderation workflows can allow that API to act as a content aggregator. So aggregation is always something that clients want but we're still delivering XML feeds. The REST model offers something a lot more robust and Drupal is a great place to bring that data in and moderate it. Okay, so another great solution to offer to our clients is this whole idea of decoupled front end and using modern frameworks. So a big thing is updating a Drupal site is really costly. Generally we scrap it, build a new one. I mean, how many upgrades from Drupal 5 would you do? No, you wouldn't. You would find a way to get the data out. You would and build a new website. With this it's different because the data model maybe doesn't expire nearly as frequently and we can update the front end without really the concern for the back end. So we also offer more dynamic app like user experiences and interfaces so UX isn't a buzzword. It's fundamentally about solving actual human problems. That's hard to do when you're locked into an assortment of Drupal contrib modules that have most likely been designed for one very narrow purpose. We wanna build the right kind of solution. So using modern frameworks can offer that. The possibility of mobile applications, again that's a big thing for clients. And if you look at organizations in the education sector, they're all considering ways that they can improve their information ecosystem to include apps. Modern frameworks like Ionic, React Native are getting there to a really strong degree. And then also we're looking at potentially mixing of static and dynamic content by using modern frameworks so we can ensure performance and engagement through a combination, like a multi-tiered approach for how we're displaying content which is a lot harder to achieve in Drupal with just caching. And then the greater scalability, we can add new end points with still maintaining one API. Okay, so obviously a big part of what we sell like if we're in the Drupal business in general is this idea of open source technology. So continuing to sell Drupal means continuing to sell Drupal as a pillar of enterprise ready open source. And we only enhance that reputation by actually looking to other open source technologies and other open source ecosystems. So sort of broadening the scope of what Drupal is involved in and integrated with. And another thing about the open source sell is clients don't wanna be locked into a proprietary system. We're offering them ways to get their data out and we're also offering them the open source technology they can take over should they get sick of us. Okay, so another big part of this is the process. And our process changes when we look at a decoupled model becomes a bit more like the process may be for other people in the industry. So a decoupled model allows us to better focus on solving content modeling problems and not site building problems. So what that means is traditionally with Drupal we pick the modules before we pick how the content should be modeled or how the site should work, which is a bad thing. So we wanna focus on user flows, wireframes, site maps, which you're probably doing with Drupal anyways but the problem is you're always in the back of your mind you're always thinking we're gonna build this in Drupal so we need to think about certain things. You don't wanna do that. You wanna build the right thing, right? You wanna focus on the technology that will solve the problem identified by your user flow, personas, wireframes, et cetera. And you know exactly what is listed here basically we can uncover the most meaningful interaction and experience to suit the business goals and needs without being stuck just in Drupalisms. So another part of process I touched on this earlier parallel development and tighter feedback loops. So once initial discovery and design begins the data layer and presentation layer can develop in parallel. So that means faster tangible results for the clients. You know they can see that front end before it really does anything which is actually quite useful and it makes clients feel that things are progressing versus if you show them a completed unthemed Drupal website that they can click through. That means nothing to them. They hate that. It's true, it's true. With so you know and then you know basically because we have effective visual prototypes being built ahead of back in functionality we can tighten our feedback loops especially with user testing. And very often we don't wanna user to see the website until it's done because they'll be confused, right? You show them an unthemed website and tell them to find information. It's meaningless to them. So ideally you know those prototypes give us an earlier trajectory for bringing in user testing and user feedback. There we go. Wonderful. Oh okay I see. I guess I'm talking too much between slides. Okay so another part of the process once we've finished building something the nice thing about decoupled model is the model has a greater long-term viability so you know we've built them. Even if the API becomes redundant we still establish the data model and because it's something that's structured in and maybe JSON or something similar to that then you know we understand we have a really easy way to get the data out and we have a really easy way to get the data model out. It's not a Drupal MySQL database, right? So that's you know the viability of the data model is a strong thing but also the API can live longer because the front end isn't really paired to it. Fancy technology. Okay so separation of concerns also means that support and maintenance can come at a lower risk. You know if we have a Drupal front end that's built in Angular we can focus on fixing issues in the Angular app not in the API depending on where the issues actually lie. It's probably just because I'm wandering and it's like tugging at the bundle of cables here. I'll just stay closer. Okay so the other component on all this is working with the right people. So which is another thing we're selling our clients and you know it's critical to us. So one of the problems with Drupal is being a Drupal Dev is it's kind of a narrow focus whereas meanwhile the rest of the digital you know the industry around digital has kind of evolved these new roles that you know ideally we're all sort of stepping into. We don't want to be Drupal Devs. We want to be content strategist. We want to be developers maybe JavaScript developers. We want to be product designers, data analysts. So you know when you're looking at a decoupled model it allows us to be a bit more agnostic about the system we're working in. We're not just delivering Drupal results. We're engaging in the entire digital agency process which is a little bit harder to do when you're just focused on Drupal because you get stuck on Drupal problems. Okay so you know I've gone over you know what I see is some of the benefits the ways we can sell it to clients. So here's just some questions that have maybe come up you know and when we've talked to clients about this kind of thing. And you know that may just be things you're wondering yourselves. So we have a client that's familiar with Drupal. So they have expectations about what a Drupal site is, how it works, what it looks like. So how do we manage that in a decoupled system? So you know familiarity with Drupal likely means a familiarity with the drawbacks and the benefits. So you know we know the pain points that we always hear. You know we had a Drupal site and it was slow. We had a Drupal site we couldn't upgrade. We had a Drupal site that got hacked. You know so while we don't want to focus on the drawbacks we don't want to like go to our client and tell them that Drupal sucks and these are the reasons. We want to focus on applying, the real key is focusing on applying the right solutions. So we want to identify tangible solutions and if it makes sense to use Drupal then we use Drupal versus just deciding that Drupal is the de facto solution for everything. So you know the idea is to look at Drupal as part of a suite of solutions that we can offer. It isn't, and then acknowledging to clients that it isn't the best solution for everything. And you know that providing that kind of transparency about a tool that you may love working with is a positive because clients, it's a good way for us to encourage clients to try different things. Okay so you know this is a big thing with decoupled. There's big concerns that you know we have clients that want to be able to edit in place because they saw that at a Acquia demo. They want to be able to adjust layouts and add widgets to pages. They want their changes to appear as soon as they've made them. They don't care about publishing workflow. So you know Drupal can share offers all kinds of awesome site building tools and you know sometimes we expose that to clients but we all know the cost. You know we go back to Drupal sites we've built from years past with really open architectures and they look terrible because the client has you know put all sorts of weird HTML in the page. They have embeds from all these weird sources. You know basically they ruin what at the beginning may have been a well-designed site. And then another issue. You have clients who are constantly clearing caches. They're constantly you know they want to see instant results or they're you know they're insistent that their site be basically uncached because they're constantly updating information. Then you end up with this ridiculously unperformant site right. So I mean you know it's kind of a counter argument to the whole hey I should be able to publish content and it appears right away. Well you shouldn't. There isn't a digital ecosystem on the face of the planet that accepts that as a reality unless they're built on like you know serious next gen real time technology which Drupal isn't. So you know there's any number of ways to architect you know view-centric solutions in a Drupal decoupled system. So what I mean here is not Drupal views. I mean like view-centric as in you know when we're coming up with our data model you know in Drupal sometimes in a content type we'll put all kinds of toggles and switches that will decide how that content is displayed. You know panels is a good example of this. We have a node and then that node has a bunch of widgets associated to it as a panel entity. So that's where we circuit to get into this like view-centric content modeling or data model includes things about how it's displayed. In a decoupled model we want to completely avoid that or at least avoid it in the central data model. So you know the point is here is you know we want to sell our clients on the idea the value of the data model over you know and also the value of our design thinking as design specialists and UX specialists not just selling them on this idea that we can just activate modules and they're gonna get something for free. And then you know the other side of this is the idea of a managed editorial workflow. If clients want their content to suddenly appear you know it's I mean there's a lot of risk to that right they can make changes that can break their site. You know especially if you've given them a lot of control. So you know there's a reason that we as developers we use things like Git for version control and quick revision and stuff like continuous integration for our development projects. You know getting a client to think on that level is a positive and also I mean you know if we're working with organizations that don't have a traditional publishing background and they're just sort of in this communication sphere you know their whole mindset is well Drupal offers the ability to publish content anytime I want. But if you actually work in like for publishing companies it's not how actual real publishing works. There's an editorial workflow. People contribute content. Someone decides when it goes live. It's scheduled to go live. It's not just save and then it's live. So you know getting them to think about a real editorial workflow is a positive and a good way to sort of sell counterpoints. Okay so the third one. This is probably the most contentious one. The client is technical. They get the whole model. They get the IPI. They get the front end and the framework. They don't get Drupal though. They're experienced. They're technical. Why PHP? Why MySQL? So you know we're used to justifying Drupal as this complete solution. But this whole idea of decoupling forces us to look at Drupal more objectively which I think is a positive. So you know we want to stop and think is Drupal actually the right solution? And we have to be you know accepting of the fact that sometimes it's not and by accepting a decoupled model at times we're not going to be building Drupal sites. In fact we'll avoid them because it's not right for the project. You know so as digital agencies we're used to this idea of building elaborate systems with Drupal which is really empowering but it can also be a crutch. You know we often don't take responsibility for the modules we use. And you know and very often we're creating functionality that maybe it solves the need that the client was requesting but it doesn't actually do it well which is a problem. So the question is are we in the business of providing the right solutions to clients and their needs or are we simply in the business of selling Drupal? I like to think that you know a lot of us here want to sell the right solutions to clients. You know so that again the decoupled model forces us to question our underlying assumptions about our technology which is always good. We should always be questioning what we're using. As Drupal of eight involves into this platform that can support decoupled models we have to continue to justify its place. So that's as contributors, as people coming to speak at Drupal camp we have to continue to explain why Drupal still matters in this you know this decoupled or component-based architectures, scalable architectures. So you know in this specific case when the client asks the question the client might be right and we have to be ready to accept that and provide them an alternative to Drupal if necessary. Now obviously this is if we're getting into this territory of decoupled Drupal. If not you know fair enough you're selling Drupal sites. But you know part of the if we're modernizing our workflows we're looking at new technologies at a certain point we may have to accept that Drupal is not going to be the center of our business which is okay. Okay so that's basically it. So if anybody has any questions or further challenges looks like we have some for sure. Yeah I mean that's one of the core strengths. Oh no I'm not suggesting that I'm just preparing us for the reality that occasionally you will say that. You don't have to sell it every time right? I 100% agree and that's exactly how we approach it with clients right? We are selling clients the idea of Drupal as industry class, enterprise, content management and you know with Drupal 8 we have this really strong intelligent API. So I'm 100% behind that. It's just part of decoupling. It means that we have to actually fundamentally look at you know solving problems in this sort of component-based way right? Where here's a solution, here's a solution, now we have to assess which ones are the right for the right solutions for a given client. And you know it might be uncomfortable for us because we're used to just saying well Drupal obviously but you know is that best for your clients? Maybe not. Sure. Oh sorry. It kind of makes me think of selling any other good practice. Like I like to sell for example automated testing to my clients. I've been doing that successfully but in some cases my clients like not getting the idea about it because they're not understanding why you're spending so much time on it. And I kind of got to a point after a few years where I just do it anyway. Yeah. It kind of just becomes this best practice that like you know I'm gonna do it and I'll explain later. For sure. I'm wondering if you think that like in the case of, is there any case where you would not use decoupled Drupal having done it now for a lot of clients, is there any case where you'd say for this project it's not good or has it become kind of a defective? Oh definitely not right. I mean again it's a lot of clients are coming to the table with a bias right. That's why we have this point on like the unbiased. You know client is you know basically a lot of clients they have a bias they want Drupal. Especially government clients unions like anyone basically you know kind of bridging on public sector is gonna already know about Drupal. There's like a government mandate to use it. There's a government distro for Drupal. So I mean you know there's these mandates to do it and sometimes you're just gonna obviously accept what the client wants and do the project because it's good value to you and it's what they want. I mean I think like it's not always the case that you're gonna have to actually sell them on the model. Sometimes you're just gonna do it because the client doesn't know what they want. You know is it important for the client to know what the underlying technology is? Yes. But you know if you're presenting yourself as the expert you're helping them decide that technology right. So like what you're saying in terms of automated testing and you know you might list that as a bullet point of what you've offered them and charged them. But you're doing it to protect yourself and you're doing it to make your work higher quality, right. And it's the same thing with Decoupled Drupal. For using it as like the right solution it's not because we're just specifically trying to convince the client to use it because we want to do it. It's because we actually believe that it's a good solution. I think I had a question. We have to follow on to that question. So you had two really good slides on like what the right client is for Drupal or for Decoupled or Headless Drupal and like how do you recognize the RFP that's gonna like each on that direction. I didn't see a bullet point in there about like budget but it was kind of the underlying theme of a lot of those things. And my impression is that for a Headless Drupal project to make sense it's gonna be a big project. Yeah, so I mean I think there's two sides of that. I think like you know we're Drupal developers so we have an established suite of things that we use, right so we have in-house distributions, we have modules that we've contributed and or we just have modules that we like using or other people's distros that we like using. These are efficiencies that let us build faster and cheaper for us at higher profits or we can accept smaller projects and still profit from them because we know how to do them faster. I mean I think like the evolution of a decoupled model is the same thing. We wanna be able to offer client, we wanna be able to have in-house the tools necessary to build a decoupled Drupal site faster than we could build a normal Drupal site and then that's a benefit for us. I think that's actually the reality long term but I think if you're just selling it to a client and they're absorbing all the costs, yes, it's likely higher. That's one of the big benefits of this because you know Sean already pointed out you can have focused efforts, right? The picture relates of the solution. As an individual, if you're building a small site ready to be wearing all the hats, this is gonna be a harder or more difficult challenging model. I mean you may have the talents across all those different touch points, right of the project but it's gonna be some overhead, right? So the efficiencies come when you have that distributed model and then the nice thing about having those efficiencies in your production cycle is you can concentrate more on the strategy, the design, figuring out how to build the right thing and that's a clear value to the client but also clear value for your agency because you end up building better things and when you build better things then you get more opportunity to build other things. Anthony? Anthony? Is it Tony? Angelo. Angelo, sorry. Sorry. Try to be clever, sorry. I apologize. That's fine. You'd mentioned that for situations where the client is like, yeah, we want our content to appear like that and we want our site to be super fast. You said that, sorry, you have to go one way or the other? Not necessarily, but sorry, go ahead. I was going to say that there are ways, if the client does have a large enough budget and you do, but not through hardware, through software, we've had success with Varnish and our requirement was, yeah, we want our content to appear ASAP as soon as we save, but we want it to be speedy. Yeah, through Varnish, you can do that. Unfortunately, some hosts don't provide Varnish on their servers. That kind of sucks. You might have to host in-house, which is going to increase your cost so long as the client is willing to accept those costs. Hey. Yeah, I mean, there's definitely, obviously like caching is part of a performance strategy, but there's sort of a fundamental difference, right? You can also put caching on a static site and it's still going to be way faster than anything you built in Drupal because the problem with caching is, relies on caching pages that people are going to. So, I mean, one of the nice things about stuff like, no SQL based databases is because they're document based, they're pretty fast, right? If you look at something, a good example of this is, so Craigslist, they actually have a two-sided model, they have two different database models for their service. They have MySQL for all the transactional stuff and then they have a Mongo database, which just stores long-term data, which seems like kind of the opposite of what most people talk about, but so because the NoSQL database is actually smaller and it actually, because it's document based, it's more efficient and fast for long-term results and archived results, whereas the MySQL model handles all the transactional stuff. So, I mean, it's just like, there they've actually decoupled their own system, right? They have two different databases serving the same platform. I mean, there's a lot of value in looking at those kind of models. The problem with Drupal is, the only thing you can do is rely on the caching or you have to bring in decoupled elements into a Drupal site, or you're bringing in static site content, not relying on Drupal Bootstrap to present your content. But again, at a certain point, you throw away the Drupal theming layer and you start feeding Drupal data into something that is designed to be quicker and present data in more performant ways. But yeah, no, there is caching for sure. Is that okay? So how does all of Drupal have a very special sort of database model where everything works with joins, right? Yeah. It's very special to Drupal, how Drupal works. I had a lot of people about this and they say, well, we want to do something else for this particular, what would you suggest people do in such a case where you don't get to use then all the content curating models and everything because you're not using the same database from there? Well, I mean, in the case I was just pointing out here, it's kind of where a two-tiered approach where we have different database models for different solutions. Just in a simple decoupled site, you don't have to have a secondary database model, right? Drupal is the API that's serving the content. So you have an endpoint, which is potentially cached and then you have some sort of data store which really just brings data in when it's required and then you have your front end. So you have like Angular that's hitting something like JS data to pull in its content or pulling content from the Drupal site. So I mean, fundamentally, there's never another database model. It's still just Drupal. So if you need to do those kind of complex queries like relational queries, you still can. It's there's no reason you wouldn't. Your API just needs to be able to like, you know, obviously pull in those kind of queries. Mind if I comment on that? Yeah, you're referring to field safety and the field API. So you have five or six fields. You query a full node, you need five or six joins. That kind of stuff. If you're willing to put the effort into it, you can use the entity API and create your own entity. So literally all your fields are essentially one table. Things do tend to go a little bit faster, but it does require some manual work on your end. Any other questions? All right. So one of the selling points, you're talking caching, but one of the selling points is probably the extra layers of caching. Yeah. So you can cache the API as well as the front end of the standard varnished caching. Yeah. That makes a big difference. For sure, yeah. And you can have layers of that, right? I mean, if you're using, I think, you know, like obviously you can, you can, if you're using like some sort of views based endpoint, you can cache the view. You can, so you can cache the query. You can do the varnished cache. You can do memcache. You can do it. It's just, the list goes on. Just on the, I typically don't directly respond with explicitly, unless the questions lead towards that. So unless the person who wrote that or he actually knows what they're talking about and will actually appreciate that angle. So I keep it more general. Technical enough, right? Yeah. And the conversation about like, should we decouple, should we not decouple, should we have some sort of a mix between that? Do we have a static site generator, whatever, right? That conversation and that whole thought process is way too premature. Yeah. You're just looking at. Right. Well, this is why, like, you know. That needs to be pushed off. The big thing here is, you know, we want to focus on like our strategy upfront, right? And then the technical solutions should be informed by the strategy. If you're going at a client just saying, we're going to build you a Drupal site. Now let's do content strategy. Let's do digital strategy now. It's like, well, you've already moved beyond digital strategy. You decided you're using Drupal. So, you know, like, I agree. Like, I think it's important to make sure you know what you're, you know, know what you're, they really need. Yeah, exactly. Any other questions? Oh, over here. One of the questions you don't have. Right. You recently made a sort of like a reverse proxy for the friend sharing. So some page will go to direct you to the site. Right. Right. Have you ever come to that problem? Have you ever tried to solve it? So the, anything like SEO related or share related comes up. You know, I mean, there are pre-renders for, you know, stuff like Angular. You know, I think long term, you're probably going to see a lot more like a decoupled site isn't just the front end framework. There's actually like, it's an isomorphic application where there's like, you know, a data store on the Angular side or on the JavaScript side that's actually handling sort of this like post content management serving. So I think like, you know, probably long term, like a lot of those kind of issues are going to be more like in the JavaScript side than on the Drupal side. I mean, it's ideally that Drupal does like, is agnostic to the display layer is necessary. Right. So, you know, pushing people back to your Drupal site because there's deficiencies in your Angular application, probably isn't the best long term strategy, but Angular has all kinds of holes, right? Like, you know, very often people get excited about it and then they're not thinking about SEO and they launch a website and Google can barely crawl it because they haven't provisioned it properly. So obviously there's challenges, but you know, I mean, if that's anything new, right? I mean, I think, you know, the fact that Google is kind of the central force behind stuff like Polymer and Angular where there's sort of, I mean, especially something like Polymer where it is kind of in itself this decoupled, you know, component-based model, I think it makes sense that a lot of those problems are going to be solved, like, you know, or have probably already been solved, right? But that's on the Angular side. Mm-hmm, yep, right. Yeah, avoiding bootstrapping Drupal seems to be kind of one of the main threads with any of those. Yeah, I mean, you know, shy of like having, you know, there'd be a completely second thread of Drupal that kind of lightens up that bootstrap. Yeah, I think most decoupled projects probably benefit from considering, you know, a secondary database stage or like an API, like outside of just the Drupal API to like, so you're not just bootstrapping Drupal every single time you want to do a query. But I mean, like, I've just got some over here, like, you know, caching can help at least mitigate some of your API performance issues. So, you know, you're bootstrapping Drupal, but really like with a hybrid solution, like you're still bootstrapping Drupal, but at least it's cached. That's like the obvious one. Yeah. I have the data served up with JSON pages, just lay it however you want. Yeah. About the editing experience, have you guys worked on any of the couple projects? So, it's one of the first things that we were talking about or that I mentioned was just sort of like the different models. So, we're actually working internally on a project that kind of touches on this. And basically the idea is to completely decouple this whole interface, but as part, as a component-based interface for your front-end. So, the idea is on your front-end, you're gonna have, you know, components. Maybe you looked at those as like content types or widgets sort of the hell you want to look at them as. And then, you know, you need to edit or create those. So, the idea is to actually put that directly in the front-end. And then bypass Drupal's content management all together. So, we'd be building a content management interface that's easily integratable into whatever front-end we want to build. Yeah. So, we haven't gotten too deep into that, but obviously that's the ultimate is when we can actually build proper workflows for content management. Drupal's great at content management, but it's also really technical. That's a whole task in and of itself is teaching people how to use Drupal content management. And then you look at stuff like Tumblr or even WordPress in certain ways. They have slightly better user experience. We can, you know, we can add a theme. We can format our forms in Drupal. We can do all sorts of stuff to beautify it. But, you know, the fundamental failings of Drupal are in, you know, telling stories or, you know, providing really narrow user experience or content management user experiences. We had a conversation with a client the other day and they were talking about they had this, you know, really complicated matrix in their RFP for permissions. You know, they're like, we have these users that want to be able to edit this kind of content on this specific page and this, this, this. So with Drupal, we can install like, you know, 10 layers of permissions to like, you know, make a block on a page, you know, editable. But if you're doing sort of this decoupled, you know, content management interface, you can just build an interface just for that person. You know, I mean, maybe not that narrow, but like just for that role. So if you have one person or like 10 people at an organization that only edit one type of content, why would you give them access to the Drupal content management experience, right? Just give them a really simple portal they can log into and edit that one thing. So anyways, and ideally, they can also do that directly on the front end. It goes through a publishing workflow. So anyways. Just to expand on that idea, even when it comes to editing content, doesn't necessarily even have to be a person, right? No, exactly. The other system. Well, that's, you know, we've got external APIs that can feed into Drupal through the API. The first thing like crud kind of system. That further segments that team that I was talking about before, right? So now you have concepts of content manager may work in Drupal and then the information architect works in Drupal directly. Whereas the actual contributors are working in some angular front end. Exactly. Somewhere else that's very much tailored towards their particular role and needs. Well, there's also a lot of third party stuff for that too, right? Like if your data model is, if your Drupal data model is agnostic enough, you could have like, this could be like contentful, you know, stuff like that. Like, you know, like gather content. I guess that kind of stuff. Like where they have APIs, there's a tool called import.io that's really good for like just scraping data from wherever and building an API off of it. You know, like there's all kinds of ways that you can have these external APIs that pull stuff in and that make their way into Drupal and then make the way out to whatever it is that's on the end. There's another alternative mechanism we use to avoid bootstrapping Drupal all the time. We write a lot of mobile applications. We basically use Drupal to hash data, to create data, and sort the cache base. And we query cache base directly. So with Drupal, it can just create the documents. Right, right. Sorry, is this cache db? Is that what you said? Cache base. Okay, I'm not familiar with that. It's a very same idea. The only difference is that you have a very good HTTP interface. Okay. That's supposed to be in the way. Okay, cool. Great, that's awesome. Yeah, I mean there's tons of solutions. I think it's all about what you wanna use Drupal for, right? If you actually, if the Drupal content management interfaces your value, great. If it's the fact that you get an API out of the box with a strong MySQL based database out of the box. Great, it fits in in so many different ways. It's just about seeing how you wanna do it for a given project. The keynote talks a lot about open source. So as we decouple Drupal, have you ensured that the content management system that's plugged in the Drupal is also espousing similar value? Or are you creating a proprietary software set to apart? No, so I mean, for what we're doing internally, obviously the goal is to open source it. A commitment to open source technology is critical if you're gonna take advantage of something like Drupal. Ideally you're contributing, if you're not, then hopefully you're contributing to somewhere else. I think everyone in this room probably agrees that open source is kind of the way the future is for our software goes. Or at least the way of the present, and it's awesome. So anyways, yeah, I think the goal is to use, to always be open source as much as possible. I mean, obviously there's balances to that. There's companies like Acquia that have huge contributors to Drupal, but they also have their own proprietary systems that they're leveraging to make profit. And I don't begrudge them that. That's part of the awesome thing about where open source technology is right now is that there's actually a lot of money to make around it. I think the key is to make sure that if you're building something that really leverages something else, it's good to give back. And if you really wanna build an ecosystem around something, I mean, that's the model that made Drupal successful. Making it open source and looking for contributors is a, or at least even just people to use the platform is a critical way to manage your software ecosystem. Anybody else? Great, I'll be there. Awesome, okay, thanks a lot.