 Thanks for coming to forecasting innovation weather.com's emerging technology story So by way of introduction for those of you in the room who don't know me I'm Jeremy Dickens. I'm the technical lead on the CMS team with the weather company known to many people as weather.com I've been with TWC for two years I have been working in Drupal for eight We're we're also now IBM so I guess I'm big blue, which is a little odd, but Fortunately, I'm joined by my better half Matt Davis is my name. I'm a lead Drupal architect at media current I've been working at media current for about three years now And also working on the weather company sites for about three years as well So the obligatory agenda slide, what are we going to be talking about? What is this all about anyway? We have our fancy Roman numerals to show that we have class But really this is mostly going to be a little bit of a story time From the two of us talking about what our companies have done in terms of you know How we've pushed technology forward. I've been a little bit uncomfortable with the subject about like classifying myself as an innovator I think that's fair It's also fair when people say look at all the crap you've done. I'm like, well, yes I guess we have so we're gonna talk a little bit about what innovation is and we're gonna talk about the three major projects where we've That we've worked on that have pushed things forward significantly in our opinion and then we're gonna kind of wrap things up about what it what it means to try to innovate in Today's world right so to kick it off. We're gonna start with an introduction to innovation And as with all good introductions, we'll start by defining our terms So what is innovation to innovate is to make changes in something established? especially by introducing new methods ideas or products in Ovation, I don't do voices Which is awesome, right? I mean so how do I innovate I want to innovate don't you want to innovate you want to innovate? I see you yeah, he's innovating right now as we speak So, you know, you but there's some questions around that right like okay, that's great We know what it is, but how do we do it? Do I have just like get struck by an idea like you know the bolt out of the proverbial blue or is it like a process? Can I like get the innovation checklist and just start going down and you know marking things off as I accomplish them? And and even if it is based on like some you know Eureka moment How do I follow through on that idea in a way where you know? I can conquer the risk that come along with it face those challenges in order to take that idea into something that's in production So what we're gonna be doing today is really just kind of telling a story a Story of innovation. Hopefully it won't turn into a grandpa Simpson rambling story. It's possible though But it will be a story of Risks, which will try to be pretty honest about the kind of risks that we encountered During this innovation process, but ultimately it's also a story of rewards And and we'll be happy to share the rewards with you Well, some of them So so we'll talk first about progressive decoupling and this is the story of the Drupal 7 weather comm site So by way of background we at the weather company weather calm the weather channel if we have what I think is it's fair to say is a pretty weighty mission statement where our core mission is to deliver Data to people in a timely and accurate manner that can potentially save their lives at very least it helps them plan their day You know, this is thing important stuff to know. What's the weather gonna be like today? Do I need a jacket? Do I need an umbrella? Is there a tornado approaching? These are things that that We consider our core mission That actually drives some pretty significant technical requirements in order to accomplish So we have data oriented concerns. That's that's data looking concerned Yeah, yeah, okay Good. So weather data is highly dynamic in nature. It changes frequently, right? On top of that is highly localized. We have there are places in the world where you know, you can be Well, it probably today you can be in One spot and be getting poured on and then be five minutes away and it could be just overcast or maybe even sunny Exactly Florida for anybody who's listening later This data is also not some subset, you know, we're not just looking at the greater Atlanta area or New York City This data is worldwide in scope and we have customers around the world that depend on this data And then from sort of a more prosaic technical side that data has to be sent and consumed by people in all manner of devices So we call it weather calm, but that also means like your mobile web device It can mean the mobile apps. It can be people on 2g in in areas where the internet infrastructure is not as good as As in the rest of the world. So that has to be a consideration Then as an organization, we have certain team oriented concerns that drove the requirements where we had a large existing and very competent JavaScript team that was Engaged in producing the code that was required to service some of this data And then we had content teams producing videos and and articles talking about weather talking about science Talking about the latest weather event giving news breaking news at the moment that it happens that are around the world Both of those teams have huge velocity requirements. They can't Wait on, you know a six hour code deploy window They have to be able to make their changes and publish their content right now. Oh, and then there's this Which I'm sure nobody else in this room has ever had to worry about these concerns, right? Okay good so Those challenges overall prompted a specific approach Involving Drupal that really at the time wasn't considered. I think media current Started building the we went back and looked at the git logs. The first commits were from the summer of 2013 We launched live in November of 2014 by way of pointing out that the Dries's famous blog post about the future of decoupled Drupal where he apparently coined the phrase progressive decoupling That blog post wasn't put out until de september of 2015 nearly a year after we'd been in production So There are other presentations that have been made at past Drupal cons about kind of deep diving the architecture and what it is But for those of you that haven't seen those Basically, we have Drupal and angular so Drupal is providing this highly cashable markup It's got integrated workflows for managing some of that markup, you know like page management But also editorial workflows It's this source of the source of record for the content that's created on it and the configuration for the individual Components on the page, but it connects to some data stores externally. We might get into later But then the front-end team, you know, there's angular which was even at the time well known It was the I think the leader in the space at the time that we launched It's able to deliver the dynamic content rendering it on the client side So we don't have to save a rendered html page for every single of the millions look at millions of locations that we have Data points for and for the most part no Drupal necessary for them. That's going to be a key point as we go on so Did we did we meet those goals? Do we hit those? Those challenges so we have the highly dynamic data that's solved by a combination of ESI and angular Localized check same thing being able to get that worldwide got it Multiple consumers yet. We have this external data store so we can Create our content saved in the Drupal database gets pushed out to the data store that you know The iOS app can read or any other sort of like, you know, I think there's a Windows Application that reads in this content. So we got that one. That's great So then our team Again our existing JavaScript team not only did they get the framework of choice at the time They didn't need to learn a lick of Drupal Mostly mostly a little bit of form API never hurt anybody Our content teams, you know, they got Drupal's Content editing abilities great, you know, it trained them on how to use Drupal as a content editing platform Put a few tweaks in here and there got it Job script team high velocity. They can make the changes their modules. No big deal content team They can just keep shucking along like Drupal content editors fantastic But one of the key points in all of this is that the driving force behind all of this innovation That led us to create this progressively decoupled architecture before the term even existed Was these specific business requirements? We weren't just out in a field trying to dream up something new for its own sake. It was always driven by these goals Yeah, I mean just by way of of Example our content team has Pretty much a 24-7 requirement. They have to be able to get into Drupal and make their editorial changes So like long deploy windows are right out. So, you know, we go through this we get it launched It's it's up and running. It's in production. We keep iterating We keep moving and anytime you build a large software project, you know, you know You're gonna surface some of those unknown unknowns and this slide is really just um, you know Imagine the ominous music in the background. This is the Dunham right of our presentation. So keep this in mind. He'll be back Meanwhile in San Francisco, so we're gonna take a brief detour now over to San Francisco for the weather underground project So as Jeremy mentioned Weather comm had launched in 2014 November. It was humming along. They were creating tons of JavaScript components over there The platform was really successful And what the company began looking at was migrating its other properties onto this same Drupal platform And this process began in the oh before I get into that though So it's a little bit about some of our intentions when we created this platform in the first place From the get-go we were hoping to create something that would be JavaScript Framework agnostic because we knew that there was a lot of velocity in the JavaScript world and the JavaScript developers like to be able to play with different kinds of tools and the The tool of the moment can change much more rapidly than we might be able to accommodate But at the time there was a lot of consensus around the internal team at the at weather.com around Angular 1 and so we ended up just sprinting full steam ahead with Angular 1 and in the long run over You know after a over a year in production What we ended up with was a platform where our Progressively decoupled model ended up being actually more tightly coupled between Drupal and Angular 1 than we really would have liked And this was a problem in the long run because even though Angular was mature Like I've mentioned the ecosystem in the JavaScript world is moving really really quickly And there were problems that in Angular 1's own innovation story They were surfacing their unknown unknowns as well Things like components and taking advantage of a virtual DOM Weren't possible in Angular 1, but those problems were being solved and addressed in other ways in other kinds of frameworks So when we came to the weather underground Towards the end of 2015 and began talking to them about migrating them on to this platform One of their first requests was we don't want to build this in Angular 1 We really want to be looking at the more innovative new frameworks that are coming out and specifically They were really interested in exploring Angular 2, which if you're not familiar It's the it's like the difference between Drupal 7 and Drupal 8. It's a ground-up rewrite totally different frameworks So we began doing this investigation into what it would take both to Turn our platform back to being JavaScript framework agnostic and into implementing Angular 2 And as it turned out when we started this process, Angular 2 was still in an alpha state And we ended up launching our first Angular 2 pages on the weather underground site in April of 2016 When it was still in a beta state now I don't know how many people in this room have followed the Angular 2 Release story, but it came with breaking change after breaking change after breaking change So we had stuff in production Many many many breaking changes before the official release of Angular 2 and that meant we paid a lot of bleeding edge tax refactoring our components and refactoring whole core pieces of our architecture and how you can Do things like dynamically bootstrap components Into a single lap when you have disparate pieces of your page there and you're too So we paid a lot of that tax But the other side of that story is that because we were early adopters We were able to form really close relationships With the core Angular team at Google and they were actually really interested in our use case Because this progressively decoupled kind of model wasn't how they were originally thinking about the framework being used So we ended up actually helping to influence the possibilities of where Angular itself was going By being involved that early on And ultimately for reasons we'll get into in a little while Whether underground decided to pivot to going fully decoupled and building on top of the Angular Isomorphic story called Angular Universal meaning it has server side and client side rendering Angular And Drupal just serving pieces of data restfully But what was key about that is that because we had those relationships already that pivot was relatively painless We already knew the people and had relationships with the people who were writing Angular Universal and could literally say Hey Patrick JS come down to the weather underground office and let's hack on this for a few hours and make a proof-of-concept in the matter of days and Another big thing that came out of this kind of innovation story is this Drupal 8 module that you can download today called decouple blocks This was built from the ground up in Drupal 8 to be a JavaScript framework agnostic There are currently implementations in Angular react and view And actually this module is also looking for a co-maintainer as well to help implement other frameworks All right So here we kind of get the scene shifts back to weather calm and and things aren't so great those Those unknown unknowns. Well, we we have surfaced them. This is sort of the Empire Strikes Back episode of our story And we're gonna be honest about the things that that we had found in that in that model So so one of the big problems that we ran into as we scaled this system out I mean, it's worth noting our goal that we mentioned earlier was to really let the JavaScript developers have their own independent velocity and Man, they did they took advantage of it and created hundreds of these components and they were being placed in various ways on different Drupal pages. Well, all of the dependency management of that was being handled by Drupal itself So in our platform, we had actually written a whole bunch of custom code in Drupal 7 to manage where different JavaScript assets were needed on any given page and take advantage of Drupal's aggregation to try to bundle those up And keep our performance down now This is problematic if you're familiar with how most of the JavaScript world works because There are lots of really cool ways if you're building a JavaScript app that you can get your sizes of your bundles down things like minification uglification Bundling and then the big one is tree shaking where you can actually shake out all the stuff in a framework that you're not Using to really get your bundle size down now tree shaking is especially important in the Angular 2 story Because it's a huge monolithic framework that if you don't if you can't take advantage of tree shaking You're shipping over a meg just for the platform itself So we knew we wanted to be able to take care of tree shaking But you don't want PHP to be trying to do something like that. It's huge. That's a huge problem space It's not even worth diving into to try to make PHP figure out which of your specific JavaScript functions are being called So this was a big problem that we kept banging our head against that we couldn't have foreseen going into this and then you know talking about velocity so It turned out that yes Well, they were very very happy and very very fast at being able to deliver these modules and create these modules on the front And you know it became a problem that they wanted to go to A different framework or go to angular 1.5 or angular 2. Well, there was a lot of Drupal code invested Investment time needed to do that and our team just didn't have the bandwidth and we became a blocker for them so and even Them putting things on the page that you know might not work in the way that Drupal might want them Would require code reviews on our side. So that's actually the third point on the slide Honestly Philosophically JavaScript should be able to have its own guardrails Those guys should know what JavaScript does and should be able to do that They shouldn't have to worry about breaking Drupal if they do something that Drupal kind of just doesn't like Then we ran into some infrastructure issues Obviously with the way that D7 site works and the way that the traffic that we have to handle We had a complicated caching model And on top of that we had gone with certain caching vendors that you know Well, what if the business decides we need to move to you know a different CDN? That's going to be a problem because we're built to use a particular vendors ESI model Another thing a side effect to the JavaScript aggregation is that because there were so many different Pieces of JavaScript being loaded on so many different pages We had a problem with the sheer number of JavaScript aggregates that were being put onto the file system And I had don't know of anybody else. No one else has ever come to me and said man We've got too many aggregates on our file system Drupal Drupal has a default setting to keep 30 days worth They don't expose that in the UI. It's just there. I don't know anybody else that's ever had to go in and Say hey, I don't need to Kate 48 hours worth So that became a problem for the record the Gluster file system does not like it when you have 50,000 JavaScript files in a single directory. Yeah, it doesn't doesn't play nice Data consistency issues between Drupal as you know the system of record plus the external system just as another example when you have Thousands and thousands of thousands of nodes of article content on your site and they need to be scrubbed to change any HTTP string to an HTTPS string. That's bad enough when you have to push that to an external data store at the same time that's Not something you want to get into And then, you know multi-headed Drupal 7 having 8 to 12 web heads behind, you know your load balancer Talking to one database Maybe not such a great idea. You are gonna run into some problems that does get painful Let me tell you so these are things we were we were able to mostly mitigate these but it was never like clean It was never great. So it certainly made us look at oh, we didn't realize this was going to happen and Have to try to come back on the back end and spend a lot of development time trying to fix all of these various issues Which brings us to the API first initiative and our final area of innovation And the premise this a little bit Those of you some of you may have already kind of read into this the implication that yes Weather calm and whether underground both ultimately made the decision to go fully decoupled in the long run But some of what I think it's important to emphasize here is that that's not To say that progressive decoupling can't serve really useful purposes I think there are lots of good use cases for it and a lot of the problems that we surfaced We're due to the very scale that we were operating on So as we dive into kind of the fully decoupled story We don't want you guys to have the impression that progressive decoupled is not ever the right route to go Actually, there's lots of good reasons to do that But the full decoupling story as we kind of alluded to earlier it started with who once there was kind of decided That we really were we're getting exhausted by these pain points. We were surfacing in the progressive decoupling realm We looked to who first whether underground Because we knew that we had very strong ties back to the angular team And like I said, we literally could send Patrick JS a message and say hey come hang out with us at the office for a few hours And let's look at what a proof of concept of this would would would look like So we were able to really quickly get this spun up on the weather underground side So What it's come down to from where we're taking things here, you know as Drupal developers and where we are in sort of this new next-generation world is that we're gonna provide interfaces and those are gonna be editorial interfaces configuration interfaces But it's not just to our content teams or our our page managers that make you know Put the data on the on the page to be consumed It's also for potentially machines reading that data as well and making decisions about what microservices to include What other systems to call what modifications might be need to be made on those records? So what we're doing is we're really embracing using some already defined standards Like Json API for our document model Using Json schema to do our validation of that model and even maybe some cool things that we'll get into and then open API or swagger to to document those APIs and Really give both the humans developing things against them and even machines that might need to interface them with them a good understanding of what these APIs do So what it it just so happens and we started realizing this last year in New Orleans that the Requirements that we're getting now as far as driving forward just happened to dovetail really nicely with where the whole decoupling conversation in Drupal has gone since we started and it was Not a thing kind of a thing a few people were doing it to now It's a key question that everyone keeps asking over the course of you know this conference So we're putting these up there highlighting that there is an API first initiative Where they're doing a ton of great work Implementing these technologies on the Drupal side Mateo is doing his Json API module. We're hoping to work really closely with him and you know the We just got the open API space to be able to implement swagger on the Drupal side Scamata is very interesting if you're getting into this or looking at it because it also sort of acts as this helper piece with Json schemas and swagger, so we're really excited about the fact that we're driving forward into the space where everybody's kind of Starting to coalesce and push the technology forward But of course we're going even further than that too because we are innovators And there are specific things that we're trying to push even further than where we're hearing a lot of the Drupal community Talking right now a big one that I'm really passionate about is the editorial interfaces And what we're looking at with this project now is for some of our key Editorial interfaces. We're actually going to be decoupling those as well and building single-page JavaScript apps To guide those along now. What's exciting about that from my perspective is that we're going to be using Json API So that all of these different systems that are interacting with Drupal They don't have to we don't have to care where the source of all of these things are because to us and to whatever other systems are Consuming these apis. It's all just Json API all the way out there Sure, yeah, I mean the fact that actually I think the one that's really neat is the one above it so being able to take in a Json schema document potentially and Your custom entity type automatically gets the fields that are defined on that Json schema That again a machine another system could be generating those given, you know, some pretty complicated workflows That that is a use case that is certainly out there that you know I think would pay big dividends in Drupal in the long run And again Drupal being able to talk to other microservices and having other microservices Talk to it to be able to you know, we can push configuration to them They can tell us about their status about their notifications and then I'll finally this whole concept of being technology Agnostic Matt, I'll let you take which it really comes back to that point that I was saying that because we have all these different Systems that are all the glue that's tying them all together is this Structure of Json API so that at any given one of those systems if we wanted to switch it out with something else We could because we know exactly what our data models are how they're going to be structured And that's what's tying everything together So it gives us a much broader ability to be agnostic to the specific ways we implement things It's worth noting about this slide that each one of these comes with buckets full of unknown unknowns that we haven't even Dreamed up yet. You know, this is being a little blue skies So We're already I'm already looking at these for a man. That sounds so exciting and cool. Oh god Well, this is the next example of those icebergs where we could see the top when we know some of the problems But then there's a whole we know that there's this whole other set of problems that we can't even fully realize yet Right so let's wrap up shall we so one of the things about Innovating and being innovative I guess, you know as well What does it get me as a company like what does it get me as was it get my team to be innovative? And just from the perspective that that we have with IBM and TWC I mean, it's pretty easy to see that you know success really does breed success when you Have taken on a seemingly impossible task and been able to solve it That really does a lot for making you feel comfortable taking on that next big challenge And when you have those little god moments, you're like no, I'm not okay. It's all right. We've done this before we know the drill From an organization when you see that your organization is innovating or that your team is innovating or that a team That you work with is innovating it helps motivate your team and the rest of the teams to continue pushing forward I mean nothing makes you feel better than even being next to somebody who's like Really just knocking it out of the park they can they can do wonders for your self-esteem and your motivation levels I mean anybody who's been to a Drupal con before knows that coming here and being around smart people You come away feeling really good about your work and your life, you know most of the time But it is it's something that your entire organization learns that that it gets this motivational sense from it and You know to that again when you're in the room I've always said that I like to be put myself in the room with the smartest people I don't think I'm the smartest person in the room by far But when you get in that situation where you are a thought leader or you're perceived as a thought leader You end up being around other thought leaders and what that actually gives you is this great opportunity to you know bounce ideas off of each Other or collaborate with them directly or indirectly you can see where maybe they've made mistakes Where maybe they've taken a slightly different approach you can get Eureka moments from seeing what they're doing They might have gone east and you're going southeast and then you realize that you kind of went around the mountain two different ways And you realize there's a whole different mountain, but now you know you can kind of do it So I think that's really important and you know getting into how we've partnered like with media current It's been great because that is how what our relationships like and I think when you come to a Drupal con That's what it's like is your look at what everybody's doing and it makes you feel good And it makes you feel confident that you can take these challenges on and you you can actually succeed at them And perhaps also see lightning snow And as a as someone working for a Drupal agency as well, there's tons of benefits that we get not just raining money What one of the things is that as we establish ourselves as you know being at the forefront for example of working with angular That attracts developers who are interested in ways To combine Drupal and Angular that want to work for media current because they see us as helping to lead the path there Obviously, we you know, we've produced a lot of material in terms of blogs and webinars and videos That can have marketing value and drive people back to our site who are curious about all the things that media current does And ultimately, you know, that's that can be really appealing to clients who are trying to figure out similar problems We've already wrapped our head around and been at the forefront of solving All right, so this one's also a little weird because it will advise for innovators Yeah, look, we're struggling for headlines at this point. You're just lucky. You've got slides guys. I promise So just some it made it made Matt and I like have some discussions about maybe what we've learned from all of this work And what you know kind of as technologists What are the things that we might say to someone else who's you know coming at some of these problems We're trying to figure out how they can fit in Or even a larger organization trying to figure out if they're how to manage the treacheries of the modern Technological world, you know first off, you know, you just have to admit that risks are inherent in everything we do day to day But especially in the line of work that we're in and you just have to understand them as best you can And then expect that there will be problems that you didn't see my big role models in life are actually You know astronauts and the team behind them that sent people to the moon and send people to space and you know They went into a complete unknown and engineered a solution by trial and error and the stakes were incredibly high But they were able to mitigate those risks and when they didn't and failed they were able to pick themselves Back up in order to eventually succeed Yeah, one of the key things there in terms of risk evaluation is not just the engineering team having some understanding of Going into unforeseen territory But making sure that all the stakeholders who are involved in a project really understand that yes There are risks we can see but there's a whole bunch of risks that we can't even fully comprehend yet And having their buy-in as well that it's worth going down that road to create something really new And the key thing though that we're really trying to emphasize here is finding collaborators and partners Whether it's a partnership like TWC and media currents or whether it's people at a boff that you meet at Drupal con finding other people who are interested in similar problem spaces and Really jumping in with them and diving in for the long haul And figuring out how you can collaborate together because innovation is never something that just happens in a vacuum It's something that we can all contribute to together and that's it. Thank you very much. Thank you everybody And we have plenty of time for questions Feel free to approach the mic My name is uncle gupta and great presentation there. I had a question So I kind of looked at your previous case study, right? So when you did your Drupal 7 and angular You know sort of set up so one of the use cases was to control layout and how do you manage that in a fully decoupled? It's a good question It's a secret That is actually what we're That's that's that's literally phase one for us is is Building a system that allows that in a decoupled world. That's all I can say In in the Drupal 7 realm, you know our Drupal 7 site was built heavily on panels If you've seen some of the previous case studies and in that Drupal 7 world There's actually a restful panels module that you can use. That's awesome. Yeah, you're the guy. There you go So that's one example of this guy ways that you can have a have a layout That's driven by an editor and then it's actually the entire layout and the contents of a page or put out as Jason That can then be consumed by a separate front-end So trying to be Agnostic with your technology thinking forward you're decoupling the front-end you're decoupling the editor interface You're have everything defined in your JSON schema. What point is Drupal not necessary? That's a really good question Have you had conversations internally about that? Oh, yeah. Yes Absolutely, and that I mean that is the reality that we face right is that in in terms of our overall stack Drupal is in some ways becoming a smaller and smaller piece of that stack But it's also in another way It's kind of the glue that's binding a lot a lot of it together as well because what Drupal is really good at and it's Largest strength. I think it was mentioned in the keynote today is data modeling and handling really complex data structures And that's still the role that Drupal is serving in this Model as we move forward now one of the other things I'll say about that is is that we're also really looking at Ways that the kind of ideas that we're playing around with here Can help shape the future of where Drupal's headed as well So things like like the session that Preston so is going to be giving I think it's tomorrow called decoupled from the inside out Where there are people that's a core conversation where some of the core people are really exploring ways of making Drupal more micro-servicing or completely decoupled Out of the box. So we do think there are there are notions here that could help guide forward Ways that we could really grow the entire Drupal platform as well and and I'll say not only that I mean if I think it it behooves the rest of the CMS world and the technology world for Drupal to to be a leader in in Embracing API first methodologies and having those technologies out of the box. I mean, I think that would drive adoption And certainly inform the conversation about how systems do that in general So I work for a small the weather small weather company in Oklahoma and Over the Oklahoma Mesonet But we have a small team it's state and university driven and we're completely moving to Drupal So this is all all new kind of in the planning stages of getting everything ready, but everything's pretty much the same We have you know very localized data Tons of data coming from sites all over the state Reporting every five minutes, you know, there's constant so is your is Drupal handling the weather data Not necessarily okay good So we you know, we'll also have You know weather entries to where people can go in and edit edit maps or edit info about weather parameters and edit news Articles and things like that too. So that would be the main use for that and then the main structure for the site You know your general navigation and stuff, but I guess my question to you is What would you recommend for a small team and we have like maybe three people that are gonna be working on this and You know things that we can do to help us in this move so Generally for a small team going fully decoupled may be over architecting Yeah, and if you can avoid it Unless you really understand the kind of complexity to your stack that it brings along with it it might be worth really looking at the kind of progressive decoupled model and honestly I would suggest specifically looking at the Decoupled blocks Kind of kind of model because that's a way that you can just take the very specific parts of your page in Drupal 8 that need to be really localized and dynamic and Pass those off to some JavaScript framework of your choosing Almost anything else that I'd say is is almost CMS 101 stuff I mean make sure that you model your data data types accurately make sure you know how to categorize your content You're gonna want to be pushing content to people on-demand make sure you've got a strategy and a solution for the keeping the content fresh Make sure you look at your editorial UIs and that everybody's happy with them when you get started because for a newsroom having that editorial velocity is huge and when that starts getting unwieldy because you've got Too many places that you need to assign categorization like too many taxonomy fields that can really hurt people so Definitely bear that in mind as you're building out Thank you It's funny because we've given the impression that we're super heavily into angular here But the truth is where we are using react as well on the weather. Yeah This is this is the whole thing like one of the drivers was when we launched Angular was the thing now, you know, there's I mean, you know There's too many frameworks almost but and one of the challenges that we have in our d7 is that the investment of development resources into making it work with just any Framework out of the box is just it's too much. It's too heavy Decouple blocks on the other hand has the idea that maybe you would have a site a d8 site where you would choose one But that you wrap The you basically wrap some code some metadata around the framework itself and tell Drupal how to embed it But that could be what handlers exist right now for that React view angular to I think there's an ember one in progress as well but from our team side like our our first Forays into decoupling are live and they're based on well, they're originally based on react I don't I think they may have changed that the front-end teams. They're they're basically using inferno inferno. Yeah, so cool Well, if there are no other questions feel free to come up and talk to us after you're free. Thank you so much