 We're here to tell tales from the recent past and both disease and discuss our epic task. It was the sunset of Jane Nano on the sunlows of Jimmy Fowle. Had no JS and a D8-facing architecture and a semantic content model. A multinational distributed software team and a workflow that did not throttle. It was the sunset of Jane Nano by the gallon so stout. And I think you will love that for five o'clock on a Tuesday at Triple Con Austin 2014 there's no better. Being such a wonderful audience at our musical session today. For those of you who don't know me, my name's Andrew Berry and I'm an architect at Lullabot. And up here with me on stage is musical genius extraordinaire David Dyers. Dears. These people. I know. Only took months and I still can't get it right. And today we're going to be talking about The Tonight Show. Luckily for us, we still have a keyboard. So The Tonight Show is the longest running television show in history. I mean that like not just in North America, not just in the English speaking world, but in all of the television that's ever been produced. And that's 11,000 episodes of episodic content that's been produced since 1954. And this is The Tonight Show website. It's a responsive, touch friendly, very dynamic website. And when it comes down to it, it's an app. It's more than just a way for documents to be presented on the web. Now for those of us who have been around the building websites for ten or more years, we've really seen the internet take off as this tool for us to share our experiences with one another and with people who are really far away and disparate from ourselves. And this was really important in the design of The Tonight Show website. Because the primary use case for the app is to make these shareable experiences and these shareable moments from the show be able to be watched and viewed and then shared out to people you care about as easily and as quickly as possible. And as we were designing our architecture for the site, whether it was technical or project or some other part of the site, that's what we always came back to to keep us grounded in reality, these concepts of shareable moments. So yeah, here's Drupal, but step back, not really. Drupal is just one component of several different systems that have all been built and tuned to work together to produce what you see in your browser today. So today, David and I, we're going to talk about how we went all the way from a Drupal installation screen to what you can pull up. Now, NBCUniversal is itself the amalgamation of two very large companies. And in fact, a couple of years back, NBCUniversal was bought out by Comcast and together they have something like 136,000 employees. At least that's what Wikipedia told me. So as soon as you start thinking about organizations that large and that big and that many competing ideas and interests, you're probably thinking enterprise software. And at least to me, those words would probably make me think of words like large and complicated and slow and 18 months to anything, even for a project that's already been going for 18 months. But let's take a look at what needs to happen to build a website to relaunch or create a new entertainment talk show today. First of all, they have to choose a host because the host is the cornerstone of figuring out what the creative direction and the content of the show is going to be. So then they have to, once they've chosen a host, figure out who the staff is going to be and start that hiring process and that can take quite a lot of time. And then they have to define the creative direction in concert with the host and actually start defining the segments of the show and the bits of the show. And ideally, all of this needs to happen before any technical work begins because otherwise you're not going to be building a website that's actually useful because it's not going to model what they're trying to create. So even then, if we get all of that in place, it just gets us a website that would mirror the show, a website that isn't necessarily a first-class experience and to be effective and competitive in today's really crazy media entertainment marketplace, the web needs to be a first-class component of the show experience. It's got to be a channel for both unique and repeat content. So in the case of The Tonight Show, all of those prerequisites for the content and the direction of the show, by the middle of December 2013 we had reached a point where we could actually start to build things and start to think about building the website and the apps. Now, for those of you who are familiar with the show or watch the Olympics when they were heavily advertising it, The Tonight Show launched on February 17th, 2014. You throw in some holidays in the middle there and that doesn't give you a lot of time to get a website out. It certainly is in 18 months. And when it came down to it, we had about six weeks. So how were we going to pull this off? Well, before I get into that, I'd like to talk about who was involved because how the project was actually composed of the team members was really important in determining the technical architecture that we went with. So first of all, primary, our main guest for this evening would be NBC Entertainment Digital. And they're responsible for anything and everything that has to do with the NBC television entertainment brand. And so they're building all sorts of tools for all their different television shows. And then there's also NBC, ONTS, their operations and technical support. And there's some of them here watching right now, which is just great. And they're the team behind the Publisher 7 distribution at NBC, which is what they do all of their sort of customizations to integrate with NBC systems and other things. But then there was also Crispin Porter, who was actually the primary contractor for The Tonight Show build-out. And anything that you see which was publicly visible, that was work that they did. So whether it's the website or the apps, they were in charge of looking over their design and care. So then finally we get down to Four Kitchens and Lullabot and we really helped round out the Drupal team. We'd worked together on NBC.com, which at the time was in parallel, but not yet launch development. And so we sort of provided expertise and consulting and so on. And when it came down to it, the sun never set on The Tonight Show team. Not only did we have a complex site to build with a tight timeline, but we were all over the place. And we had to really figure out how to manage that. If you look at this, we're basically covering the whole world as far as east to west. And I remember realizing in the middle of December, this is what we've got to build the site. How are we going to do this? If this project is going to launch on time and have a full set of features, we'll need to structure the project and the architecture of the technology to be non-blocking and dependency-free. So what's our first step in order to figure out how we're actually going to make this happen? Like anything else, we needed to decompose the system. We needed to define what all of the systems were that needed to be built, figure out what their roles and responsibilities were, and then figure out who was the primary expert in each of those systems. So we did a bunch of brainstorming and we came up with all of these topics, from content modeling to video, which in itself is like a very complex item, so it needs to be separated out from your content through to the Drupal side of things, through to the people who needed to actually understand what the show was going to be doing, and then the very technical components of the APIs we would need to implement for the mobile apps and the systems that would actually drive everything, and we knew that we really wanted to have, for lack of a better word, an entertaining front-end, which was going to need a lot of effort, and then of course the mobile apps themselves. So we started through from the source of the content to us as technical architects, and we moved through the entire system to figure out how that content would eventually get to the end user. So our first item ended up being content modeling. This was really, really important, and what I think was interesting about it was that everyone needed to work on it. It needed to be something that everyone had a solid understanding and a solid vocabulary around so that we could communicate with everyone, whether you were a front-end designer or a show producer. And it was about the only item that everyone needed to have total responsibility and to be successful. The API design was handled by David and myself as well as someone from Crispin Porter, and this was where we started to be able to decouple the project structure because we could make it so that the API, for all intents and purposes, was really a responsibility of the tech teams to make sure it was being built right and well, and NBC as an organization cared in the sense that they were going to have to maintain the API and actually live with whatever decisions we made. But when it came down to it, it was more of sort of an oversight and review and long-term thinking versus managing the day-to-day decisions of the API itself. And then we had the actual Drupal or Publisher 7 implementation, which David and myself worked on as well as some other people from both of our companies and a developer from Crispin Porter. And then video, of course, video is always a special case, and so we had someone dedicated to just video who got to run down that rabbit hole for a few weeks. And then friend and an apps, totally Crispin Porter. I have no idea about how they actually work, you know, deep in the code. They just are there. And then that left NBC free to become our show and infrastructure experts without having to worry about all of these other components that needed to happen. As we were working through these slides, David had this great analogy that I just can't do justice, so I'm going to let him give it. So, in a way, this whole process was exactly like winning at Lip Sync Battle, which is a segment on the Jimmy Fallon Tonight show. And the rules of Lip Sync Battle are as follows. Two contestants enter. And they both take turns singing popular songs that they've pre-selected. The opposing team, the opponent, does not know the song that the other person selected. And the goal is to one-up each other, culminating in a final performance. And at the end, Jimmy Fallon always concedes to the other player. So in that way, this is exactly, absolutely, nothing at all like Lip Sync Battle in any way whatsoever. But it is actually a little bit like playing Lip Sync Battle because while you don't know your opponent's song, so we had low visibility to the intent of other teams, which meant we could allow independent duration on other layers of sight, see how that works. You can only control how well we did on a particular team. So you play to your strengths and you really have to go for it. And then it's also this lightly competitive structure, conducive to enabling the other teams to do their best. Basically, everybody's working really hard and doing their very finest work, and that competitive structure just dissolves at the end, and everybody wins. Except for Jimmy who concedes. I'm glad no one had to concede on this project. So where does that leave us? Well, that leaves us with our non-blocking approach, which basically ended up being a decoupled app and web front-end with a services-based Drupal API powering the whole thing. And an abstracted content model that allowed us to both model the show and the elements of the Tonight Show and continuously iterate on it without breaking things as we went through basically week-by-week doing iteration on this six-week project. So this is a standard Drupal site. Content goes in, whether it's from a service like MPX or editors at a keyboard, and in the end views come out or panels comes out or bean or whatever it is that you're using today to make stuff come out. And we're all pretty familiar with this. This is how we've been building Drupal sites for a while now, and it's not that different from Drupal 5 or Drupal 6 build-outs that we may have done. And in this case, we have a lot of anonymous traffic hitting the site, so we've got varnishing caching in front of it just to make sure that the site works. So we throw Akamai in front of that because we really care about making sure that nothing happens and, you know, that helps with geolocation and so on. Yeah, you know, it's like anything else in computer science. Just add another layer of caching and make it better. And what's really interesting about how this played out is this still looks like a standard Drupal setup or a standard PHP setup for that matter. But this is where everything changes because everything we know and hold dear is how you build a site. That's all it is, an API. To the consumers of the API, they don't care about how it's hosted, how it's built, who's running it, or why. They just know that there is documentation that says that they can get the data they need somewhere living in the cloud. And I feel like this level of abstraction is something which is really powerful for what we can do with our projects because it basically enables us to work through the whole web community instead of just Drupal developers as far as site building goes. So, you know, if we're thinking about how content actually gets out to an end user, yeah, we've got this API, and then there's this node and Varnish and Akamai in front of that because, yeah, more caching. And then we have a backbone app which is actually what you get when you run the browser. You've got the first page which comes out of nodes that are fast and snappy, but then all of your future interactions with the site are entirely controlled by backbone. And something else which came out of this which really helped validate our API design is that right now we've got one API client, but pretty quickly we had two. We had the node app and we had the backbone app. And as soon as you start having multiple clients interacting with the same data set, it allows you to verify that your data works the way it's supposed to and that your API is actually usable. So, you're just an end user, and you're like, wow, this is a lot of stuff to go through just to get my Tonight Show videos. It is, but at least it's something entertaining at the end. So, we've built this sort of API-decoupled system that, you know, from a very high-level architecture standpoint allowed us to encapsulate and extract the Drupalisms of the site. But that was just one small part of what made this project work within our tight timeline. And I'm going to hand it over to David to talk about the next entertaining part. Thank you, Andrew. So, yes, Andrew mentioned before, and there were really, there's two components of the site. One was the decoupled cope solution, and the other was the semantic content model. And so, I'm going to explain what I mean by semantic content model in a moment, but I'd like to start with kind of how we got there. So, in a tight deadline situation like this, we felt the best thing that we could do as consultants, as architects, was to unblock the most amount of people to allow all the teams to move forward at once. And the biggest contender for that work was the API. If we developed a good API where we had a shared understanding of what would be coming out of the API, basically define the endpoints and the outputs of the system. And then from there, we could actually work towards making that happen in code on the back end and to ingest that code on the front ends. But we didn't necessarily have to do that work up front, we could just define what was going to come out. And so, we started down that path, but we found that it was quickly very prescriptive and unsustainable. And, you see, it's a bit like Jeopardy, where you are creating the answers to questions that you're going to provide the questions to later. And we found that with the content, with the basic content model that we created, that we, the questions that we could ask to get those answers were very limited. So, they were tied to displays specifically, so the endpoints tended to produce things that were for specific displays on the app, say the Android app or the iOS app, and they were very formulated to those things specifically, or the website. And that's just not great, restful design. It's a very display-centric API with a few concessions for rest. And that led us to this. So, it's pretty close to a blocking workflow and clearly not going to help us succeed, because with our front ends and back ends tightly coupled like that, it reduced our overall reusability of those endpoints. It was a content model that didn't have the long-term flexibility for the editorial team. So, the Tonight Show with Jimmy Fallon, if you've seen before the show launched on the Jimmy Fallon show, it was a very innovative show, and he was constantly working out new bits and new segments that, and he just was flowing with the times, and that's how good late-night TV works. It's very topical. So, tying things into very specific pieces of fields or content just wasn't going to work for editorial at all. So, this type of coupled content model where the elements are composed of things that drive specific displays, well, when change comes along, either at the business level, at the show level, or at the display level, it's going to require a lot of work on the consuming technologies, the node and backbone technologies, but also the back end as well. So, that wasn't something that was going to allow us to work asynchronously and all move forward at once. It was going to require a lot of back and forth, and I can't actually move forward because the endpoint doesn't work for me any longer, and so that kind of blocking workflow was just not going to help us meet that deadline. Very aggressive. So, based on that approach, while we wanted to get the endpoints defined and the outpoints defined to have everybody move forward, we realized we needed to take a step back and rework that content model. And that was really for us the dawn of the semantic content model. So, in a typical Drupal site, it can be very easy to have a page-centric content model, and like the display-centric content model, you might start with the answer. So, I have a page here, an about us page, and I have a listing page, and from those pages, you devise the fields and relationships between those fields and relationships between those pieces of content to create your Drupal content model. It's a page-centric content model, but it has a lot of the same problems. You have something very dangerous driving your content. So, as with the display-centric content model, you have a very tightly coupled solution in a page-centric content model, and neither of these solutions are flexible or sustainable in the way that you want or need for a website that needs to live past its launch. So, the Tonight Show with Jimmy Fallon doesn't exist because it has a website. It has a website because it has a show. It has a property. Why let the website drive the modeling of the business? Ultimately, it's going to be more meaningful for the editorial staff and for NBC Digital to have the show drive the site and the content model. So, that's how we ended up at semantic content modeling, which is going to have us create structures inside the content model that resemble the real-life elements of the business. For the Jimmy Fallon Tonight Show, that means it's going to resemble the segments and the pieces of the Tonight Show that we all know and love. And so, since Drupal wasn't responsible for driving a page, pages at all, it's not responsible for being a website. And because we had this sensitivity, because we started to form those in-point answers and suspected what kinds of questions could we ask to get those answers, we had renewed sensitivity to this display-centric modeling. And because we were both removed from page-centric and had a sensitivity to display-centric modeling, we really set about creating these agnostic and dependency-free semantic content endpoints. One last point about all this, though. With semantic content points, it's really important that you have the right level of resolution. For us, that meant that we were basically having a 10,000-foot view rather than a 100-foot view, because that volatility of content that Jimmy Fallon segments tend to have and he's constantly iterating on a show and trying to improve it and make new funny bits and be topical, modeling it too closely to specific segments like lip-sync battle, which is something that wasn't going to be working for us in the long run. So with that, Eddie Lee from NBC had the fantastic idea that we could build off the smallest element of the Tonight Show. And it's a late-night television show, and the smallest element of a late-night television show, the smallest atomic unit of funny is the joke. That's the big reveal, how about that? Which coincides, actually, perfectly with the mission of the site, which were the shareable moments of creating those shareable moments, those spaces. Like, did you see that thing that happened on the Tonight Show last night? That's a conversation that you have at the water cool the next morning. And in creating that, that's based around jokes. That's based around specific punchlines. That's based around the formation of multiple punchlines. And so, really thinking semantically, we have jokes, and many jokes form up a bit, and many bits form up a segment, which is from commercial to commercial, and many segments form up an episode. Episodes contain appearances from guests, be they musical, political, comedians, actors, actresses, so on and so forth. As a website property, we also have these other supporting elements. However, we have the social media challenge, so Jimmy every Wednesday night has a Twitter challenge, where he has people tweet in to a specific hashtag and reads them over the area. He also has an Instagram challenge and so forth. And then we also have the games, which are multimedia experiences that people can have on their iOS or Android devices or the website. So in practice, taking this idea that we're going to break things down semantically, we ended up with a semantic content model mostly. So what we found, as with anything, AmSolution is going to perhaps come to unwieldiness. So it's a lot like database optimization, which is my love, but too much of it makes things a little bit unwieldy. So we found a multi-layered approach to our content model, actually served us a little bit better and was a little bit easier to work with within the constraints of our time limit. So in practice, we ended up creating entities that weren't semantic, but were building blocks. And these are things like videos, images, carousel items, so on and so forth. Those items got built into the semantic objects. So the semantic objects used these building blocks. Semantic objects were, as previously mentioned, bits, segments, challenges, games, guests. And then our concession. So originally, we had a model that was a display-centric API with a few concessions for rest. What we ended up with was a restful API with a few concessions for display. And then our display-centric concessions, and we first saw a little bit, but it just made it happen. And sometimes you have to make those concessions and in an absolute world, you wouldn't have to, but you also have a deadline, and part of it is meeting that. So we have carousels, block posts, cues of semantic items, image galleries that contain building blocks and semantic items. And all that to the benefit that it gave all of our teams from the developing teams to the QA teams, and that's the multiple multinational development teams. So the apps teams for Android, for iOS, for the website, for the backend, the QA teams, which were in California and India. The editorial teams at NBC, we all had a shared meaningful language that was native not only to the website, but to the show, to the property itself. And that helped us all talk about things and envision where things were going and really have a common language. It also made sense editorially for the long term because this is Drupal as a product, the publisher seven distribution, is a common editorial workflow set of tools that lead to a workflow process for NBC that they are used to supporting and used to engaging with editorially. So now we finally placed our content in the driver's seat and it's driving the property, or so the property is driving the content model, not the website driving the content model. And this leads me to sort of the other element of our approach, which was that the other part of our non-blocking approach, which was our API. So I'll talk briefly about that. So once we have this content model in place, we're able to establish our outs finally and define these elements that were going to allow our multi-platform, multi-team development style to happen independently of each other. We could have a shared agreement about what these things were going to look like with those, both building the Drupal system that was going to spit these things out and building the consuming technologies that were going to take that data and make it into a beautiful website or app experience. This allowed us to develop with reasonable agility and respond to the volatility both from iterations on the front end from editorial's experience with the site and Jimmy Fallon for that matter, but also with our own experiences with bugs and things like that. So it also freed up the front end to really have frequent updates. So interestingly enough, once we had agreed on what these things needed to be, we could create the content and content teams could be entering in that content right away. There wasn't any delay. There wasn't any last-minute rush when one day before the site launched, we had something in dev or staging or production that just wasn't public and everyone rushed to get in content and it was a mad dash and it's four in the morning and bugs are cropping up. That never happened because content teams could be working on the content and created something out. So our product, while it was, you know, actually the API, it was a little bit more than that. It's more than meets the API. So at first glance, you know, we're talking about, well, we have these outs and they're defined and that's great, but we also have our sort of an agreement about how these points are going to work in the future and what the internal structures of the resources that we have. What do images look like? How do we respond to those for responsive websites? What do videos look like? What's the metadata around that? And if we could all come to an agreement about what those things are, we didn't necessarily need to know ahead of time that an image was going to be needed for a guest inside of an episode or that a video was going to be needed for a gallery because we could predict, because we had set that as an agreement amongst ourselves, what that was going to look like was going to use the structures that would be given to them and then simply put in a ticket saying we need this added to this endpoint and we could do that and it all just worked. So in many ways, what we're talking about is making the most available member of your team the most available and that's your system. Your system is actually the most available member of your team. It's not your architects. We go to bed, you know. We go to the bathroom, whatever. We have a number of things that we do but the system is always there. And if you can create an intelligently designed, highly available member of your team, why not? So it could be a person, it could be a spec, in our case it was the system and that proved to be very useful for all of us, especially in this asynchronous workflow and a non-blocking workflow. Andrew has developed a lovely article on how to legally binding your web APIs, which I recommend that you read. How are we doing? Okay. Let's move forward. But it basically allowed us to have a versionless backwards compatible hydrostyle development model where we could all move forward. It was iterative and dependency free. So if the coupled systems need a linchpin, basically something that is highly available that can answer two teams that have questions or need a response or basically don't know how something is going to work, it could be your system. And then that could answer to all those things that are very valuable to us. So the basic concerns of our API were that we needed to provide semantic content, that we needed to provide display content, that it needed to be performant, that it needed to respect permissions and the state of content, whether it was published or not, and also that it deliver agnostic and predictable resources, like the images and videos that I spoke about. What it wasn't concerned with, it wasn't concerned with routing, front-end routing, of course it had Drupal menu routing for the endpoints and if you go to the website as particular page, it wasn't concerned with how it pulled results from the API to make that page. It wasn't concerned with tailoring those results for a specific device that was all decided at the App Lair. And it wasn't concerned with authenticated audience interactions. So these are some of the things that we dealt with specifically and some of the things that we avoided. We also found, you know, it wasn't an API, it's a Poop API. So even if this is based API solution, there are options. So like you could be saying, well you have six weeks, why don't you just site build this? Why don't you just make a bunch of views, content types, and then spit it out in services? That would have been extremely fast. Like, I can do that by two, you know? Two p.m. That's done. Okay, let's move on. Next project, SLAM. But the problem is, is when you introduce iteration into that model. So for an asynchronously distributed team, on the weekends, late at night, early in the morning, at all times. And the architects who needed to review that code and understand what was going on and basically review that for any problems with Drupal would be staring at a bunch of features code, you know. We had developed, for mbc.com we developed an API that was PHP object oriented based. And it allowed us to really bury a lot of the deep Drupalisms, deep into the parent classes and allow the implementing classes to be a lot simpler and a lot cleaner. That meant that we were looking at maybe one line change in an implementing class, or an implementing function, versus 150 lines of change features code. And that's going to review a lot cleaner and a lot faster in an asynchronous workflow. So we found that particular process to be really helpful in getting things out the door. It also let us leverage some existing PHP object oriented resources that we had who weren't Drupal experts. And they actually didn't need to be, because we had implemented all the deep Drupal stuff really down below. And so they were able to kind of ramp up on that stuff as they needed it. They could pull in specific functions or work with the parent classes or overriding classes to touch that Drupal stuff. But for the most part, implementing classes were six lines of code or something like that with a few query specifics. So it turned out to be quite easy for non Drupal experts to work within a complex Drupal framework to get a services solution out and be enabling their app consumers or their website consumers. So the API in practice, basically we had a few structured calls and it looked, we had display centric calls which kind of had some query parameters. And then we had some semantic calls which looked a bit more like good restful calls. So those are some of the concessions we made and so to a semantic to a display centric sorry, not to display centric but to a display content type, a call might look like this. So we have episodes ID 15. The result we get back would be something like this. So you can see here and you can see the inner details of the image. And so this is like a signature that we sort of came upon for images and then we reuse that every time we had images and you could have multiple images and they all kind of look the same. And that helped out with the implementing teams as I mentioned before. For semantic resource here's a call to a semantic resource and it's going to look very similar. You can see the object image is repeated here and it's just JSON coming out the back end. I wouldn't want to leave you with the idea that this is all a rosy picture though. There are some challenges around Drupal as a content provider. So it's not a site. So the things you're used to getting for free in Drupal might not be there. You need to understand what your solutions are for routing. You need to think about the things that Drupal typically gives you. It's going to give you some caching. Do you need additional caching on your front end like we did? Yeah you probably do as the answer. CDNs are going to become interesting. You know we have great CDN solutions like the CDN module for Drupal. But when you're serving that content out that never hits Drupal as a site you have to kind of figure out well what are the addresses need to be, how are we going to figure this out for region and so on and so forth. Probably the biggest one that's going to need a lot of training is your editorial teams are going to experience a disconnect because they don't have a one-to-one connection between a form where they enter in content in those fields, save it and see a web page after that. There's a whole site previewing system that Drupal just has by default that you aren't going to have in a decoupled system. So that is definitely the biggest disconnect and they need to know that the content that they're entering in is going to be used on apps. It's going to look like this. It's going to have this interpretation. It's going to look like this on the website and they just kind of need an overview of that and basically to understand that when they're entering content before any of this stuff is even implemented, they're going to see something that might look quite different than what actually shows up on the website. Or you need to develop a site previewing situation so there's another concern. And that leads us to really the more you know section. So if we had to do it all again there's a couple things we kind of thought that we could do a little bit better. So really don't forget that site previewing experience. I sort of went on because it is a bit of a problem. You really need to think through what you're going to do for a decoupled solution and how that's going to be solved. So we definitely would be thinking about that immediately as the project was starting. Probably in my experience if Drupal is not providing a site experience for somebody maybe you can issue a soup to nuts stuff like media is great. But actually I don't need any display functionality of media so maybe I don't use media maybe I use a simpler token based solution when I'm embedding media type content into body fields. And then I think that both of us agree we'd probably make even less concessions for display. It's not only irksome from an architecture kind of viewpoint but it does make the system overall less sustainable and I think the objects could be cleaner. So sticking to your guns on that is going to cost development time but in the long run it's going to make a more sustainable solution. Which brings us to We made it. Yeah. So it's kind of crazy like here we've talked about everything we did but I haven't answered the big question. Did we actually launch the website or not? Did this happen on time? Well the answer is yes. We got the website to everywhere and anywhere it launched first week of February and it just sort of happened and it's kind of amazing when you think about it usually you make that estimate like is it possible or not and in the software world we get that wrong so often and even if it's just wrong by that said you know that's considered really good and the fact that we had something out and to the public and with real content in it by that first launch was at least to me really exciting and kind of amazing and the timeline actually revealed something pretty interesting as well. Yes. So what we saw actually is that you know we had this really aggressive timeline so we had to do a decoupled solution that would allow separate teams to act at their best expertise and basically move forward as quickly as possible together in lockstep and that process then gave us a pretty strongly asynchronous workflow which fed back into being able to iterate faster and doing more decoupled development and improving that model and so it was this nice synergy between these two which is allowing us to you know the analogy of rolling the boulder up the hill and it finally tips over and then it just speeds on through and it happens more quickly than you even ever imagined. Yeah and we definitely succeeded at sort of having the system as the architect like I totally was out of the office the week the site launched which is you know also sort of unheard of in a lot of web projects and really designing the system as the architect allowed the front-end team who was working on different time zones or different hours entirely to actually make assumptions about what we were going to give them before they'd even asked us yet which is something which you can really use to speed up and make your process work well in parallel. Something else which I definitely sort of picked up at the end of the project was we were figuring out how we were going to build the site in the first place. Decoupling by that point had certainly been the topic of a lot of Drupal cons, a lot of web conferences, a lot you know just the web industry was thinking about decoupled content stacks and it's not like this is a brand new idea. There have been decoupled systems for at least 10 or 15 years now but prior to this project I had always when evaluating a new project early on assumed that it either took one of two things to make it worth decoupling a project. That it either took extraordinary content requirements like a recipe database with millions of recipes. That's going to need a recipe server and a recipe API just so you're not breaking your website under the weight of that. Or you needed to have a really wide number of channels that you were publishing your content out into. I figured if you had either one of those two scenarios or both at the same time then you had to go decoupled. It was the only way to succeed. The summary was that decoupled solutions were for content longevity and not for any other real reason. But after seeing what happened on this project I've come to realize that a decoupled architecture is just a better and more human way to work. It's really interesting to me that like we had people who didn't know the site had launched to the public because all they were doing was working on writing APIs and getting those out there and yes they were ready middle of January and it made no difference that the public was consuming them first week of February. It just was work that was happening and we've all been on these crazy projects where content is putting in content the night before and QA is doing all kinds of regression testing and developers are just doing what they can to meet the deadline and you're putting in 18 hour days and that didn't happen in the same way. What really happened was that the project launch stresses were decoupled by teams as well and so each team had their own sort of mini launch I could say at various points in the project but they weren't dependent on one another and so it really allowed our team to just sort of focus on getting things done and not focus on what needed to happen and yeah I now look at these sorts of projects as why should we do this as a full stack why not decouple it it's going to take a lot to convince me that I shouldn't do a decoupled website for even my own personal stuff now because it just seems to make sense and I think by sort of forcing ourselves to work under this really tight timeline it really inspired everything that we learned out of this and without those constraints you know it probably would have ended up being just yet another Drupal site built with views and panels and fields and it would have been great but it wouldn't have been what we have today so that brings us to the end of at least what we wanted to explicitly talk about for anyone who's been here and just wants to evaluate the session please go to the schedule and give us what you would mean a lot yeah it would really touch our hearts and we'll leave it with some questions we've got about 15 minutes left according to the schedule and for anyone who's worked on decoupled sites or just has interesting thoughts I would love to hear them yes that's formally a cue hey guys Chris Herring from NBCU ONTS hey nice to meet you likewise use this as an example internally to just highlight you know how successful a project can be when given a deadline the one thing that's sort of never been clear to me and you guys didn't really talk about it so I'm interested to get some inside knowledge on this really is like what was the project management process like across all of those different teams and companies was there were you guys aligning iterations were you just each company was doing their own iterations was there a scrum of scrums that happened regularly what was the dealer yeah I felt like we haven't talked about this but yeah I mean I felt like their CBB was running a scrum type process or an agile type process with NBC but I felt like the teams operated largely independently and it still worked because of this like asynchronous workflow so you could understand how that may not always happen right yeah I think the thing so what was the magic sauce there is what I'm trying to figure out there wasn't enough time to have scrum of scrums or you know these sorts of meetings and because it was such a short timeline there wasn't the space for the project code and architecture to grow to where it needed that amount of project management so because we had so many small decoupled systems yeah within that small period of time they could all sort of focus on doing their own thing and I think the other thing which was really important is that our main discussion points between the teams were not scrums they were the API and the content model and so by forcing ourselves to discuss like you know in those terms any of the meetings we had were already very focused whether it was we need this extra bit of data or oh wait we got to think about responsive images or whatever it was I think that I actually think they'll loosely just go back to the lip sync but the loosely competitive structure of having separate teams working on different aspects of it was very useful like because if your failures block other teams and that's a bad feeling it's sort of like you know live up to the moment kind of scrum but that was effective in this project I hear you and I'm totally impressed I just it definitely takes a leap of faith on the business side to agree that we're just going to hope that this works out without having everything totally planned out I mean ultimately someone was accountable like yeah cpp was contracted for it so yeah the teams also weren't totally isolated like cpp had someone doing Drupal work you know we did a little bit of work on the front hem just sort of you know providing some eyes and some code review and so on you know NBC had internal like developers helping out so like because we have that little bit of cross-pollination it helped to keep the communication in line cool thank you congrats again guys thank you so you near the end there you talked about why wouldn't you do this for any project and the main thing that I think of is like you know in the traditional Drupal world we have you know our Drupal site and we engineer like how does the content model work and how do content creators get the stuff in and then we engineer how that stuff gets displayed on the other side but now we've got this back end system and this front end system so we got to basically do the whole process twice how do we get it in and out of each system is it not then twice as much work overall even though you're splitting it between multiple teams isn't it effectively twice as much hours spent on the project I don't I definitely for projects of this scale with this number of developers I wouldn't say so you're like you know a one person shop it might be a harder sell to do I think the real thing to keep in mind is that we actually are rebuilding things in Drupal anyways when you think about it like you've got your content types which are your fields and so on and then you're building a view and that's really just transforming your content into some intermediary format and then you're embedding that with panels or displaying it with CSS and so on you know if you replace a lot of those middle steps with writing an API it might be a bit more complicated to think through but then at the end you get the ability to do things like totally change your front end without having to worry about breaking the Drupal site which is something we run into all the time where like someone starts modifying the content model to match whatever it is today and then you have to spend three weeks updating all the views and panels and custom code to work with it okay I agree so so then you you talked about the benefits of decoupling things means that there's fewer dependencies but then early on in the project with the Drupal of putting the API are you doing because things aren't really finalized in Drupal yet are you have like a mock output of the API where this endpoint is basically just showing this static file implementing teams I think ended up doing sort of mocked versions of content coming out of the system before it was available so yeah our initial we actually wrote the API before we implemented it as documentation and we used this need tool from apiary which basically you write and mark down and then it includes syntax for the HTTP requests and responses and so it gives you really basic stubs for like an individual guest would be really easy to do at the time we ran into trouble with listing queries because then you would end up having to like actually type out ten responses ten items or copy and paste and so on but some sort of stubbing is you know I think really important to make this work it's great thanks hey guys Eric Brown from St. Louis, Missouri hi I have two quick questions one regarding previewing did you guys ever have points where your content creators wanted to like actually preview how the content they were going to be creating looked in the various client situations? absolutely yeah and almost right away it's definitely something that like I said if we were going to do this again that would have been an immediate concern we did work out a solution where content from Drupal basically that was unpublished could be published and viewed with a previewed node system node.js system so they were able to do that eventually and absolutely they wanted that right away and anybody who ever does this will want that so don't ever like leave it to the last moment basically and then second question technically I noticed that when you showed like the response from the API there wasn't much Drupalism in the data so can you talk about what work you did to kind of strip out the Drupal you know all the hierarchy of data yeah so like because so we use services but then we have a module called publisher API it actually started out as NBC API and then we made it generic so we could steal it for tonight show worked out well that way but we weren't using views or anything which meant that we weren't getting default fields like we weren't undoing what Drupal was giving us we were opting into what we wanted to send out and one of our our design decisions early on we were designing the API was exactly talking about we didn't want to think about Drupalism because that made it easy for us as the Drupal architects to be lazy we didn't want our like if you're encoding Drupalism into the API then you're assuming that the consumers of that API understand Drupal and that's just not cool so we really sort of ended up with a system where you know the most Drupal in the API code is really entity field query and database queries and there's a little bit we've got some caching in place at the sort of object response level but everything else from that is just like get the data you need make it match the docs please yeah most of the mechanics of it rely on an abstraction on top of dbtng and also yeah the caching layer and dfq sometimes to assemble lists and is the API like is it publicly available or is that strictly locked down to the client? it is not no it's not yet so you don't have to it's something we've been meaning to talk about okay thanks guys sure thank you anything else? hey guys I know I worked on the project I'm not trying to be a troll our man on video please give a random applause to this guy I do have a question though because I was pretty isolated from a lot of the implementation when you hear about these decoupled projects the fighting words that usually start are what about SEO when you have these magical JavaScript frontends that render how was that handled? can you guys speak to that at all? and we're out of time again I'm sorry actually like it was handled that's why Node existed so anything that was static HTML was coming out from Node and so I don't know the stats but well I don't know the current stats but it used to be something ridiculous like 99% of the traffic was backbone hitting the API directly and then basically Google just crawls the site through the Node system the neat thing is I don't know if they actually did this but I know we talked about the reason they used Node was so they could reuse some of the backbone code for displaying the site so it would actually be the same I think they did it that way I think that's true they said we had so little visibility to the Node site it was interesting but yeah I think they did we did have routing in URLs becomes really difficult I think with a lot if you're not thinking about that on your site and it was kind of refreshing to not even have to think about path auto or anything like that on the Drupal side but it's still difficult or still a problem that needs to be solved we just got to say hey Crispin Porter you get to do this awesome thanks anything else? thank you very much guys goodnight Austin Texas wherever you are