 from it's somewhere in like the 10,000 lines of code and I need to be able to actually have I need software to write my software because otherwise I can't keep track of all the things that are coming and going. And then that's contrasted with this decoupled approach which in the general software industry is now often termed microservices but in the CMS space you know it's the idea of decoupling your CMS so that you don't have everything happening in one application. And we can talk about why this provides specific benefits and why people are interested in it also some of the caveats and things you should be aware of if you find this of interest in our considering it. But it's important to note that this isn't something that's just a Drupalism. The moniker quote unquote headless is sort of a Drupal community thing because it sounds cool and like I bear some responsibility for that like I made a neat mashup graphic of like a headless horseman holding a Drupal instead of a pumpkin but that's sort of like a fun thing that we came up with in our own world. More broadly in the world of websites and website makers the notion of decoupling your CMS from some of its other components particularly decoupling the content management from content display has actually been around since the very beginning and this is an architecture that actually has a lot of legacy in the web and a lot of things going forward. So monoliths try to think of their big blocks of stuff and they have everything in them. You can kind of think of the monolith at the beginning of 2001. It's just like it's all there and the idea is it's a totality and it contains everything. In the Drupal world you might say well we do have these different functionalities and in fact we have a separation of concerns. It's not actually really monolithic because there's the theme layer which is you know there's a different directory where that code lives and themes are invoked in a different way than modules and it's different than core for sure and that's true but the thing is that that's more of an internal convention rather than a strong separation of concerns. The boundary between what happens at the theme layer and what happens within Drupal core is very permeable. That gets a bit better with Drupal 8 and twig where there's actually maybe a stronger separation of concerns between literally the templates themselves and the theme but you still have all of the logic that's in the theme that bounds how layouts are constructed and when they're utilized and sort of like what content is present for each template. That software that code that's programmed to do that essentially has an unmitigated access to the rest of the system and vice versa and so what happens when you have that permeable boundary is even with the best of intentions and following best practices there's usually some and sometimes there's a lot of spillover between the two areas and so it's sort of like you're playing Twister with your code and Twister is like an exciting and yet awkward game of chance and for the projects that you're building this is why for instance you know you may think hey we have a we just need a new theme I don't want to do really anything big to my website I just want to do a little bit of a redesign can we build a new theme and suddenly you discover that actually that's going to require you to refactor a great many things and the reason is that things are all twisted up. This is also a frustration to front end developers people who don't have a lot of Drupal specific expertise but have a lot of experience building pages for the web because what happens is our Drupalisms the things that really only exist in Drupal or are only familiar to people who have years of experience with Drupal end up leaking out to the front end where general web developers who maybe have years of experience building amazing web pages and doing awesome stuff on the front end are kind of like scratching their heads and be like what is this stuff and why is it here it feels really like foreign to me and it gets in my way. So the monolithic architecture has these drawbacks in that it creates confusion for the front end developers they have a harder time latching on and working with Drupal because there are so many Drupalisms that leak out and then internally even the Drupal savvy developers because of all the twisting up of things can sometimes end up in a position where they're not able to move as quickly as they want or they're being frustrated by unintended side effects or they just find that it's actually very difficult to meet the needs of the business and if you remember the beginning of 2001 and when that monolith came down the result was that the pre-human primates that were down there they got pretty ragey and they ended up smashing things up. So in the worst case scenario the kind of a kluji monolith actually leads to a lot of unproductive work for developers a lot of unnecessary factoring a lot of having to roll things back because an unintended consequence occurred and these are the reasons why from the developer side people are definitely excited about a different way of building websites. The different way of building websites involves a strong separation of concerns and in general although this actually burges out within that whole idea of microservices and I'll talk a little bit about that at the end in general what people are talking about here is they're saying hey I want Drupal to be the repository of my content I want it to like handle the editing of content and some administrative stuff and then I want something else hand wave hand wave we'll get into that later something else to handle the display of that content to my users and the difference is that we're going to communicate over an HTTP API between the Drupal backend and that something else on the front end that creates a strong separation of concerns because the only thing that can be passed over that API is data these days most folks use a REST API and they use JSON data that's the most kind of widely that's the lingua franca of the of the distributed web and what that means is that the on the front end that client can be ignorant of almost all things Drupal it can just consumes these you know objects in JSON and then does whatever it thinks are necessary and that means that if you can agree upon what will be passed back and forth over this API that's an important point to note one of the key things from a practical standpoint building with a decoupled architecture is having a lot of this stuff mapped out ahead of time and even kind of prototypes so that there's a spec of what there's a contract even that's the way the developers often talk about it there's a contract between the front end in the back end of I will ask for this and you will send me that and that creates like a good solid foundation on which you can execute and one of the nice things about this is that people can actually execute in parallel once you have that foundation and it kind of makes people happy and everybody wins the reason why everybody wins is that the folks are able to use the tools that they prefer so a Drupal back end developer doesn't need to worry about theming and the front end developer who may or may not know that much about Drupal at all is able to use whatever tool chain they'd like because all they're doing is you know getting some some JSON files over this API and then rendering them as you know per the specs so that they can have things work for the client and there's an enormous amount of innovation happening online in that front end space with the you know kind of HTML5 becoming the new standard flash is finally dying out thank goodness and and we're just seeing like the rate of progress in that front end development space is really really rapid and for us as Drupalists I think it's really important that we we are a part of that I think we can actually play a really important role there I was recently at a conference that had a whole angular conference of anglers a JavaScript front end so it's a it's a JavaScript framework for building rich front-end applications and they're doing like really cool stuff like you know interactive applications that if you're not on the internet will save your data locally and then sync up with you know the mothership whenever the internet access comes back and figure it out like really advanced stuff like that that's just great but they are sort of not they don't have a lot of sophistication when it comes to what their angular front-end applications are talking to and I think there's a really amazing opportunity for us in the Drupal space to show how these pieces can fit together here we have a robust content management system it has all those wonderful administrative capabilities it's got great editorial capabilities it has access controls and users and permissions these are all things that you really are hard and on some of you don't want to implement in the front-end because they're easily then that you know you're putting that code in the hand of a user a malicious user could have used that code coupling these things together and showing or certain I shouldn't say coupling since we're talking to be coupled connecting these things together in a structured way creates a lot of opportunity and it's a chance for Drupal to sort of connect itself to one of the most vibrant and active parts of web development today like I mentioned before another reason this is really exciting people is that it allows you to parallel track your work this is something that's been the vein of almost every Drupal project that I've heard of to some degree or another that you have this chicken-and-the-egg problem of well we need our content model to be set up before we can do our design and then once we started implementing our design we discovered that the content model was in some ways not you know we missed something and then we had to go back and then we changed that down some parts of the design were not implemented correctly and there's this kind of ping-ponging that can happen on a more complex project especially between the developers who are creating the core back-end for the system how the content is stored what the business logic is and the femurs who are working on the front-end and oftentimes the dynamic between those two different teams can become kind of a little bit you know statically which is not great with it and that can certainly happen in any project this is no by the vitamins who I mean to recommend that like decoupling is a silver bullet that prevents you from ever having developers at odds with another but if you are able to create a contract between and then you start with that as a spec really you start with the API spec and there's really tools out there for and processes out there for for creating and managing API specs you start with that then the front-end developers can just go because they have a spec to work against and they can kind of you know may they can have something that mocks that spec that just provides the basic responses and they can just be off and running on as soon as that is done while the the back-end developers are implementing the real-world version of that spec and then you know once you start to actually connect the two there will be a little bit of a back-and-forth but that's done by figuring out changes to the spec amendments to the contract if you will and that creates a structured mechanism for figuring out how these pieces end up connecting and because what they're connecting over is a rest API that there is a it is bounded right that the impacts of changes are knowable and can be understood and planned for an advance you're not gonna suddenly discover that there was another piece of code somewhere else that included some hook that was now being invoked and you know your user profile pages blew up unexpectedly that those sorts of unintended side effects that are the result of the game of twister are no longer as they're far far less likely to occur and you have a good structured way for doing this and you know people can work in parallel and the last real reason that I think people are extremely interested in this is that it creates some notion of future proofing. I think there's really two aspects to future proofing when it comes to decoupled. The first aspect is if you have a decoupled back-end and a contract for what the front-end should you know is going to expect to receive and you know the and then the front-end its own business how that ends up looking it becomes a relatively straightforward proposition to say I would like a different front-end because you can you can sort of pop one off and put another one on you can run to in parallel relatively easily you can change the front-end without necessarily having to change anything at all on the back-end that you might find that your new front-end you want to do some design things that involves capabilities that didn't exist before and then you have to like look at how you need to amend your contract but in the simplest case if you just want to say go for you know go from your existing design to a completely mobile first design or if you want to have the option of like totally different designs for desktop versus tablet or if you want to have a design for your site an experience of your site's content that's totally different for a certain type of user or so totally different for a certain type of use case you can actually run that as a separate front end using the same contract in the same API talking to the same back-end and that's a very powerful capability so the idea that you can future proof yourself from like you know having the ability to iterate on your user experience without having to overhaul your whole CMS that's a that's a powerful and attractive idea the other future proofing aspect to this is the the macro trend for the web is this notion of services that interconnect with one another the notion of the internet of things the proliferation of things that consume the web is is you know there's we're not in some kind of weird future like you would see in an IBM ad but they're not wrong that that's the way that things are headed right the notion that a person looking at a web browser whether that's on their desktop or on a mobile device is how the web is consumed that's you know not really true anymore and it's only going to get less true over time so you have the the the very obvious and actually quite present case of mobile native applications that want to consume things from the web from CMS is decoupled as a way to serve that use case you also have the notion that maybe there's other sites you know maybe your content is being aggregated by other systems and and you want to be able to give it to them and rather than having them scrape your website you know it's it's kind of ironic that the lengths that Google goes to to determine semantic data out of just web pages you know they have these little tags you can throw around stuff which is awesome and that's what you get like event listings or other cool things when people search for your stuff but there are many many many many other websites that aren't just scraping the the you know scraping the HTML off your web page they'd like to interact with you on API level and that might really be of interest to you or vice versa maybe you want to consume data from some other API and you don't want to have it all kind of being forced to go through Drupal's database with a decoupled front end you could say that front end gets some of its data from Drupal and some of its data from another source maybe there's multiple sources that are involved and that's an exciting use case that's becoming more and more realistic for more and more people so the idea of decoupling now as a way of being better positioned to take advantage of future internet use cases is another aspect of future proofing so I want to talk a little bit now about caveats because that was a lot of exciting stuff about decoupling but there is as with anything where there's excitement there's also maybe a little bit of over excitement or I wouldn't say hype but generally you know people people developers in particular get really enthusiastic about this stuff because it's really cool and it's really fun but there are definitely drawbacks and risks to doing it this way there is an interesting blog post just was just titled the cake is a lie that talked about all the ways in which people might misunderstand what is going on with with the coupled and decoupled Drupal in particular so one of the first things to point out is that all of this is serious work to build there is no even with like the coolest proof of concept examples that are out there and there are some really cool ones there is no turnkey way to build a decoupled website that serves any particular use case there are just you know as far as we've gotten our basic patterns for connecting some of the new frameworks and new front-hands with a Drupal Drupal's data exposed over arrest API actually building your website using these techniques will require significant amounts of custom code significant amounts of soft you know software development and a lot of planning and iteration so you should not if there's people out there who seem to think that yeah just has this rest API and core and there's this thing called angular and you just turn them both on and suddenly you have an interactive single-page application website for Drupal that is very very far from the truth this is this is no longer like you know sort of Sputnik moonshot stuff that only the a few developers are working on but it's far from being a like thing that you just turn on and because what we're talking about really is comes down a lot of times to the user experience and the implementation of the front-end I don't think that we'll actually ever get to a place where you just like turn on decoupled mode or something like that because ultimately just like most websites built with Drupal have a custom theme there will be at most websites build with Drupal in fact almost all of them I think that are decoupled will have some customization to the front-end some customization to that contract between the front-end and the back-end and that's that's a lot of work it's not necessarily gonna save you money up front in fact it will probably make your project more complicated if you know from a cost standpoint it only makes sense as a long-term investment and from that standpoint if you want to do this you have to really get buy-in from everybody on your project all the stakeholders have to really think about this and want to do it before it makes sense to do unless you're simply just doing a prototype right there's there's some cool things you might be able to do by prototyping where it's like you know if you have your running website you're not actually changing that you're just setting up a little rest API and trying something out on the side that's kind of fun but if you are looking to do this for your you know for your primary website it is a big project it requires a lot of work the other thing is as we all know Drupal does all these wonderful things for us this is a great the periodic table of modules from amazing labs it's a neat wonderful case of infographic and and research so look there's all these modules there's a hundred of modules that are in use by hundreds of thousands of sites and the thing is that a lot of Drupal modules have to do with how stuff is displayed to the user and once you're no longer using Drupal to display stuff to the user most of these modules or a lot of them anyway kind of come off the table as things that you can utilize and what that means is anything that they were doing for you you're now doing some other way and that some other way probably involves you building it yourself in in your own manner or you know there's there's some stuff you could take advantage of on the front end there are some good plug-and-play JavaScript tools to be able to use but in total you're you're giving up a lot of the stuff you get for free with Drupal when you go into a decoupled architecture and you should really evaluate what you'll be giving up whether you can afford to just let it go or how much work and cost it will be to implement that in a different manner so everything from content translation to previewing to you know there are there are lots and lots of cases where things you know that you're just used to being able to do in Drupal they're no longer present in a decoupled architecture because it's it's customized okay so now I want to get into some specifics which is to talk about five different ways in which people go about decoupling sort of five different decoupled architectures I will and I'll talk through their various use cases and applications and then we'll take some questions from the crowd so the first and probably most popular method for doing decoupled implementation with Drupal is to have some sort of static site generator or static renderer and in this case it's sort of you have Drupal as your CMS and administrators are using that your content editors are using that as per normal and then something else whether that's something that's run once when you're ready to publish or something that can pull from the Drupal back end in real time generates static HTML pages out of the data in Drupal and the benefits here really are that you can just separate the concerns there's some great case studies out there I saw at the Dev Zyner conference in Portland phase two has a wonderful case study about using a front-end library called pattern lab which helps you build with atomic design this principle of building up design libraries and design languages and that's a it's a there's a big huge front-end tool chain for using pattern lab where you install all these node modules everything else on your laptop and you're just pattern labbing your way to things and what you end up with is this really really clean elegant minimal beautiful implementation of your design that is much much more robust and flexible than most Drupal themes from especially from our developer standpoint and then you sort of take your clean elegant minimal implementation design and you can generate just that HTML with your generator there's other tools out there that do this for kitchens has a open source project called Saucier that keep them with their chef theme that's a node.js framework for doing some of the static site generation and so what this does is it allows front-end developers to be unleashed it allows you to have that parallel track statically generated front sites are by definition high performance I mean they're well they they are much there because there's no database queries to be made they're going to be fast they're read only right it's a static site but it also means it's totally secure right there's no way there's no real way if all you have access to is something that's serving HTML documents for you to hack that and this is actually the oldest architecture in the book when it comes to the web there are people that were doing this in like 1995 because they got tired of writing web pages by hand which was how everyone was doing it and they said I'll have a script that takes my you know content from over here in a database and makes the web pages for me haha I won and so static site generation has been around for a long long time and and it's one of the most popular and and and straightforward ways that people are decoupling another way is to have a hybrid approach to decoupling and what this really means is that you are building on top of your existing website a rest API and that's this is a way to you can also prototype so you have your website it's working great maybe there's things you'd like to change about it but for the most part it's doing its job and what you do is you essentially build as an extension to that website the rest API and then you can start to do things with it so you could have a portion of your website be a rich JavaScript application that talks to this API it's not just like doing the normal Drupal call and response kind of page building for full pages it could be talking to this API to generate a really dynamic dashboard for instance or to have a really rich content editing experience or to have you know some other kind of highly interactive capability or it could be that you have this API and it's you know it's serving to power a section of the website that is being built with one of these static site generators or something else like that and this allows you to to sort of get a little bit of the best of both worlds to start because you don't have to think about redoing your whole website you just think about where a decoupled functionality or decoupled capability would be of use to you and and focus on that the the risk here is that you know you're sort of like building a half-breed monolith slash API thing and and if you go very far down this road you may find that you need to refactor more and more but it's an interesting way to get started and certainly there are websites that are built with this in mind from the start so for instance websites where there's a really beautiful kind of interactive normal user experience but like all the login stuff and user profile stuff those are just served directly by Drupal so you're you're saying I want to use a decoupled architecture for a certain set of components but then I want to actually rely on Drupal for another set of components maybe particularly where I'm more concerned with security or something else that's a certainly a valid approach to this architecture another architecture that can be used in conjunction with the hybrid is this notion of the quote-unquote single-page app and this is where a lot of the not just design development on the front end but the functional development on the front end gets very exciting so this is where you have these frameworks that are coming up like angular backbone react and ember and more for building interactive applications on in the front end so you basically are delivering software that's written in JavaScript to the browser it runs in the browser and it does really great stuff and you can do things with this this type of architecture you know requires advanced JavaScript development skills but you can do things this way that just you can't do any other way you can't create a real-time application experience if every time an interaction occurs you have to do a round trip back to the web server this is a way to build real-time application experiences in the browser and typically good real-time application experiences there's a back end right there's a place where stuff is get saved and loaded from Drupal actually makes a wonderful back end for these sorts of things and and this was actually for at Pantheon one of the the first few iterations of our dashboard actually worked this way we had a Drupal website that was fronting for a core API but that Drupal website was mostly just pushing data to a JavaScript application that was driving all the user interface and interactions that's how you create good real-time experiences as I mentioned before there's the whole native mobile app or potentially future internet of things and this is the idea of having your website talk to some embedded application right so an application that's not running in a web browser it's a Android app it's an iOS app it's a smart device in a home it could be sending data to that application it could be receiving data from that application and and that's a great way to interact with all those things because you know they're not gonna like you know you're not gonna mock a user and fake web page submissions and stuff like that to do those interactions you're gonna need an API especially if you want to have multiple different things that are going on one of the things I'll point out to is that like you can you can there there's these architectures that I'm showing you are just examples of the major themes that emerge so for instance there are cases four kitchens did a case study on that I saw where they built a static site for twit.tv it's this week in tech it's very popular podcast so they built a they built a decoupled they used their Saucier library and they built a static site for the for desktop and mobile web and tablet and so forth but they also with the client are working on documenting and exposing the API so that the community around the site can try to build their own applications on top of it which is really interesting it's the idea of well now that we have this API that we are using to drive our website what if we could safely expose this API or some portion of it to our users and see what they want to do with this innovation and that's kind of gets to this like more connected and integrated world where it's not just about delivering web pages it's about building you know kind of integrated systems and certainly the native mobile app universe is one of those particularly because a lot of times when you see people building a website that drives a native mobile app there's also a website for that app and that website is one that people can just come and log into and you might utilize Drupal's capabilities directly to handle like user account management and for the people who are administering the server it's service to go in and say oh like let me make some new content in Drupal and that gets pushed down to all the mobile apps as the latest update those sorts of interactions and tools work quite well where you have actually multiple ways of interacting with the core CMS system whether that's directly to the website or through a native mobile app and finally the last implementation that I'll talk to is the CMS on CMS or to stick with our headless horseman language what I like to call zombie Drupal and so this is where you've decoupled Drupal and the new thing on top of Drupal is more Drupal and that sounds this sounds a little crazy and maybe like you're over and maybe we're going a little bit too into Drupal land with this but it's actually a highly valid architecture and the reason is that you can create a separation of concerns between your your your layers but you don't necessarily need to implement separate technologies so it may be the case that you actually have a lot of Drupal developers and not a lot of front-end developers who are not familiar with Drupal and in fact you can parallel track multiple teams of Drupal developers by again creating the same API contract and it basically maybe even creating usable reusable code as a standard way that your instances will send and receive data from another but because you're able to build with a separation of concerns the tech team can can implement across both paths simultaneously and one of the nice things about having a CMS as the front as the front end is that the CMS has capabilities where the CMS is by nature configurable so you have instances where we have actually a very very high traffic site on Pantheon it's like a top 200 site on the internet and it's built with this type of configuration so there's millions of pages a day and they have a back-end CMS that has like their huge repository of content it's just like a ginormous repository of content it's like it's just like millions and millions and millions of articles and nodes and because they have so much content they'll be really careful of what they do with it they can't just create random views and hope it all works out for the best because once you're standing over like 10 plus million pieces of content you can create queries of death that will bring your site down so easily and that that's a common fear for people with large-scale websites so what they do is they build a highly efficient Drupal application that is just about exposing that content over a REST API and then they build another Drupal application that is a consumer of that API and it handles this way and it handles some caching and it allows them to like try out different things like they can adjust on the front end site oh let me just do a different layout or let me like reconfigure this on showing 10 pieces of content instead of 20 or oh let's go try setting up a new section we do it here and our ability are our we are essentially you know foolproof right we can never really hurt the back end because the back end only speaks over an API which the back end of knows it can serve in a scalable sustainable performant and secure manner and this is the beginning of moving towards a truly distributed microservices kind of architecture where you don't just have a front end and a back end you might have again multiple front ends so you could have your back-end CMS your front-end CMS your mobile app you could have another another back-end service that handles a specialized type of data maybe one that doesn't work so well with your primary type of data you could have another instance that just handles things like authenticated traffic you can integrate third-party services so a lot of people integrate third-party services for comments now as you start to build this type of decoupled services oriented architecture rather than a it's all in one website architecture more possibilities on the internet open up to you now certainly it's quite complex and it takes a lot of work to do but there's a lot of wind to be had in there and that's the reason why everyone is so super excited about it right now and I believe that at this point I'm ready oh that's not quite ready the one of the things to reiterate before we conclude is that this is nothing all of that new here as I mentioned with static site generation that's an architecture that's been around since the beginning of the web a lot of the service-oriented architecture stuff has been around it's just been something that only larger very large companies would do so service oriented architecture is not really new it's just new that people more of the internet public is thinking in these ways and is it being empowered to build in these ways and certainly you know a lot of what we're looking at with the native native mobile apps that's relatively new but the idea of you know building an interface to a site that was consumed by something very different you know I'm glad that flash is really going by the wayside but there are plenty of people from the heyday of flash you know like the mid-auts who built websites where there was a flash front-end and some kind of CMS back-end possibly even early versions of Drupal Drupal 4.5 maybe and so these are all architectures that have been with us for a long time what's changing now is that they're becoming more and more standardized we're getting more and more best practices and the tools to build them are really rapidly evolving and becoming more and more accessible so while this is exciting stuff it's not really new it's more that it's moving from the like vanguard state to the broad early adopter state and that's exciting because that's really been always up to me a core of what the Drupal community is we are early adopters of new technologies on the web that's one of the things that makes the project awesome that's one of the things that keeps us relevant that's one of the things that keeps it fun for us to do so really excited to help you know spread the word about this stuff and hopefully get more people interested in engaging and helping us further develop best practices further develop tools further create more case studies and awareness around the joys of decoupled CMS and at that point now I'm ready to take some questions well Josh that was just fantastic