 Oh dear. That would be horrible. My planet needs me. Are you nervous yet? What's the gig going? It's so much better sitting down. It's like informal. I know. All eyes are on there anyway. I know. That's why I've never understood why they record. I've seen that too. It's like you're just trying to set something up for the material. Are we going back? Do we have to hit a record button? Did they say anything about it? You're being recorded for speaking to Mike. Oh, I'm not sure he just said it. Pretty good turnout. The doors closed. Is that what we do? Yeah. What would the assistant be like to tell us that? To start. 1045. Except for when I'm not. That's true. All right guys. We're going to get started. If you guys have any questions, feel free to stop. It's in the middle or you can wait till the end. We've got a lot of stuff to cover, but we definitely want to leave time for any questions, any further explanations of the topics we're covering. It's a lot of stuff. But yeah, we can definitely make time for any questions. And if we can't get any questions, just hit us up after the session. Hello. Steve, can you go first? Yeah, sure. So I'm Steve Woley. I'm from Australia. I work with Aquia as a technical consultant. I've been here for the past two years. My day-to-day is kind of like running around, working out business requirements and mapping them to Drupal functionality and doing that kind of stuff. So it's quite challenging. It's quite interesting, quite rewarding. I wanted to talk to a bit of a story about past projects that I've had that's kind of led me down the decoupled space. So at my previous job, I was working with a large travel company. Then we managed around 80 different brands. And each brand had around 200,000 products that we were syncing between each site. So it worked out to being around 16 million database records across all of our sites. And most of that was duplicated content. And that doesn't really make sense to me. So I started looking at a way that we could centralize that data and then expose it via APIs to all of those 80 sites. So that was kind of just a brief intro into how I kind of got into the decoupled space and started looking at ways that we could use APIs to syndicate content around rather than kind of duplicating it through databases. Great. Hey, everyone. My name is Jason. I am not from Australia. I'm from Atlanta, a little south of here. I've actually been with Acquia for four years, and I'm the front-end lead in professional services. My experience with Decoupled Drupal started more intensely a year ago when I was tasked with helping lead several initiatives. So a lot of my day kind of stretches from multiple roles, but there's a lot of decoupled conversations, right? And we'll get into that as far as, like, is my project or is the scope of my project appropriate for Decoupled Drupal? I know there's, you know, a lot of things to cover with that topic. But pretty much, you know, my day-to-day, as far as like working through best practices with Decoupled, how to communicate the best use cases for communicating those scenarios as well. So, yeah, kind of cover things all over the place. Cool. So let's just jump into about the presentation. I'll run through these pretty quick. I'll give you guys a quick refresher on Decoupled Drupal. Obviously, since it's more advanced topics, we won't, you know, belabor the point for these items too much, but we'll give you, I guess, a little bit of a flavor of our opinions on it. Yeah, next we'll jump into React Plus Drupal, the new hot couple. We want to kind of cover React as, like, our framework to kind of discover and utilize the APIs, but, you know, we've used a lot of things like View, Angular, across the board. We just chose React because we wanted to, honestly, play, play around with GraphQL and React in our Decoupled Kit, which I'll get to in a second. Next, we'll cover orchestrating Drupal API data. We'll primarily use GraphQL as a way to communicate this, but there's, you know, several other options out there as far as middleware or proxies, ways to do this. We really want to communicate why we chose the path we did, which I'll get to in a second, as far as understanding architectures and comparing architectures, right? So, depending on your project and the scope of your project, various things are obviously required. So we wanted to kind of take a step back within our Decoupled Kit, which we bought, just to explore each option and compare, like, you know, why is the proxy helping in this scenario? Why are we not, you know, for example, interacting directly with the JSON API? Like, we really wanted to kind of dig into those scenarios just to understand them so we can communicate those out to help other people get their learning jump-started. Next, we'll cover Decoupled Development in the Real World, right? You know, for POC or talks, you can cover more high-level things, but, you know, we all live in the world of real projects, you know, real scope, real scalability, how to extend, and choosing architectures that are fair to hand off to clients even after we're done. That's, you know, a big passion of mine and Steve's as far as, like, choosing the right architecture for the client, not using the newest, coolest thing, throwing it over the fence, and, you know, just get Adeline out. And lastly, we'll give you guys a demo of our Decoupled Starter Kit. We probably didn't mention this before. This isn't anything we're selling. We've got a different source for you guys to download, play with, you know, use it as well. We used a lot of different toolkits. The React Slingshot, Headless Lightning, GraphQL, as I mentioned before. So, basically, our only purpose was to help further our own learning to help enable people on our team and people outside of Acquia. So it was essentially just, like, a developer, a developer's exploratory, you know, journey of understanding different architectures, discussing it, arguing about it, making the best decisions, you know, based on what we were trying to communicate, but also, like, understanding that there's a lot more things we can build, and a lot more things that, you know, we'd love to hear from you guys as far as what you would find interesting. Cool. Okay. So we'll run into some quick things with the basics of Decoupled Drupal. So, obviously with Decoupled Drupal, the main theme is that you're using Drupal as a content store, right? So, once again, this doesn't need to be, you know, just Drupal. So what we do sometimes is Drupalists, we focus so heavily on Drupal as, like, the main cog in the relationship of these different architectures. In a lot of cases, it's just 10%, right? Like, you're dealing with several APIs, legacy systems, old.net architectures. So I think it's important to kind of, like, scope it that way as far as, like, yes, this is an API-first approach to Drupal, but you're also dealing, you know, mini scenarios, which we'll cover in the Decoupled Kit other API scenarios. You know, obviously another big component of what we're talking about is shifting the responsibility of the presentation layer to non-Drupal applications. In this case, it's React, but it doesn't mean necessarily you're negating the front-end altogether. Like, we've explored a lot of scenarios, you know, with ourselves and clients as far as, like, stubbing out certain content types to be used, you know, to run, like, native React native apps, but it doesn't mean you're necessarily not using the front-end. I know there's a bit of, you know, discussions about that as far as, like, why would you negate so many things in Drupal? We're definitely not, you know, proposing that, and we'll make that really clear throughout the presentation, but we also want to kind of talk to that, too. And once again, you know, just enabling external applications. This could be several things. It could also be using external APIs to bring data back into Drupal, which we'll kind of cover through Marvel's API in a second with the kit. But also, like, understanding what that means as far as, like, best practices using OAuth, you know, validation, how to set your tokens, a lot of that fun stuff. Like I mentioned before, a big focus that we wanted to do was understanding how to synthesize non-Drupal and Drupal data and what that means. Like, is it better to use, like, if you're using, you know, for something more marketing for combining that data and you just want to, you know, essentially use, like, an external views mode, essentially to, like, pull in marketing data or things like that, or you're really migrating information back. So we actually, we'll cover this in a second, but we actually cover the scenarios of dealing directly with JSON API or using the orchestration layer, like we'll talk about. So just to reiterate the first point, API First approach, our version of API First Drupal isn't about negating features. You know, Drupal spent years and years doing things really well, trying to do things even better. We're definitely in no way proposing, okay, build your own editorial workflow. Like, hey, let's, you know, custom workbench and react. Like, to us, that's crazy because we don't want to, like, take away things that Drupal is good at to build custom solutions for. Our theories are more to extend and allow Drupal to power, you know, with editors having a comfort level, allowing that comfort level for them to, you know, go through normal, you know, workflows as far as we're going to go. We're going to go through a lot of different, you know, general experiences, but also power multiple other, you know, mobile apps, Alexa, things like that. So we really want to focus that as far as, like, you know, our big focus. This is a big question that we could probably spend three hours in here. I'm sure a lot of people have opinions, which is awesome. We don't see headless things. We don't see headless things. This is definitely dependent on the scope and various scenarios, like, you know, the technical scope of your developers, who you're handing this off to, how is this going to scale and things like that. So I'll run through these real quick. Typically in my discussions, we started with the client in, I guess, phrasing it like this. Is your business focused on making it more of a, is your business ready to work towards the directive of supporting and building on the API first. And the other things will kind of fall and sink after that. Also, is there a functional need to interact with data outside of Drupal? That's a big one, too. You know, from what we've seen, if there's, you know, like a one-to-one relationship as far as having a react app that is essentially like pulling nodes and displaying it, you know, it's like, you know, we see, you know, more like the synthesizing of, you know, different API endpoints and pulling different legacy data elements or more custom personas on, you know, like microsites, proxies, things like that, a little more enticing as far as the architectures, that makes sense. Yeah. And a lot of this, too, kind of comes down to, not that it's necessarily a qualifier, but, you know, you talk to a lot of technical folks that, you know, have their preference of working with people. And that's perfectly fine. You know, you want to do what's right for your client first, regardless of who you work for or your role. So we try to really focus on what's the comfort level of the people that are taking this on and helping develop. So if, you know, you have teams that are, you know, well-versed and react, Angular, you know, there's tons of awesome people out there and don't want to deal with Twig and a lot of that. We also want to make sure that, you know, if they're willing to adopt as far as from a business perspective, that directive, then we definitely want to enable people and have them, you know, work in the direction they're comfortable with. Cool. So I think it's important to understand what a content API is and how Drupal fits into the mix in providing that content API to many different clients. So traditionally, APIs have been a way for applications to share data and the content API is no different to that. It's a way of sharing content from a source to many different clients. Where it differs from a traditional API is that content is much more different to typical interactions with an API. So content has references, content has relationships, and content has all this complex metadata around it that we need to kind of replicate within an API. So things like JSON API and HAL are standards around how the API can expose that data in a way that the application can already infer different references. So when we talk about Drupal as a content API, providing a content API, we need to really pull back a lot of what Drupal actually is good at. So controlling layout, adding classes, adding styles in line with whizzywigs and things like that, which is things that we allow content teams to do. We kind of need to pull that stuff right back and say, you can't actually do this anymore. So we want to make sure that we have enough data and enough content for people to build good experiences with. So content APIs like JSON API, like HAL and different specifications, they strive to maintain the relationships between content. So if you use JSON API, you'll see that any reference is a link to that reference and you have to make another HTTP request to pull that stuff back. And then you have then you can have a full understanding, a holistic understanding of what that content is. So this is also about kind of making sure that the content is available for multiple different types of clients as well, so not just websites. In the way that the landscape is evolving, we're kind of starting to see things like chatbots and, you know, Alexa integrations and all these kinds of things that can start leveraging the content APIs. And if you start putting presentation in the different interactions between different front ends for your apps. One last thing I think I want to touch on with content APIs and how Drupal can fit in here is that out of the box, the JSON API module will give you a lot of functionality with your different content types and do all that kind of stuff. But if you do have custom modules and custom functionality that you need to provide to your different front ends, you have the ability to use different REST end points and understanding how they handle the data that you transfer between both applications. In our decoupled kit, we didn't really want to go down that route and we just kind of wanted to use the out of the box experience with Drupal and try and build a content site based on that kind of out of the box experience without touching too much on the REST plugins, but that stuff is available if you need to go down that route as well. Security is a pretty big thing around APIs and how do you make sure that your API is secure and you know who's talking between who. A lot of the headless profiles come bundled with simple OAuth in Drupal and OAuth is the de facto open standard for securing APIs. We'll kind of touch on, I'll go through exactly what OAuth is. OAuth is token based authentication. Your client will send a request to some API credentials that you define, so you'll create a client, you'll set up a secret ID and access to a public ID and you will sign that request with the back end and it will give you a token. Every request from the front end then is using that token and that will then operate on behalf of the user that generated it. So the back end knows that they, if I request and I get an authenticated user token, then I'm an authenticated user and I can have access to the API. And this is all stuff that's handled by Simple OAuth as well. Simple OAuth also provides different grant types and this comes into consideration when we're actually defining applications. So there are two main grant types that you'll probably look to use if you go down the OAuth road, so there'll be the password grant type which is something that's typically used by applications and this doesn't have to be the source. It'll be between the applications to sign the request and generate a token for every request that that application will make. This is typically what you would see on like a mobile application rather than having your user login and you will get all of that content. The other one is the access code grant type and that is the one where you will click on the login button that will redirect you to the source and your login. And then you'll access the grant type and you'll allow the client to have access to your data. And all this stuff is provided by Simple OAuth and the decoupled kit has examples of how this interacts with Drupal and with the React front end as well. So we've got a page that we'll go through when we get up to the demo part about how and we'll show the workflow fully from end to end of how the OAuth signs the request and how we get to actually see a little bit of an example where content is restricted for certain user types. So you'll see how you can actually start to map that stuff by using these OAuth and the scope and the grant types. Cool. So we wanted to include some information as far as within the decoupled kit as far as how you're dealing directly with JSON API. Once again, we're in no way I'll probably say this twice more in no way are we proposing that you have normal node CRUD operations and outside elements. But we did want to offer basically examples of how we're requesting the tokens, the setting the headers and giving examples for each CRUD operation. So we just wanted to offer that maybe as a way to enable people to understand the normal workflow but also essentially what the requirements are. So we tried to make them really simple, really build out the kit in that regards too. We have things broken down by components for Drupal CRUD operations by themselves, namespaced accordingly and tried to isolate the scenarios in a very easy to understand scenario. So if we're looking at here, this is oh by the way, sorry for each of the components we have separate content types. So for CRUD operations we have dogs, no I didn't include cats. For the GraphQL orchestration layer, we included Marvel's API, a comic book sales API and a couple local storage devices. And then for the single relationship we included Pokemon, some base stats and then we also have another user type for basically user accounts that we'll show you guys how we deal with like mock APIs in GraphQL and kind of cool stuff like this. So this is just a quick example of a post request and with yeah any of the entity references you have to make two calls, you have to essentially build it to begin with validate and then retrieve the information back for the final post. So that's what essentially the post is. This is just a retrieval. This shows a little bit more about the content headers. I believe with the last release of JSON API we had to add like one more thing was content type to the headers but other than that nothing really adjusted. You know pretty straightforward as far as like making those declarations in the header, retrieving the information back and I'll show you guys how we have all this information stored not only within React but we also have it within Redux. I'm not sure how many you folks are knowledgeable with Redux but we'll kind of explain how Redux is used within React to maintain state and kind of track different scenarios. It definitely has some cool tools we want to show you guys as well. So with update requests it's pretty much the same as a create request it just needs to change the method that we send the request with. This actually requires that we configure Drupal in a specific way so Drupal's configuration as of I think 8.2 allows us to set API and the rest settings in the settings YAML files so you need to ensure that we have we're allowing the correct headers to actually make these requests as well. So if you ever want to go down the CRUD operations they need to accept patch, put, delete, post and it needs to actually be in your configuration otherwise it will not work. One other thing I think it's important to touch on with both update and delete is that the API doesn't do a confirmation so if you were expecting it to or like in the Drupal UI you click delete and say are you sure you want to delete this it doesn't actually happen in the API which is to be expected but it's just something to be aware of it will just automatically delete your content. No problem though. Cool so now we get into the fun stuff so orchestrating Drupal API data see this slide is called why use GraphQL but I think it's better to say that GraphQL here is actually a content middleware and GraphQL just fits everything that we needed to define for what a content middleware is so in a lot of our projects we see that we have multiple sources for data we have lots of different requirements around business logic on how to display that data and how to actually present it back to the user and what a content middleware will allow us to do is to provide a central place for all of that information so any business logic around how to display the content it's all in in one place it allows and that then will scale out when we need to add multiple clients to make those requests to the content so if we're adding a chatbot if we're adding an Alexa integration mobile app you don't want to have to reproduce all of that logic in each application to make sure that they understand how to read the data how to make those multiple requests to JSON API to pull back all of those reference fields do all that kind of stuff as well so the content middleware needs to be able to handle all of those use cases and provide a nice interface for all of our clients to interact with one other key importance here is that it actually even further decouples all of our clients from Drupal in a way that our front-ends don't even know what they're talking to to retrieve their data anymore and Drupal is purely providing the data to our content middleware so why do we choose GraphQL to do this so GraphQL I'll just go through quick basics run down of what GraphQL is in case you haven't read up on it but GraphQL is a structured query language that allows the user to define data types and it's done pretty straightforward in JavaScript there are a few different implementations in different languages as well but they're all roughly the same so you define your data types you define what fields they are what types of values those fields contain so you know your standard ints strings, floats, all that kind of thing and then what it does on top of that is it allows you to request for specific fields so whereas REST and those kinds of things will return you the entire resource GraphQL will actually allow you to say I only need to display the title so you can just do a query request to the GraphQL server say I only want the title and it will just send that back to you and that's a really powerful thing when you're creating front-end clients you can reduce the chattiness between your application and the back end and then when you start going down different types of integrations while it's fine with the web you can do those requests it's all fine but once you get into mobile apps you're running into restricted network access so you can keep the payloads between applications to a minimal so yeah that's it simplifies that whole request pattern as well another important thing to note with GraphQL is that it's not actually tied to a storage mechanism so where REST and stuff is typically a way to expose the database and the schema of your tables the GraphQL allows you to define exactly how you will pull that information from wherever it exists so you can define an API request to pull some information back so it can go to another service you could have it set up directly to query Drupal's database if you wanted to you could do it have another MongoDB on the node server that can have some data that you want to expose and you can do all of this kind of different things and you just define resolvers on how to actually access that data it's really quite powerful for that and the last thing to note sorry the last thing to note is that while it's mostly around reading data and retrieving data from different sources for it to actually stand up against other SQL languages it needs to provide a way for you to update those data as well so we have examples in the couple kit of how you can actually send mutation requests through to the GraphQL server and how we can then understand those and operate with different APIs to update the backends on how to change the data set cool so like I said we kind of broke each of these components out by their functional purpose right so in the example that we built with the Pokemon we're just dealing, I'm not sure if you guys can see the graphic at the bottom left we're just dealing with the one-to-one relationship as far as having GraphQL in the middle so we'll get to the next example in a second as far as like the multiple APIs but in this scenario we dealt with just constructing things in GraphQL so we could use that middleware layer to define the schema types so essentially most of the work was done in GraphQL as far as identifying those schema types and then defining those queries to accommodate in this case it's just a single request but we'll show you guys how the resolvers are addressed later on and then finally just requesting that JSON API data from GraphQL and as Steve mentioned it was really efficient as far as nested things like taxonomies, images, things like that where you have to typically hit multiple endpoints, accommodate logic, pagination, things like that but within GraphQL it was way easier so we essentially did most of the work within that and then kind of followed that route and then finally we'll get to the React app as well as far as making essentially those queries to call that information we're not really running any update operations so it's pretty much just fetching those nodes but we wanted to show a really simple example for you folks as far as understanding how to do that before we get to a little more complicated scenarios the decoupled kit also has a way as we were saying before a lot of business requirements end up having us talk to multiple APIs so a legacy API internally or an external API that provides additional content to help expose some of the data that we need so we set up a, there's an example there of how it looks architecturally we've got a set of marble characters coming from Drupal and we actually wanted to augment that data with comic book which comics they appear and then another API provides the sales data around that as well so where the GraphQL server can handle talking to Drupal to get the initial result set and then also extending that through to different APIs to resolve for fields one interesting thing to note with GraphQL is that if you don't actually request those additional fields so if we don't say we want the comic books return without request GraphQL doesn't even make those API requests to do it so it's another kind of performance win on the content middleware layer where it's only going to fetch the data that we need present that through to us on our front-ends this is the example that we use to set up a mutation so we can add additional heroes to our back-ends we can go through, when we go through the demo you'll see that we've got a drop-down it kind of is also powered by GraphQL and another different type of data storage mechanism and it will send us through a list of heroes that we can use to add to our source automatically update based on GraphQL knowing that we've got this hero name we can go through the different APIs we can pull in all of that data and it's all kind of automatic after the initial update we also started to as we were developing this we kind of ran into a few issues with performance on the middleware so once you start to add all of these different API requests it's probably not the same if you've got databases that are much faster but API requests end up being slow what we were using is quite slow so we're like how do we improve the performance of our middleware here and that's when we found a set of tools from Apollo that allow us to actually cache those requests in the middleware so it augments the GraphQL schema definitions with some cache tag availability so we can start using a local in-memory cache for the GraphQL server so it doesn't actually have to make those requests again either so we get another performance win from the middleware it's already built the resource that already knows what the data is stored in memory until the next time it clears or until you manually perform a cache clear cool okay so next we'll just jump into a couple topics with like I mentioned before we're not really calling these best practices this is more just the reality of developing in things that we're encountering as we're building the kit but also things in conversations with clients so obviously when dealing with an API there's several scenarios right like Steve mentioned with caching we handled with Apollo but we also wanted to understand what it meant for local development understanding dependencies on outside APIs but also really like you know failover scenarios like what happens if your API is down what if the wrong things are cached what if you know how are we going to address cache busting on non-static elements so we really wanted to try to understand those and include those in the kit which we addressed as far as those typical workflow scenarios but you know as you can assume most of the scenarios are typically with multiple things depending on the speed of transferring data between those things so that's what we try to focus on a lot as far as like understanding the right level of caching not over caching cache busting things like that and also like securing and tracking authentication obviously as we mentioned before it's a big focus but we wanted to kind of segment that information out too you know so you guys can download and understand cool so the big one is API fillover right it's something you know just like deploying on a Friday or slow latency you know like until it's an issue for you it's not an issue right but we need to we really wanted to address like normal scenarios so we I think I want to step back just for a little bit as far as like the high level right so like when we're talking about normal development you're dealing with like scoping and allowing for plenty time for like functional and unit testing it's the same way with like any type of couple structure right like it's really about planning and understanding like stability patterns you know circuit breaker design pattern Steve mentioned to me yesterday the chaos monkey which Netflix uses as far as like just trying to break down your system at different parts so a lot of that is just having the right things segmented for failover or caching things appropriately and understanding things on a timing function so that you are addressing if things are down you can essentially store the last best scenario with that data so the user's not seen any downtime but then also checking periodically depending on the scenario just like normal circuit breaker architectures we also wanted to simulate API connectivity with local tasks I'll get to that in a second but you know we rely heavily on mock APIs GraphQL offers you know something out of the box Apollo but there's a lot of things you can include with react not only with just test and you know other functional testing suites yeah so let me jump into caching mechanisms which we once again all these examples we'll get to in a second but we you know segmented these out as far as each scenario example so this is just a way that we can use the client side caching mechanisms as well so this is just adding more robust failovers for our whole decoupled application so you've got proxy caching on Drupal you've got varnish and CDNs and all that kind of stuff to make sure the JSON API responds well you've got the in memory caching GraphQL because all requests there are post requests so you know setting up reverse proxy caching is a little bit more complicated and then we also have the client side to deal with and the client side has a few different caching mechanisms that we can employ so we've got them here and we've got examples of them in the decoupled kit as well but I'll quickly go through what Caches is a new API that the browsers are providing for us and it actually is designed around caching HTTP requests so it will respect HTTP headers and it will also create different caches based on the very header that's sent back from the API or the HTTP place that you're making the request to the local storage method is using window to local storage and it is kind of a simple key value store in the browser client's browser so I think it's limited to 10 megabytes of data so it's usually for really simple kind of content structures that you go the app can't not have this stuff so we kind of need to put it somewhere in case it doesn't ever make that request again this is the simplest method to implement of all three but it does have a limitation on the size and it's much more restrictive than the other two and finally we have index DB which is an in-browser relational database that is limited to 50 megabytes per browser and some browsers have slight variations but on average it's 50 meg and then you have a full API around creating a local database for each browser that makes a request to your application this is quite complicated and it doesn't use promises which most new applications that you're developing in JavaScript will want to leverage your application because it makes controlling the flow of the application much better, much easier so in the decoupled kit we actually found a library that will help add promises around the browser's API for Windows index DB and it's called DEXI so if you ever download the kit you can have a look at DEXI and see the API that it's got which is quite useful and quite easy to use as well cool so I'll touch on this real quick you know I know Mock APIs are synonymous with sexy development why use Mock APIs I'll let you guys read through the list but essentially we're trying to emulate things on a local development level but also working with other teams and external APIs can be a bit taxing as far as rate limits and things like that so we want to kind of address a way to simulate data as we're testing but also like say you're creating a jura ticket and you want to scope out what does it mean if we change the API and construct it this way well Mock APIs are great because we can actually you know if you're working with another team and we're understanding what needs to be requested we can actually Mock that up with a proper schema and the right tools and offer up that data to essentially demo and say okay would this work you know and especially when you're dealing with like external teams or external dependencies you don't want to be you know throttled by whatever's going on with the other you know scope or the like testing coverage is obviously big not only with continuous integration but local development so we want to like really focus on like you know for the proper times understanding run through like Mock's you know retrieving basic data and not getting too complicated with it but at least address addressing the main like breakpoints as far as like hitting the right things with the circuit breaker scenarios just so we're understanding things. Here's a couple methods that we took a look at tools package so we're using that as far as like emulating the user information but there's a lot of different options right like with react with react-adjust you can test things node comes with JSON schema faker and also node you can just use JSON server to use like a JSON file and it'll build from that schema construct and serve up that data for you for local testing cool all right so now that we've talked about the coupled kit for 35 minutes we're now ready to show you guys Steve do you want to cover the GraphQL stuff for first yeah we can quickly go through this so this is if you run your GraphQL server in dev mode they give you a schema browser called graphical I think it's a browser yeah and this kind of let you just kind of really quickly query that the schema types that you set up so you can go through and you can show exactly what fields you want what fields are defined and how the server should respond to those things as well so if we step through this we can kind of see that we won't go through the code but I understand like I know that here the ref types is an actual another reference field in the Drupal JSON API so this is just kind of showing us that we pull it all back in one request we make a query with all of these fields and we need them all to display our to build our front end API our front end UI and it will automatically make that request to Drupal again to pull the ability types back it will make that request again to pull the ability types back and it will do that all on the GraphQL server and this kind of just explains how that works cool yeah and with the kit we also included a bunch of documentation not only within the code itself but also we built up a lot of readme files and read the docs if you guys ever use it it's pretty rad so we tried to step through the code as far as like what are we trying to do this function does this this function is expecting this we're expecting here just to you know essentially communicate and help everyone understand our typical workflow and our thinking as you know as far as the time we were building it yeah and the code has pretty good documentation as well so if you pull it down you're all if we've ran into something that we had issues with we kind of documented out our approach and why we chose a certain way to solve that problem yeah minus the curse words so if we look at the first example as I mentioned before we have things kind of broken out as far as this is essentially not using GraphQL at all it's just dealing directly with those JSON API calls so we have like an example for each of our dogs as far as like creating a new node looking at retrieving a list of nodes with each dog and then using React to essentially like build build in have an editor there upload a new image and also removing the node so we we broke these out like in a very simplistic way but you can definitely get way more advanced with a lot of these things we just wanted to at least for the baseline communicate that pretty easily and then get a little more jazzy on the feature branches yeah and it shows you how the interactions work with Redux as well so we'll go through the action flow from Redux and we'll go through triggering an event with Redux and sending that through and then sending that back to the front-end so it updates and manages the state that way yeah and here's the Redux toolkit the window is kind of small but it's kind of neat because you can actually bring things through as far as like the state timeline and actually emulate you know like the typical workflow of like retrieving the data interacting with the data and you can actually step and debug back through the code as far as how that is updated within Redux so as I mentioned before this is the one-to-one relationship with the Pokemon data and so we essentially have like the query here with exactly what we're using in GraphQL as far as fetching that information from GraphQL on that proxy layer and then each of these is just like a node example as far as expanding it down showing the different attributes things like that not all the attributes but just a couple there's a lot so at the bottom we also have like a quick example as far as like we wanted to you know a lot of us are you know started out or mainly Drupal developers we wanted to show like some pretty simple cases but clearly communicated cases as far as like React how we're doing like data comparisons and things like that so we have just you know like a real simple game as far as like matching one-to-one like he would be the winner based on attribute but we definitely have some stuff upcoming that's a little more you know verbose as far as like visually cool so Steve yeah so this is the example where we're synthesizing data from multiple APIs and we've got little badges on on each row where the the data comes from so it makes a request to GraphQL and it says that I want the comics and the comic sales and that will then fetch those requests as well and we've also got here this is adding another this is a mutation so this is an example of sending a mutation query to the GraphQL server it setting it up doing that inserting that node into Drupal and then we have access to all this other data because those services know already that Black Panther is a Marvel character and the APIs know how to pull that back so really quickly we get all this extra information without ever having to migrate more of that content back into Drupal we've got the middleware there pulling information in from other things based on how we know the APIs work cool yeah and just to be clear like a lot of the work too with as far as like synthesizing the data it was mainly declared in GraphQL right like so yeah most of the work we're looking at different services there's a lot of obviously different services you can use but we want to use things like Marvel that had large data sets but you can do a lot of really cool things as far as like having like 10 different APIs that you're essentially blending together and constructing it away in GraphQL it's like really really easy compared to just dealing directly with hitting those endpoints you know one off yeah and if you also download this the decoupled starter kit this is the page that is leveraging the Apollo cache as well so you'll see that the first load on this page will be pretty slow because that's a lot of data that's pulling back from a few APIs but every request after that will be pretty quick yeah I before we used Apollo I think we were at like 40 seconds yeah yeah it was a couple tiers in our eyes but after using you know the right configuration layer for the caching definitely got a lot better so this is our example on the different caching mechanisms in the client though so this is the browser's cache here window.caches we've got a bit of a write up on how they work so windows.caches requires a service worker which is also a new concept in JavaScript land so that basically the browser your website will deliver another JavaScript file that the browser will run outside of your page and it will set up a few different environment variables for that browser tab and what it does here is it actually creates the cache for our frosties window.caches after that we've got the local storage one and that's just simple key value pair that stringifies the response from the API and the last one is actually using a local database you can actually if you open the developer tools you can see how much data each one is using as well and Chrome has some pretty good developer tools around this stuff I believe it's in memory cool yeah with the API DocMate Datamock as I mentioned before we're using GraphQL but I've used other JSON services as far as far as marking this up we have most of our variables just included in a local .env file which you can obviously use for hosting deployments to contextually switch between different APIs but for our local storage we're just using a couple different variables not a lot a couple key pair values from Apollo and for this one we set mock to true it's just a true false and then based on that it will actually build whether we want to use real data from GraphQL or GraphQL to generate the mock data so that's essentially this example we jumped into a chat box integration too with the Pokemon data just for fun really this one shows another client that's talking to the GraphQL server to pull information back you can see there that it made a request and it knows it asked for the field speed into the GraphQL server and it pulled that value back we can start interacting with our content in different ways this is the example that we recently set up and it kind of shows the workflow of an OAuth request making sure that we can generate a token for a particular user so if we log in it'll actually redirect us to the Drupal site we're already logged in here so it'll ask us to grant the permissions, we grant them back and it sends it back the token it sends back an access code which we then use to generate an OAuth token which can then be used to request information from the API on behalf of that user so we see here that Drupal roles has too, it has premium and authenticated so one thing I didn't touch on when we were talking about OAuth is that simple OAuth uses Drupal roles to control scope so in this case we asked for the premium scope to be added to the user's token when it generated it and what the simple OAuth module will do we'll actually do an intersection between the roles that the user has and the roles that you're requesting so in this case if we log in with the standard user so we've got two users here, standard user doesn't have the premium role even if we do request the premium scope simple OAuth won't generate that token with that scope so this content here would not be visible to the standard user and that's it let me check time real quick okay cool, yeah, I wanted to allow definitely allow enough time for questions if you guys want to kind of jump into it that a couple kit is here for download but yeah if you guys have any questions please hit us up afterwards we can talk over Steve Febier and a Zima for me because I'm a gentleman but yeah let us know if you have any questions just hit us up too on Twitter or you don't use Twitter yeah anytime after the conference at the booth we will have a demo again in the booth tomorrow I think is it 12 o'clock so if you have any questions we can't answer here come up and have a chat yeah and when everyone's downloading and trying out the different features we'd love to hear feedback we're definitely going to make this an iterative process as far as like adding new features exploring different architectures which once again is just to help enable other people provide feedback contribution things like that we'd be super happy as far as like if you guys have any information you want to transmit back to us so we can help include in our roadmap yeah thanks yes sir is there any reason to choose React as opposed to Angular or something like that as far as Drupal is concerned or you know for any reason not really it was just a personal preference we wanted to use GraphQL so we thought it you know yeah and Facebook so trustworthy we decided to go with React but no yeah no it was just essentially just a preference I have worked with Angular in the past before so we wanted to essentially try React to understand like Redux especially with the binding of the data within the API so that was the main reason yeah and hopefully we can get in and write a framework similar to the React one with the other front ends as well so we can use View and Angular and there will be a different starter kit kind of thing for each different JS framework yeah precisely yeah so with JSON API you're passing structured data but it doesn't directly address handling serving up files like CMS managed files including images and PDFs do you have a philosophy or suggestion about how you would do that and do you proxy it or like in our case for Edutopia we wound up spinning it out as a separate service yeah up to this point probably our opinion would be the same just because what we discovered was not only with like the complications of doing like the round trips just the caching was an issue dealing with like a CDN because you're essentially sidestepping what you can do in Drupal and sort of those assets or address it CDN we tried a couple different scenarios I think currently we're just using like file entities but we I think next like number one party on our list is look at different ways to address that so we'll probably have examples as far as like serving it up even from like a third party CDN or something like that just to make it easier but that is yeah definitely one of the big you know bombs yes sir you probably have total control of the data coming from Drupal my question is could you have used the GraphQL server to grab data straight from Drupal instead of going to the JSON API you could you'd need to expose the database to remote requests but you can do that as well so there are node there are node packages in this case in our example we're just using a Node.js server for the GraphQL server there are node packages to integrate with a MySQL database so you could have that queried directly to the MySQL database to pull those fields back and that information back as well you don't need to go to JSON API but it's not part of a kit right now not right now thank you any other questions yeah cool awesome well yeah thanks everyone yeah absolutely thanks so much I really appreciate it thank you thank you first time ever for that thing first time was it alright yeah thanks thanks thanks thanks thanks thanks thanks thanks thanks