 Oh, OK, cool. Yeah, so I guess I'll start. I mentioned this before. The slides are available online now. If you want to go check them out, there's links and resources contained within them. So if you're a note taker, I got the notes ready for you. They're available at the URL at the top, emarchac.github.io slash drupal-in-the-dark. Cool. So hi. This is Justin Longbottom. Hello. I'm Aaron Marchak. Yeah, I am a Drupal developer. I've been working with Drupal since six. The version, not the age. I've also done another presentation that's focused on accessibility in Drupal. And that's one of my specialties. The other one of my specialties is getting myself into trouble. So this is a presentation about that. And I've worked with Drupal 8 on several production builds and have done work with Drupal 8 and React in decoupled and progressively decoupled environments. And I'm Justin Longbottom. I'm a developer at MyPlanet as well. I've been doing Drupal for about six years. I've been building web apps and web applications for about 10 a year now. And yeah, so happy to be here today to share what we've learned recently with you guys. Damn. We're both from MyPlanet. Oh, yeah. It's Justin, you can see there. We're a technology company out of Toronto, Canada. We specialize in making usable and beautiful products for the enterprise environment, a web and mobile. So our essential mission is to get the user experience that people expect from consumer apps and bring that into enterprise and corporate internal environments. So we're hiring. We're really nice. So if you want to come visit us in Toronto, we can go see a Jays game. That's us. And I'm going to actually start this presentation with a story. There is another company in Toronto that we're very good friends with. And they're called Heliolytics. And what they do is they specialize in auditing solar panel installations. They use aerial photography to go to these. I'll explain why this connects to Drupal in a second. I see that you're confused. But this is a real company. And they take aerial photography of solar panel fields and identify the panels that are broken. And they return to the owners of the fields, the maintainers of the fields, with a graph saying where it's broken. And this is particularly interesting because they do this with aerial photography. So it's in large mass. And these solar fields, I don't know if you've ever been to Arizona, but they're in the middle of nowhere. So it's very far to get to. It's very difficult to get to. And when you go there, there's actually no guarantee of any internet connection or cell phone connection. So Heliolytics has this problem where they pass off the grid of broken solar panels. So you can see here, this is the photo. The light panels up there are the ones that are not working. And then they give the technicians that go out into the field this grid. And they know where the solar panels are, but it's really difficult to communicate to the technicians exactly which solar panels are broken, where those solar panels are located, and any kind of more information with it. On top of that, these fields can be hundreds and hundreds of square kilometers. They're very large. And they're in remote locations. So a technician has to go print off the sheets that indicate what's broken, drive all the way out there, try and find where these individual panels are broken and address the issues. So there's hours of difference. There's missed connectivity. And there's a lot of different issues that you have to handle. And to make sure that the technicians that are working on these fields have the correct information that is up to date and that they're able to interact with is really important. And that's a problem, because if we give them a website or an application, they're going to miss the connectivity when they go off line, when they go off the grid to visit these fields. Or if they choose to go and print out the documents and then drive all the way out there to make sure that they have it, the documents could be 12 to 24 hours or even longer. They could be out of date. So while these people are working in the solar fields, how can we actually help them solve the problem? So to solve the problem of solar, we're going to have to go in the dark. So yeah. So this is the presentation Drupal in the dark. And so what we're going to cover here is a few examples of business cases and use cases for why having an offline ready Drupal environment that customers can use to engage with their content in an online and offline and dynamically changing world. We're going to go through a few more business cases and then some goals that we had with this presentation. In building this presentation, Justin and I really started exploring and pushing the boundaries of what we knew how to do with Drupal. So we had some technical goals and things that we wanted to answer as developers as we were going through this and developing this. When building out our offline Drupal environment, we used a specific set of tools and the toolkit and we'll go through that. And then we're going to go through our exact build process. We're going to give you a demo of the application to show you how it works. So there's going to be a live demo. So it's offline ready. So if the internet goes down, we should be OK. Across your fingers for us anyway. We're then going to talk about some security implications in an offline and a headless environment. And then finally, we're going to go through some afterthoughts and looking forward. So there's a lot to pack in here. We're going to ask for questions at the end to make sure that we cover everything. Hopefully we have some time for that. So why decouple Drupal 8? There's been a lot of dialogue lately about it. Dries mentioned it in the keynote. Thank you. Lots of articles posted by Aquia lately about it. So it definitely seems to be a direction a lot of people are interested in. I would hesitate to call it the future of it. But there's certainly an API-first initiative in Drupal 8. We are fortunate enough to attend the Aquia Partner Summit on Monday. There was a roundtable about the API-first initiative posted by some excellent members from Aquia. So that was really informative. And I just sort of reinforced this notion that decoupling is sort of a direction a lot of people are interested in. So that's sort of why we got interested in this. We sort of witnessed the dialogue. We want to participate in it, further it, experiment with it. So we're hoping to show you guys basically what we've learned, what we still need to learn, the trials and tribulations of the prototype that we've built here. And just sort of the supporting modules that helped us put this together. And there's been one of the things in this list is Lullabot recently redid their whole site to be decoupled and offline capable. And there's some interesting technical choices that they made that are different. And we're going to talk about what's unique and what's different between Lullabot's choices and different ways that you can pick the technologies that are out there. And just adding to that, there's sort of this notion of progressively decoupled sites. So there's a spectrum of decoupling. You can have fully decoupled or partially decoupled. So we've worked with a lot of progressively decoupled sites, sort of having little react components that we've embedded to generate a nice UI. This is sort of taking it all the way to the one end of the spectrum with fully decoupled. And then we add offline capable to that, to the mix, just to make it extra fun. So that's sort of the rationale behind it. X-debug has crashed. So in doing and researching the decoupled, we found that the business examples that the community has largely been talking about have been kind of wanting, for lack of a better word. It's very easy to talk to a developer and say, we want to build an offline capable application and the developer to get really excited because it's new and it's exciting and it's somewhere that we haven't gone. But it's difficult to go to a business or a client of yours and to say, I want to build an offline capable application. They're probably going to be like, what, does it cost more? And you're like, yes. And they're like, no, don't do this. So having the ability to talk to business cases and use cases for offline I think is really important. One of the business cases that we've seen a lot and I very much agree with is commuters taking public transit where you expect them to be online and offline a lot and you expect them to disconnect and have partial connectivity. Yeah, another one would be just basically in general intermittent connectivity. You can't always rely on the internet if you're maybe taking the subway and an airplane. So traveling is obviously a big barrier that creates the need for offline capable. If you come to Dublin and then you forget to pre-buy a cell phone plan. That happened to us when we landed, so those sorts of things. And obviously technicians that work in remote locations. So that's what Aaron was alluding to earlier with the solar company. Just we're getting good coverage but it's not everywhere. And so this sort of helps bridge that gap. And so when we started looking into this and we started developing it, there were some specific goals that we wanted to actually achieve with this implementation. We wanted to stop treating lack of connectivity as an error. Yeah, so one site we stumbled on when we were kind of doing some research. I'll switch over to that tab because I won't paraphrase because I do a good job of it here. I'll just read that out to you. We live in a disconnected and battery powered world where our technology and best practices are left over from the always connected and steadily powered past. So basically we have phones that'll die. We have grids that are inconsistent. So offline first is sort of initiative or a way of thinking about it. We've probably all heard of the phrase mobile first which was a term let's say maybe 10 years ago that started, you started hearing a lot basically developing for certain devices or mobile devices first, having that in mind first throughout the development process. This is sort of analogous to that sort of offline capable first, sort of having that in mind throughout development. I heard a really good quote at this Drupalcon that it was like the software that we're building is in a perfect environment. We have perfect control over it but it's built on top of an imperfect network. It's the physical world, it's not gonna be correct. And so to assume that you're gonna have complete and perfect connectivity is just false. Another technical goal, view all the content all the time. So sort of the idea is that when you first visit the app or the website or the page, you kind of download a copy of it into your pocket if it's your phone and you have it with you or wherever you go. Once you're offline, you kind of have the whole site. This is different than caching where you have to view it first or whatnot. In this, you sort of get a whole copy of the database and you have it stored locally. So that's sort of the difference there. And you're able to write and read the database locally. Like you're able to perform crowd operations locally and then have it connect afterwards. There's not a disconnect between what you're able to see and then when you're able to actually perform those additional actions. Yeah, and our last technical goal was connecting Drupal with React without the middleware. So often there's sort of a middleman interface between Drupal and your application. One of our technical goals was to have the app communicate directly to Drupal using some APIs that we set up in Drupal 8. And the Lullabot example, if you follow their kind of implementation, they did do a really, really nice decoupled Drupal 8 with Pouch, which was what we did, but they chose to put a middleware in between. And so we wanted to see what would happen if we took the middleware out. So we'll get into that. Tools. So this demo was built on 8.1. So there's some requirements that we have there that are not gonna be true in 8.2. The reason why we used Drupal 8 specifically, we mentioned before that we've been doing some decoupled work in Drupal 7. I don't need to rant to you guys about why Drupal 8 is better, but predominantly it's able to match the speed of React and it's able to be just as performative. So that's a really key issue. So the suite of modules that we used for this, they're listed there. Relax being the main one. I don't know if any of the maintainers are in the room, but we want to give a shout out to you. We probably were bugging you on the issue queue a little bit. Yeah, so that's good. So yeah, that kinda helps smooth things over for us. So we definitely had an experimental mindset coming into this, just trying to see what we could do. So we were happy to kinda participate in that a little bit. But yeah, so this suite of modules, I'll switch over to the React one, relaxed one. So the suite of modules, you can recognize them, they'll have this little blue cloud. There's a lot of co-dependency between them. They work together very well to provide the architecture that we needed to make this happen. And if you go down a little bit, well, this is exactly our use case and we actually are using CouchDB. So we sort of use that as a guideline, I guess, for some of the prototypes that we were building. We're actually able to do this, I believe, correct me if I'm wrong, without writing any custom Drupal 8 code. We use these modules and the built-in Drupal 8 services to make this happen. So that's kinda cool, in our opinion. Most of the heavy lifting and the code writing that we did for this was actually on the React side. So Drupal 8 really made it easy. One note in Drupal 8.2, and I just learned this recently, the cores module, just cross-origin resource sharing is now in core, and that's one of the key modules. But we'll get into that a little bit later, I think. But yeah, thank you to the maintainers. The other side of the application we built with React, the reason why we chose React for this is we have been using it a lot recently, and it was what we were most comfortable with, which is, I think, the first step when you're trying something new is to keep as many variables consistent. One of the reasons why we choose to use it, I mentioned before that we do enterprise applications, and React is really, really, really nice to use in that sense, because it's, as I have here, it's for building large application with data that change over time. So it's stateful, so it's really nice to be able to handle different elements of state. You have composable, declarable, or declarative components, so each component is inherently contained within and out of itself, so you're able to understand and be able to manipulate and share that throughout the application. And it obviously works well with Drupal 8. So a little background story. We've done a decent amount of progressive, decoupled work in Drupal. This is sort of a case study I'm gonna run through quickly for you guys. This is actually a Drupal 7 site that we built. It's progressive, decoupled, meaning we have pages with React, single page React apps built into it. That was sort of our foray, our entrance into doing this sort of React work with Drupal. Oh, sure, you wanna open that? Yeah, keep talking. Okay, so the way this is set up is we basically have a React app that consumes some JSON data from an API, and we built a really nice search interface for it. The rationale behind this is views when you have huge sets of data. Every time you change a query filter, even with the AJAX turned on, it has to make a round trip to the server. It can be slow, it's not as responsive. The idea here, because we're dealing with huge sets of data, is let's deliver everything to the client app on page load and do all the filtering and updating client side. It's very snappy, very fast, and if you go down a little bit. I'm getting there, there it is. So here it is. So it's basically a vacation planner. When the page loads, it says give me all the vacation options, every departure, every permutation of boat, every price, every add-on, every passenger number, it's a lot of data. And if you're, I mean, maybe you could do that in views. It would probably be a really painful experience, especially with all these complicated filters. Some of the filter widgets that we're using are nice little React libraries that we've leveraged. Resulted in a really snappy, wonderful experience. So basically, that's sort of how we got into React and decoupling, and now what we want to do is kind of take it to the next level, have fully decoupled app. Yeah, that's sort of the background. The other thing that we've, we chose here is within the React environment, you have a bunch of options for offline thinking and data stores. There's been a lot of discussion here regarding the different ones. The one that we chose here was pouch to couch. The main reason was because Relax came with it, and I'm lazy, so somebody else is doing the work to make sure it's connected. Great. It's also, as we said before, it's focused, specifically it's focused on offline first, and that's the main target of pouch. I guess I jumped ahead earlier, but yeah, the idea is have all the content all the time, download a copy to your pocket. It's kind of a cool idea. One thing pouch does really well that we found is resolves conflicts and kind of race conditions you can have. We were trying to break it earlier, have two people editing the same node in the React app in the Drupal side, and it seems to resolve that pretty well. Pouch is basically a JavaScript implementation of the couch standard. So it's, yeah, fully client side. Just worked really well. It was very dev-friendly. We'll show you some snippets in a bit. It was pretty easy to get up and running. It did again a lot of the heavy lifting. So yeah, we were able to use this tool and other tools very well to build this. And pouch was supported by most major, like obviously not IE6, but most major modern browsers pouch is able to use, go in and use, and I believe there's also a pouch native, so you can actually start doing some more native applications if you're using React Native on top of React DOM. But we'll show you how easy it is. So this is all the code you actually need to have a live syncing application once you have your React scaffolding up. And we'll show the React scaffolding. But you have the, you create a local instance of your pouch that's keyed with whatever you want. You create a remote instance of the pouch object, which is targeted to your remote endpoint. And then you use the sync function. And then you're done, which is nice. And this inherently handles all of the conflicts. We'll show you how to do a live syncing. So this is syncing on demand, but you're able to use different flags to do live. And it works with JavaScript promises. So you're able to do really, really nice asynchronous code. So we were ready. Everything was good. We had the supplies. We're ready to kick some butt. So we built it. And now we're gonna show you how. Cool. So the first step in building this is we actually had to set up Drupal. And as we mentioned before, we really didn't need a lot of additional modules. For this example, we installed one outside of here, which was just the geofield module. But we set up Drupal using relaxed. This is Drupal 8.1, so we did need to have the cores module and we used the deploy suite. And I'll show you how it gets in there. Ah, that's revisions. So one of the things that we had to do within here is set up the replicator role and it comes with Drupal core. So when you enable the replication, here, would you mind driving? Sure, sure. Cool. So as I mentioned earlier, we didn't actually have to write any Drupal 8 code. It was mostly came down to configuring the wonderful modules that we were able to use. So the replication module gives you a replicator role, which is basically permission to replicate the data and pull it in. So I think in our case, we're just using user one, which kind of forces its way in, but you can kind of have some more fine-grained permissions that way. And the way is that I hate the permission page. It's a mess. That's fine, that's fine. Another thing was configuring relaxed web services. This is basically the, in your connection string, when you're initializing pouch, it's pointing to a Drupal endpoint. This forms the root of that connection string. And you can set some permissions here as well. Workspaces, this is kind of a cool module. It allows you to have different workspaces or sort of database instances in a sense. We're just working with the live database, so when we make a change in our React app, we'll actually see it in Drupal immediately. You can have a staging workspace and kind of deploy between the two if you'd like. Another module we had to configure was the cores one, as we mentioned. So this is sort of security-related module. It allows, as the name says, cross-origin resource sharing to prevent you from accessing it. It's basically a whitelist of other domains that can access your site. So for our demo, you can see here, we have localhost 8080, which is the local server we're running for our React app. That was kind of the bulk of it. Yeah, so really just configuring it. I don't know if there's anything you want to add to that. No, that was largely mostly it once you got going. We ended up creating, for this demo, creating a content type called panel, which represents a solar panel. And there, within there, great. And you can see here the roles that we're creating. Within there, that represents all of the content that we have. So we have the different solar panels. We also created a test article because this is a standard Drupal install, but you can see that we have different content types and within the content type itself, well, let's go to the Guinness factory. That contains data that's being passed onto the application. So we have the full node on the React side. So you can see here that I have the Guinness factory and the solar panel I've reported is broken and I have a geolocation information stored within there. So on the React side, you can see here that this is the entire React application that we have. We have a maintenance portal and you can go in and you can inspect the Guinness factory to see what's going on there. And so here we have the data that's being passed back and forth between Drupal and React. And you can see, as we mentioned before, the heartbeat that we have that's connecting pouch and couch or React, the JavaScript front end in Drupal, you can see how the network tab is pinging for changes. It basically pulls for changes. Depending how you configure pouch, it's sort of, it's basically saying are there changes, are there changes, are there changes? And if you make a change in Drupal, eventually it'll get sort of a handshake back saying yes there are, here's the timestamp, here's the doc IDs that are different. And then there'll be a payload with the updated data. And then pouch has a nice little callback for when there are changes and that's sort of our trigger in React to update the state and reflect the changes that we've received back. So yeah, so this representing the React application, I'll go over to the code in and of itself. Here I have a React, my React application and I would like to say, as I said before, I specialize in Drupal, I'm not a JavaScript specialist and I wrote this, so you can do it too. Actually, how many people here have written a React app? Just, okay, so everyone. Oh, okay. So people are familiar, yeah. Certainly not rock stars, but we got it done. What I would like to say, and I'll post this afterwards, is I used React Fundamentals. There's a tutorial called React Fundamentals and it's free, it's available online. I will send out the link later and update that. But it was really, really, really easy for me to get started with it. So if you're a Drupal developer who hasn't worked in React a lot, I highly recommend that as a tutorial, it's very clear. And React itself is just a beautiful application. So I'm really happy that we're using it. Whoa. So going through, as I mentioned before, it's really simple to create a pouch application here. We have to require a pouch at the top and this is my database helper file within my application. And all of this code is available online. If you go to the GitHub repo, erinmarchac.drupal in the dark, it's connected to the presentation. You'll be able to see it and give me tips. But here, we have the local DB, which I mentioned before is just a string. The pouch DB, which I've represented here in a terribly, terribly secure way. I am passing my username and password, which is testing, which is so secure, to my Drupal instance. And then as we mentioned before, we configured the relaxed live endpoint. So relaxed is the endpoint and live is the workspace. So you have the ability to switch between the workspaces, which is nice. We could connect it to slash relax slash stage if we wanted. Yeah, and as you can see here, I mentioned before that that's my user. I have a user representing myself in Drupal that has the replicator role. And that role is required to actually have access to this pouch thinking. Once I have that, I have a library called DB Helpers that I've created. And within there, I have this function called get site data, which I used to sync. And this syncing has the retry flag, which is a retry offline. So when I disconnect, it's gonna keep pinging as opposed to just shutting down, which is an option. And then also live true, which creates that ping time. My home component here, which is the table that I've shown before. I have a change function. So component did mount. For those who haven't used React in the room, that's actually you're able to call and identify when a component is loaded on the page, which is really nice. When I noticed a component is loaded on the page, this is an example of how I do a live change. I then call the sync function, which allows me to sync, which checks if anybody else has changed anything on the page. And on a successful sync, I get a change. So I've synced, I've noticed a change, and then I'm able to call a function within there, or excuse me, to call a method within there, and actually get a live refresh. So I have my maintenance portal. I have my Guinness factory, which is broken. This better work, guys. It's the moment of truth. Yeah, man. And I'll show you the live refresh, which is really, really nice. So I'm going to Guinness factory. I'm going to edit it in Drupal. So this is me pushing a live sync, and this is just having a live sync on the end point. This is while you're connected. I'm going to tell them that the Guinness factory panel is working. Let's keep it there. Do, do, do, do, do, do, do, do, do, do, do. And then once this submits, and we give Wade a little ping time, we have a live refresh on there, which is really, really nice. And it gives you this really cool idea of being able to connect and talk to and engage with different users of your application. Inversely, I have my Drupal side on my local. And I don't care what people tell me, I'm still using MAMP. I'm going to stop my local host. So Drupal is offline, for sure offline. And then back on my React side, I'm going to go through, and I'm going to look at the Dublin conference center. That's pretty good. And I'm going to say, no, it's definitely broken. This panel doesn't work. So now we've saved that change locally in pouch, but it's going to wait for connectivity again from the end point to be back up. I'm going to turn this on, and go back to admin content. Do, do, do, do, do, do, do. And on the Drupal side, it does take a bit longer than the React side. I'm going to see if the panel is, right, I changed it to broken. I'm going to edit it. No, go, go, go, go, go. It's trying. Make fun of me. So on the Drupal side, it does take a little bit of time. If I flush caches, I bet it'll work, or it'll break. So this is just our Drupal side. You can see here, we're including some additional items as we were experimenting. But overall, this is all that you really need. Enable it. Yeah, it's broken. To async. I was really pleased with this. So that's sort of the full round trip. Yeah. From both directions. Yay, my demo. And you can see here on our network tab, on our network tab. Great. When you look at the thing, this is the red items here are when we actually saw an error where Drupal was offline, and it's able to target that. You're able to perform things on failed syncing, but from the end user, it didn't see it, it didn't change at all. It was a really nice seamless workflow. We get a revs diff. And the other thing that I haven't implemented here, but you are able to do is actually target which item was changed in your pouch database. And then you can, since you're using React's components, then you're able to actually rebuild the individual component on the page. So you're able to do really nice granular work. Back to slide show. Cool. So, we work in enterprise. The question of security is to hear. Yeah. So you saw we had our connection string with the username and password hard coded right in. Obviously not ideal. There's some security implications that we sort of thought about that might make it not enterprise or maybe even production ready. Although maybe we did some things wrong too. I believe that first quotes from Google. Basically data that can be accessible to unauthenticated users makes an ideal candidate for offline storage. And that sort of makes sense. If anyone can get to it, then there's no real concern with having it in someone's pocket downloaded if they have a copy of it. Yeah. The other thing is because we wanted to have all the content available all the time, that means the whole database is transferred over the network and stored in local instance. So for an enterprise environment where you're reading and writing protected information, that's an issue. The other thing we did while researching this is that there's no rule access control or ownership checks on CouchDB. In the CouchDB specification you really have all or nothing. We found that when playing around with Relax and Drupal, if I have a specific node permissions, so I have all my panels, panel node type on Drupal and I have that one article. I wasn't able to resolve, and this again would love to talk to people after this, I wasn't able to resolve a way that I could just get the panels over, the panel node types over to Couch, I had to receive all of them. So within my database here, you're able to filter by the node type, which is absolutely fine, but in terms of security, that's something that we would want to have addressed. You're essentially getting the whole database and then our app does the filtering to say, hey, let's just show the panels. You could present other things if you wanted. We did see it send users as well. Not anymore. Did we resolve, okay. Yeah, I don't know. But within there, we also, in general, the recommendation was you just filter your content on the pouch side and Couch is very, very agnostic. The other way that they actually recommend to do it is to have multiple instances of Couch one per user. And so your Couch instance only syncs to the user's Couch instance and then you have Drupal. So that meant that we, to have a secure application, that means that we would fail at our goal of just having Drupal to Couch at the moment. So in general, would we recommend exactly what we did for an enterprise application? No. This was an exploration. The security implications of having a full database being stored in the user and not being able to have control over that really suggests that our approach is not the right way and I would not recommend it. But the interesting part about that is that there are some other things and tools that you can use to address these concerns. We talked about that afterwards is relaxed and Pouch, that connection really enterprise ready. I had the great pleasure this week of being introduced to IBM Cloud and to Envoy which is a solution of this. It represents different Pouch endpoints. Excuse me, it represents different Couch endpoints designed for a large enterprise environment. So you can theoretically create multiple Couch instances for each user that then sync back to Drupal and for your Pouch to actually sync. I have not done this. I just found out about this. I would love to hear more from people that have used it or will use it and are looking into it. But that's one of the directions that we could go to help solve this problem. The other question that we have is, is relaxed and Pouch preferable over any other option? We're talking a lot about a lot of different options to actually get data out of Drupal onto it and there's still a discussion about whether or not this technology stack is the best choice. In general, with any other option they all are a document store in the browser that's available offline. That base is pretty easily measurable whether or not you wanna do it. One of the negatives of choosing Pouch as a tech stack we found was the per document control. There are issues out on the Pouch and Couch JIRA. There are being addressed, that is being addressed but it's not done yet. The one thing that Pouch is just awesome at is how easy that sync was. I've seen a lot of other examples where you have to handle the sync. You have to handle the conflict resolution within there and that's something that's done custom. Pouch does that for you. In terms of a prototype, it was absolutely perfect. Looking forward, our takeaway thoughts. Drupal's very good at managing content. Surprise, surprise. Keep doing that, that's great. But we are very interested in this decoupled approach. We like to say, unleash your front end devs. You can kind of have them working on your Drupal products a lot more now. I know at my plant we have a great team of react developers and so we can maybe start integrating those a little more into our Drupal production teams. And just a side note for people that are into it, there is CouchDB for native, Android and iOS. Haven't played with it myself yet but it's out there. It's kind of cool. Yeah. So that's our presentation. So that's what we found. That's what we learned. I hope you enjoyed it and if you have any questions or comments, let us know. And all of the code is available online and the presentation is available online for pull requests, suggestions and anything. I just had a quick question. More like something that I picked up a couple of months or weeks ago on Hackernose on Reddit. I'm not sure if I found it. Was that Facebook actually has this rather nasty patent clause in their license? And I was wondering. I think this issue is something that earns some awareness on one end. I was just wondering if this was something that you guys have, it comes down to for the people. Facebook has the right to revoke a license for using React for an entire company if they feel that this company uses React to build any sort of competitor for Facebook. So any kind of social integration would fall under this rule set. Is that something that you guys have to act? Honestly, no. I don't think the sites we're building, we're really competing with Facebook, like a vacation planner for example. But that's a good point. Probably something to consider if we did have perhaps maybe a socially orientated client of some kind. But yeah, I actually was not aware of that but good to know. There's also the question about how far they're gonna actually go to supporting the clause. If you have a comment, can you come up here for the mic to make sure that it's recorded? But thank you. Yeah, if the clause is intentionally vague and if they haven't acted upon it, it'd be interesting to see what happens when they actually do and how far it's supported legally. Does this work or is it just recording? It works, yeah. About the clause, I actually was looking at a different perspective and I heard from the guy that actually said like if you wanna use React on any client, you should get your lawyer and it seems a bit like far fetched and it seems a bit like, I don't know, a hot potato. But the thing is actually that in their clause, you don't have to be even a competitor. Let's say for example, you use Facebook logins on your website and all of a sudden they go, oh, you guys use Facebook login, you kinda need more data that you guys store from our users. Like what did they do there, what did they do there? And then all of a sudden you have to kind of give in to Facebook so it's like a big red button almost and not even if it's Facebook or if you're gonna sue Facebook or if you have two companies and they're basically competing against each other, they're both using React and then they get into some sort of a clause of hey, I think you copied my design or you copied my code. You both have to drop React in your code which is again a big red button. It sucks because React is what else am I hearing? It is, yeah. I think that there's a, the nice thing about working with Enterprises and some of them is that they do have a lot of power behind them. Yeah, yeah, bloat, bloat, power. It's a big ship but if the ship starts going in a direction it'll bring a lot of people with it and the important thing is to remember that bullies don't win and that clause is such off, it's bad. It's like really not fair to sharing the community and so if we run away from that and if we don't address that clause as a group then I think that it will never be resolved and it'll kind of be left there. In the same way that the IBM employees challenge, not IBM, excuse me, EA employees challenge the legal clause of no paying overtime for devs. It's not until you stand up for yourself that you can really have change. Valid clause but. Yeah but we should really stand as a group. It's hard. It's hard but in general I found that the communicating the benefits of building technology with React, they're normally quite on board and then if you say that there is a condition where this happens but we look at the benefits and the probability of it of being made an example of by Facebook and what that implication is that's another way. I know in Drew's keynote he mentioned standardizing to Ember. I haven't worked with it but I don't know maybe that's one of the considerations for that is all this legal mess. Pick something that's not controlled by Facebook. No, no, no, no, it's an important discussion. Thank you. I would say the nice thing about this demo, React isn't required. You only need Pouch and Couch which Couch is Apache open specification. So mildly still valid but you can pick and choose. So whether or not you feel comfortable on either side of the React discussion you can still use Pouch and Couch. Well, thank you very much.