 First, thank you for coming. I tend to move a lot, so I will try to keep closer to the mic. Well, thank you for coming to this session. This time we are not going to talk about Drupal console, so you are in the right session. I think we're not even talking about Drupal this time. We could churn if you weren't. Yeah, it's this is a really fancy name with a lot of boss words, creating a modern web application using Symphony API platform, React, Redux, and WIMS something, right? Yeah, we have a bonus we didn't promote, so this is a surprise for people who sacrificed your lunch for here, so we are going to talk about a little bit GraphQL. How many people are excited about GraphQL? We shouldn't be. You are my friend now. Okay, let me introduce us. This is Jesus Manuel Olivas. He is our head of products in a company called Winno. You can contact him on Twitter and GitHub as GM Olivas and Drupal user, and this is his blog website. And Eduardo is joining me this time. Eduardo Garcia is our CTO from Winno Company. Again, this is all of places where you can find Eduardo. So, about what we give, as we say, we are the Winno and us as persons, we are the maintainers of Drupal Console. So, thanks to the community last week. Okay, thank you to the community last week. Sorry? Yeah, closer. Okay, so as we mentioned, we are the company and the main maintainers of Drupal Console. So, thank you for the community. Last week we reached this number, two million downloads since we started the project. Maybe the most interesting thing about this number is like eight months ago, we reached our first million. So, now we are in two million, so let's talk about the reception of this project about the community. So, if you are interested in more details about the things that are coming about Drupal Console, please feel free to try to contact us. Like, for years, getting the first million, which is the hard one, the first one. Where we are? Yeah, so we are a distributed company, we are fully remote. As you see, we are basically in America, but we have a couple of resources in Europe, France, myself in Australia. This is basically going with it, we are 36 resources. And what do we know about? Yeah, so as we know, as maybe you know, and you think we are a Drupal company, but actually we do more than that. This is why we are creating this session. So, basically nowadays, every Drupal company is a 80% Drupal company, but actually it's doing more than that because Drupal is an integrated system. So, you can see the map, the CMS is 28 resources about that. But we also have people working in React, working in Angular, working in React Native, working in Angular. And also, people are having different interests. So, people are doing crazy stuff, like trying to connect Drupal or Symphony with artificial intelligence with Python of this kind of stuff. So, this is the mesh that we have been talking about for the last two, three years. It's like a create bridges, live in the island. So, now we are using these bridges to try to get connected to everything, and this session is about that. Yeah, well, again, we're going to, topics that are going to mention is API platform, the Symphony API platform, which is a framework that will allow you to create out-of-the-box and rest endpoints and graphical endpoints. So, we are also going to talk about GraphQL, and this is the tool we use for the API part, for the front-end part. We use React ES, Redux, and Saga, and for the components part of the UI we use and design components. And this is most like a recipe we have for building projects. Whenever we need to create a project that requires to be in API and there is not content-centric, there is not content management, there is no revision on the data. It's mostly like we need to put data on it and then somehow interact with that data from different places, like from the mobile, from the ZLI, from a web app. So, this is what we tend to use instead of going to Drupal and use headless or decoupled Drupal. It's kind of like decoupled Drupal on the Symphony way of doing things. And how we reached this solution of this recipe, as I mentioned about the bridges to leave the island. So, actually we started using Drupal with React, then we noticed we could use React with Symphony, then we noticed we could use React with Node.js, and then we noticed we could do Node.js with GraphQL. So, we were really far away from Drupal, and now we decided to say, hey, we could do the circle. We're going to use Drupal and Symphony with GraphQL. So, that's really, even if you are not using Drupal, you are not at the factor, right? So, you are trying to reach the technology and close the circle to try to integrate the solutions to provide the best solution possible for your clients. Yeah, in talking about Symphony, this project is based on Symphony Flex. I don't know if you are aware of this. There is latest version of Symphony, Symphony 4, but they also have a project they call Flex, or Symphony Flex, which is basically a Composer plugin that allows you to automate some of the most common tasks. Kind of like, you know, it makes changes and improves the Composer Require, Composer Update, Composer Remove commands, adding in, whenever you enable a module, copy some configurations to your project. And, well, the main difference you will find out with Symphony Flex is, as the director structure is a little different, you will find out a config directory on your root project and the root of your project, and this is where all of the bundled configurations are located. Other than that, it's pretty standard Symphony installation. Yeah, let's talk about the platform itself. So, API platform. As I mentioned during the beginning, it is a REST, a GraphQL framework, allows you to build modern API projects. And a good benefit of using a tool, the same reason why we use Drupal, we use Drupal because there is a community, there is a lot of modules that we can take advantage of, same thing with Symphony. By using the API platform project, we can take advantage of other modules to interact with the project. It means if we're required to login, there's a bundle for that, like user login, if we require authentication, or extending the authentication using a JWT tokens, there's a bundle for that. So that's the big benefit of using a project like Symphony Flex in this case. And the project, it's breaking into four pieces or four components. The API, which is the piece that we will be talking about, there's a schema. I mean, it allows you to use default schema, I mean, compliant files. So you can use, I mean, automatically out of the box, use those and, you know, populate your database, doctrine database. It also includes an admin interface. It react fully, I mean, functional, create, retrieve and update and delete the interface. So you, without doing nothing used by exposing the endpoints, you will be able to interact with this. It allows you, like, a form for adding and editing fields. It also adds this crew generator. It's a JavaScript scaffolding tool that allows you to create, I mean, react components. And in order to use the API platform, it's way too simple. I can say, you don't need, I mean, like, 30 something clicks like Drupal. It's just git clone. And you are all set. The minimum adjustments that we tend to do is change the route. So we point to API, something. And since we are changing this configuration, then we change the data entry API endpoint for the client application. And once you git clone the project and make that change, the only thing you need to run is compose, Docker compose app. And well, you have to wait a few minutes or probably more than a few minutes, because it use Docker and it's pull, I mean, I mean, we'll start pulling images and all that, but you don't have to worry about, like, setting up nothing. I mean, out of the box is fully functional. And once you finish this process, you will have something like this in your, in your local computer. This shiny page that is telling you that it's installed and it's fully functional and it's worked. It might be what you, the first thing you want to do, it's adding more format. By default, it supports LD JSON and JSON format are pre-configured for you, but you can add way more formats. And those are the available formats that you can use. And as in any symphony configuration, when you have an array of values, the first one is the default value. So if you want to use LD JSON as default, you just put it on the very top. If you want to use JSON, just move JSON on the very top of this list and you are all set. And everything is configurable through YML files. Well, might be, since you are building an application, the next thing you're going to do is to start adding entities. In order to add a new entity, as in, like, you know, something like an entity in Drupal or a content type if you want to, you need to, in this case, you need to create a class, a PHP class. So this is, you know, source entity directory is the place where you store your classes. It's a plain PHP file. The only thing you need to add is annotation. You know, this is an entity allowing doctrine to discover this new entity. And that's it. And I highly recommend, we highly recommend you to remove the default entity that is part of the project, which is great. So let's say for the purpose of this example, we are going to add these three entities, post, post type and user. I mean, we're not trying to build in a CMS. It's just, I mean, we're using like similar concepts that you are aware of, like, you know, like Drupal, you know, post and post. So we're going to try, we're trying to use those concepts here. And remember Drupal hook update? Well, Symphony has something called doctrine migrations model that allow you to, to store on your, on the file system, all of your changes, or your database schema changes. So by running, let's say if you add a new entity file, you know, post that PHP entity or post type that PHP entity file, you just need to run migration doctrine migrations diff and this will create a new file for you. And this file will contain the schema changes. So later on you, you just need to run migrations migrate either you or the rest of your theme or when you are deploying your site to production to apply those changes. So it's basically like updating, allowing you to store on the file system and commit on your, allowing you to commit on your repo all the databases schema changes and, you know, translate and move easily between environments. Well, and as I mentioned, one of the reasons of using Symphony is because there's a lot of bundles for adding an extra functionality. Since we're building an API tool, we require to have a login user login, I mean, interface or using login functionality. So in this particular case, we are, I mean, we suggest you to use false user bundle. If you don't want to, like, grow and write all the integration yourself. And if you are using false user bundle, you need to be aware of this to blog post. I'll share, I'll post the, we'll post the slides on the, on the note page of the session. The first one is the official documentation of the bundle. And the second one is a bundle that is telling you that you should not use the bundle. And it's, in the end, it's not, it's not telling you you don't use it. It's telling you, I mean, the benefits, the pros and cons about using it. I mean, they claim there's a lot of fields added to your, I mean, table that you might not need. So good, I mean, a good, I mean, having a better understanding of what you're doing when installing a module or a bundle for extending your, your project is a good idea. So this is a really good read. I mean, you can have a better understanding of what you're doing. You're adding legacy code to your project. And then you can decide either to use it by knowing what is happening or use write one yourself. And another thing we tend to use a lot is creating commands. We like to automate things, you know, within, or at least I think whenever it's human involved in a process, there are chances or errors. So we like to automate things. In this case, we create, I mean, one single command to initialize the whole project in symphony. Same thing we use in Drupal, Drupal console. So we create one command, which will take care of running the database migration and executing all those migrations and populating data on their, on the entities. And for populating data with fake data on your project, you can use Alice bundle and basing, basing a faker bundle. Let's move to something more interesting. Yeah, let's take a look how the, how they, I mean, the project looks like, remember what I told you, use Docker compose app and just create those three files for the entities. Once we have that, and if we do something like this, so this is how the project looks like. So whenever you go in for the initial page of your, or your endpoint, which is in this case, well, API, API, you will see something like this. All of your entities are listed here, and you can start playing around with those. So it means if I go to post and want to try out, I can try out here, and this will execute. What I will see here, they will show me the result, the result of all the data. Well, this is really important because when we install those system, we spend a lot of time to try to figure out how to access and what results we have to have. So visually and quickly to try to have a better idea about what is going on and what specific data you already have, or you could do compared with your database to try to be sure that it's the same. And if you want to change the format that you are interacting with the endpoint, you can just, I mean, change it here and just execute it again. And I mean, for any new endpoint that you have, that you register or any entity, you have, I mean, all those endpoints available, something API posts. If you want to load the JSON format, you can go post.json. If you want to try the JSON-LD, then you can try post.json-LD. I mean, you can do this by the CLI or your application by changing the content type that you are, I mean, calling. Now I'll show you how it looks like. And if you want to load one post, I mean, one single post, you can do something like API, then entity, name, and then the ID. And for making calls from your CLI, remember what I told you about the reason for us, for us to building an API project is because we know we want to interact for different clients, in this case CLIs could be a client. So you will do a get, you know, you can use curl or wget and then using get and you call the endpoint URL and you can specify the content type that you are accepting or you are requiring for the endpoint to give you back. In this case, you can use JSON or LDJson. And for adding posts from the CLI, it's the same thing, you can use post, the post method and then you just pass the post, the URL, and you can start iterating here. As you can see here, we are passing the data we want to insert. So in this case, we're telling, you know, let's post in this URL using JSON format. I mean, and I want to use JSON and LD for passing the data and we can specify fields or, you know, property and value that we are passing to the endpoint. And for updating and removing posts, same thing, you can use HTTP commands like put, delete. So I mean, everything is there, it's out of the box. You don't have to do nothing other than just make your entity, enable your entity. It's a matter of adding an annotation in your entity and that will be automatically discoverable by the framework for you. And when you're using REST, as you can see here, when we are calling an endpoint, let's say like post or a single post. And you have entities and you have nested entities, you know, like in Drupal, we have relations, we have a field who is pointing to another entity or content type, which is related by an ID. In the case of REST, most of the time what it happens is you need to do like two calls. The first one for getting the main entity and another call, another REST call for getting the relation. In order to fix this problem, the API platform allows you to use the serializer component of symphony. And by using an annotation and something they call normalization context and denormalization context, you can create your own groups and say, you know, when I'm reading, when I'm using the endpoint for reading data, I want to enable this relation and instead of showing me the ID, please go and, you know, pull the data related to this entity. You know, it's like a relation, but it tells you, so it brings you back, not the ID, it brings you back the data from the related entity. The downside of this is you need to add, I mean, a single annotation to every single field that is an entity, I mean, is an entity relation or one to many relation, which is kind of, I mean, could be kind of cumbersome, so we decide to instead do something else, which is GraphQL. Exactly, so it's not like the other solution is not working, so it's totally usable, but we were thinking about exploring another option to try to do things easier as possible. So GraphQL, if you're not familiar with that, you could think about like a middleman or is an abstraction layer between your client or your backend, in this case, is symphony. So that's the solution we're going to explain here. You could take which part you want, if you like the server side, key with that, or if you like the client side, key with that, and you could use GraphQL on them in the backend, could be anything, because GraphQL is an abstraction to allow the client to decide exactly to take whatever they want from the server. Instead of to try to be aware about how many fields are going to receive, if it's going to work or not, so this is especially good for GraphQL. Yeah, I mean, when you use REST and you call an endpoint, the endpoint returns you all of the fields on the model, and maybe you don't want to, I mean, you don't require all those fields, you might just want the title or body or something with GraphQL, you can just select exactly the data you want to fetch. So the idea is that GraphQL, the foundations are in two concepts. First is types, so you just need, types is something like a unit to define, so maybe in the other side of the server is a FORTRAN system, it's a database, it's a text file, so you just define what are you going to return to the server, to the client from the server. And the other thing is the resolvers, which is how it's a function to help you to combine all the sources to try to return the specific type you want to return to the client. The good thing is using this package, the Webonics GraphQL PHP, integrated with API platform, all this matter is resolved for you. So using this doctrine schema, so you don't need to be worried about that because in other GraphQL implementations, obviously you have to write by yourself because we are using a symphony solution, you just, you take the solution you already have, you install this, and then GraphQL is ready to use, easy as symphony. So the whole process we have covered until now could be the outside the Docker part, could be five minutes or less. And the composer part. So the same way REST endpoints are automatically discovered by the platform for you, same thing for the GraphQL endpoint, so you don't have to do nothing other than adding an annotation, which is like, you know, and again for the endpoint, and that will be for the entity, sorry, and that will be automatically discovered by the system. Yeah, so after installing the package, as the same way we did with the API platform, you need to define what you, if you want to expose, this is GraphQL, what I am going to show in a minute, the theory is only for development, because this is a helper for you to try to build the queries you are going to execute with the client into the server. So when you are going to production, please disable. Yeah, make sure you're disabled, unless you want to expose your endpoints of the world. Yeah. Okay, so the idea, this is a typical query that you could do with GraphQL, so you have, you need to provide what resource you want to do. So in this case, with, because it's symphony, so in theory, GraphQL, no, in theory, no, it's real. So with a regular rest, you have many entry points, and you could attach and then a sequentially request, but in GraphQL, you only have one. And then you need to decide what resource you are going to get. In this case, this is a call for a specific post, and we are getting three fills, right? So you could think about this, like maybe you are doing a mobile application, and this is the fill release. This is something for iPhone, all version, and then you get those three fills, and everything is working. But later, you can add more fills. Okay, but later, maybe you do an next I direction in your application, maybe you're more rich content. And then remember what we do with serialization, like I use the reference with entities. So in the resolver part, which is, is already did for you, because for the component, you could decide to try to get more rich information. So imagine you have two clients, two different versions of the mobile application. The one client, they have the last one, but the other guy, for any reason, he already have the old one. The idea with GraphQL is that both will be functional, because the client is deciding what he really wants. So this is the second version, and then you decided to provide information about the machine name of a related entity, and now we are getting more information from our server, if we want. And if you see the ID in this case is the resource you want to try, it's the same. It's just like the way I like to think about GraphQL is like the client is the boss, right? So the back end is just, is just to provide whatever you need. So as you can see here, we have two, two different calls to, to the GraphQL endpoint, we are fetching some fields in here. And in the other one, we are fetching different fields, as Andrew mentioned, you can even take like, you can fetch related data, any field that you want to, you can remove fields from here. So you are not fetching the whole data that you, that your REST, as REST is doing it for you. And well, if you want to use the CLI for doing this, or in your project, you can make sure you also, you can specify the content type, which is the type that you want to get returned, like in this case, I'm asking for the GraphQL endpoint to return data in using JSON format. And I'm passing a query. So this query that you can see here is the same one we have on the, on the Graph, Graph, GraphQL part. Okay, remember what I told you about users, so we enable that false user bond, right, which just allows me to interact with the system by providing a user in files where it also takes care of creating the database that require tables and all that for me. Might be, I mean, but in this case, we're building a decouple application. It means we have an API in one part, and we have the client in a, in different part. And in this particular case, we are using JavaScript for using the client, which is a totally different technology. For this particular case, we use JWT will allow you to log in a user by providing a user and password and return you back a payload of data. And that they include a token, which is like an ID. And you can use this, this, this, or that ID for the, I mean, following interactions with your client. It means you set your user and password, read the value that returns for you. And that value has a time, I mean, time to leave like, say, like an hour or 30 minutes, it depends up to you, how do you configure. But basically, you keep using that ID, instead of keep passing your user and password for the upcoming request. And in order to do this, we use those bundles. So again, same as RuPaul, there is a, there is a module for that. When using symphony, there is a bundle for that. We're using those bundles for the first one is for providing the authentication, what allowed me to expose an endpoint that I can call and will return me data. And the other one is the refresh token bundle. So we introduce this bundle to avoid forcing the user to reenter his user and password credentials whenever the token expires. So this bundle allows you to send the old expire token to the application and returned you back a new valid token. When using JWT, I mean, you might want to change the payload data that it returns to you so you can create a new service. I mean, same as in RuPaul, fortunately, because RuPaul is in symphony components which register services, creating a class and then registering a definition on a YML file. So what we tend to do is creating a service, tagging as a listener, and we on the on create method that we implemented, we can change the data that by default the JWT2 project is returning. So you can add, let's say you want to add the organization ID of the user, you want to add the role ID of the user, and this will return you that data the first time when the JWT token is created on the system. And sometimes what it happens is you can probably create specific data for your token, but you don't want to fetch all of that data. You can change the payload that it returns for you when asking the token data or the values that contains that token for you. So you can use the same thing, you create and register an event, you tag as a service, and you change the payload that is returning it for you. But maybe when we talk about server side, now let's talk about the client side. So we want to talk about some combination with React, Redux, Redux Saga and Andesign. Maybe the less popular here is Andesign, we will talk about a little later. When you're in here, it's in video games. Are you aware of Overwatch? Yes? No? Okay. So this is a framework created for Alibaba, the Chinese e-commerce company. So they are investing a lot of technology in open source. So how we ended up here, we ended up here because we are starting using Andesign. And then we found that like we want to have all these products with React, with GraphQL, with everything. And they create a micro framework to try to wrap all technologies in order to create a rapid development using all these solutions. So check it out later, the URL. So the good thing is when we started this, everything was in Chinese. And then we learned Chinese. Yeah. And now it's in English. Now we are learning English. Actually, I found it because I, yeah. Yeah, I mean, last year, a year and a half ago, every single issue was Chinese. Actually, there's a pose on Medium. You know, this is a great project, but all the issues are Chinese and documentation. And they really took it on the good way and they improved a lot. So now the issues are Chinese and English, documentation is English. Two years ago, when I started, everything was in Chinese. But it was so good that I said, okay, Chinese is not a problem. I could use the translator to do that, but it works like a charm. Yeah, seeing a lot of people is using it. It's pretty awesome. So as I say, the travel is like in this side. It's circular. We started with React, which is famous for everybody. And at the beginning, I would try to find a set of components to allow me to create a complete solution. It's like Drupal for CMS because there are too many dispersed components. Maybe we reduce our development time in terms we don't need to redo the code, but you need to spend a lot of front end to try to make all of these components look similar. Like it's your complete application. So you are losing and gaining. And also you need to learn any specific API for this specific component. So the inputs were different than the slider. The calendar was different and blah, blah, blah. So what this guy did and designed is they have components for almost all the things you could imagine. They have a consistent API, a consistent user interface. And it's easy to try to replace the look and feel using less. A consistent naming convention for parameters and properties, which is just great. It's just awesome. So we started using React. We started with design. We say, okay, we could use Redux, which is to React itself have a simple state system. But if you want to create a complex application, Redux is the best to try to have a complete state system across the application. And Redux Saga is the evolution to try to easy access and managing your state to facilitate your development process. Yeah, because when you're calling end points from your grading actions, then you end up adding reducers and creating namespaces for your state. Because in the end the state is just an array, JavaScript array that you interact with. And we find out using Redux Saga help us to do the API calls and then doing calls to update the state. So basically the whole recipe here is pretty straightforward to use. I'll show some code. Don't worry about if you don't understand what you see because it looks pretty darn thing at the beginning. But once you find out, I mean, start getting like, use is pretty straightforward. It's like Drupal when you start, it's like, wow, what is this thing, it's monster. It works, it works great. Yeah, so the DBA project, the Overwatch stuff, so they provide a solution on, as usual, it is not a perfect solution. So they use something Rode Ho to try to automate stuff. Which is another Overwatch character. They have, but we found that it was difficult to try to create like a global configuration or something. So we disabled that and we use Webpack, which is pretty famous, pretty famous for that. So we use Apollo Fetch, which is created by the creators of Meteor.js in order to get the connections from the GraphQL in this case, the symphony server. As you say, we use JWT, the code in order to do the login to the application. We use local storage for simple storage, obviously, and for more complex objects and interaction in the application, we use indexDB. Also, there are other solutions. Yeah, indexDB, it's pretty much like the definition or the standard and there is like, you know, same as in Drupal. Like hundreds of packages on NPM that you can use. I mean, just pick your weapon of choice. And it basically allows us to store or even for encrypting data on the client and also for more complex structures. And the last part is something that I like a lot. So at some point, unfortunately, the symphony GraphQL implementation or the symphony platform GraphQL implementation, it doesn't support subscriptions for GraphQL queries. So we end up adding to the recipe Redis. So we use Redis on the PHP side for queuing messages using emitter, so emitting messages on Redis. And then we use WebSocket on the client side to reading all the messages on the client application. Because again, fortunately, it's not supported yet. There is an issue for that. We'll probably jump into the issue and try to help if we can. And if you can as well. Yeah, so the theory about all this solution because every single point of here is like a, it's a nightmare for a lot of people because there is not a cohesion we could find in Drupal or symphony. So only the socket EO is like, oh, I need to start as preserver. You need to do many crazy things and everything looks like isolated and not stable and impossible to scale. But using these solutions with the DVA and all this, everything is getting better and better. So we take a lot of these techniques, socket EO and Redis and everything in another implementation we have with Meteor.js and using React. So as I said at the beginning, the idea is like a you could jump technologies and you could reuse the logic you use to solve in other projects. So before to use GraphQL, we use DDP from Meteor and words for front solutions to connect with .NET, with Java, but in PHP, no. So we have to jump. Because you're a client. Yeah, and then that's what we find out about GraphQL. So we were like, how we expose an endpoint from this MongoDB and meet your application. You know, guess what? You cannot create an endpoint. And then why don't we use, I mean, and arrest endpoints. We find out about GraphQL. We start playing with it and we love it. So we start using it as well. How the application looks like, it's kind of like this. You have a directory structure, SRC, where all your code is located. The most important files here is the index.js file, which is the main entry point of your application is like your phone controller. Like your index.php file. And we also have, we also use to a constant.js file. This is where we replace RedHot for Webpack in order to be able to define these variables to be used by the client application. Yeah, because we have configurations on the application to behave on different on development and production on our stages. So we use, do a heavy usage of, I mean, EMV variables. Well, we also have the index.js file, which contains your application definition. We create any object here, like app equals to DB object. You can pass, I mean, initialize your state values here. And then we register the global models. In this case, we have out, which is the model who takes care of the authentication, login and refreshing token. The local model, which is basically any data list that we are showing on the application. That is not controlled by the user, if not provided by the application itself. Let's say there's a list of something, which is default by the application we provide. We use a local storage mechanism for doing that, for avoiding too many fetches to the endpoints. And we... Maybe you could think this is a structure. So obviously this is pretty, is far away from a simple JavaScript file to load your application. So remember, when you create Node.js application, it's more than a single jQuery file. So you are creating a pretty complex solution for the client. When I saw bigger projects, it looked like a very professional, like a symphony of big application. Because from the client side, you have to resolve many complex things that in our side, in symphony and PHP, it's easy to solve. Another important file is the router file. So the way we manage, we create objects for routes, and we register those routes dynamically. We separate the object, the login object, and in the next slide I'll show you why. So we have a login object and then the route object. And as we can see, this array takes care of... It's for dynamically loading the different application components. Let's say this is the component for the entity. So we dynamically load it here. And then we have this iteration where we are using, you know, routes map function for iterating the values and then rendering my component for the routes. As you can see here, we separate those because we have the login route outside of this out route. So this is an custom component that we wrote. I'll show you how it looks like. This component, it uses or extend the route, the default route component. It also allows you to asynchronously call a promise function, which is basically the one who takes care of review. Is your token valid? Then the route gets loaded. And if it's not, as you can see here, I mean redirect you back to the login. So this is only calling a promise, a unit's promise, this, then something, right? So if this is true, then let you go. If it's not, then let you drag it to the login. Well, we have the component looks like this. This is how we interact with the state. We have a function. We define the namespace for the entity we want to interact with. In this case, pose. We define the default initial state here. And then we have the reducers section here. By using Redux and Saga, this is how you interact with your state. We have this class with the reducers function here. And this is how we interact with the state. And make sure when you are interacting with the state and react, you don't change the state itself. You create a new state every single time. It allows you to move back in time and see how your whole application is behaving and changing while using it. And then this is a section on your class definition. It's called effects. So this is the place that you will be, or the function that you will be calling in your system. So your system will be calling something like pose.fetch function. And this is the place where you have the proper code to calling your endpoint. As you can see here, we have a GraphQL query. So we're calling pose. We're telling GraphQL to return me back the first 10 values. And I want to see those ID, ID, title and body and the type. Remember the GraphQL query we showed you before? So it's the same thing here. And finally, once you return this data, you create this object list for returning the value. What? Yep. You end up using the put function to update your state or to create a new state in your application. So we basically go here. Pose equals to calling the fetch function. Right? Remember the fetch function that we created before? And you call it here. I mean, you return this and return this as a list. So we create this map functionality to extract some data and manipulate some data from the GraphQL endpoint to create a plane array for us and then store it on the state. And then your components will be looked something like this. You will have different directories within the components directory. Different directories for a specific group of components. And for one entity, we tend to use something like project base, which contains all the logic that could be functional. You have that controller base in Drupal. And then edit list in new. I think we can show some example. The idea is we are going to show you an internal application we are working on. So this is... This is how the GraphQL work looks like. The idea is you could use the download, the documentation explorer in order to inspect what items you have available to search. You could use the search area in order to try to build the query. So this is connected with the specification. If you are trying to write something that is invalid, immediately you will get the error. And it is out of complete build on. Yeah. So actually this is the idea of how they call Graph, right? For me at the beginning it was a little complete weird. This is GraphQL. Why GraphQL? And it is because it is everything GraphQL. So this is a symphony application using all the techniques we mentioned. This is how looks and design out of the box. Let's see if the internet allows to login. Because internet... Yeah, it is login. This is going to create... This is a system who is connected with Bitbucket, the Jalosha, and others. So we are enabled the integration with this website with GitHub. Maybe you explain that. Yeah, it is a system that allows you to deploy your application. So basically the recipe we talk about is the one we use for building this tool. Internet is so slow. So it allows you to connect your project with GitHub, Bitbucket, or GitLab of your own. And then from there you can start... Once you connect with GitHub in this case, it automatically... I mean, add a web hook, mean URL, and it also add the... So what happens now is we are trying to get the handshake with GitHub to try to enable the web hoops. It is taking too long. But yeah, automatically add this SSH key for you so you can start using the project for deploying your site. So basically it allows you to create temporary stages of your project I mean dynamically create servers for you and all that. Dynamically you don't have to worry about it. It is like a CI MQA tool. And also allows you to build your artifact and deploy to your production server. In this case it could be Accha, Pantheon, or your own servers if you want to. Well, Internet is terrible. Let's wait one more second or two. We have five minutes. So the idea is obviously after we do the connection we use socket.io to try to improve the user interface try to do the interaction, enable the user to request some tasks do everything in background, continue doing something else and when the process was finished then you get a notification using the UI. And we use GraphQL and notification and socket to try to create a smooth application. Nah, never finished. Well yeah, this is the components that we mentioned on the site so it provides you with this sidebar, the layout component it allows you to form, let's say I can start just typing things here and making things and all these forms and fields and anything here is based on those components. What we tend to use is create our own components in top of those components to interact with them and as you can see here the value was created the form was rendered again and this is how it looks like I mean let's say we can probably go back to activity and this is how a table looks like once it's filled with data you can see here but I mean you don't have to do nothing other than take advantage of those same as Drupal, you know like Drupal form then they have forms, I mean there's lighters, they have like tabs. So the idea is to try to use the tool to invest your development time in the important things. Notifications here? It's logic. You see the notification there? That means the application get the connection with the GitHub and then we create a SSH that will be allowed into GitHub to allow to create the integration with the code itself. Yeah basically what happens, yeah do something you know call the GraphQL endpoint, the endpoint do something call the server, everything here is a synchronous, nothing happens I mean we have like message brokers so the message brokers go to the back do what it has to do and then put the message on the Redis emitter and as you can see we use the WebSocket to refresh the interface and send those messages here as you can see the notification was also pushed via WebSocket. So again this is the recipe we use for this. It also notifies you on a Slack, I mean whatever you want to. That's it. Yeah and that is for all so if you have any questions before to go launch go ahead, this is the mic. Could you go to here? Because we wanted to, okay the question is why don't we use, why we don't use Drupal? I mean we love Drupal, we use Drupal whenever it's a right solution. The thing here, this is not a content centric, there's no like no revision. We don't really need bootstrap Drupal for this. We can, this is light, I mean symphony API platform is lighter for bootstrap. The addition you mean the... Oh well yeah I mean but in the end it's like this is not a content centric, it's more like putting data and fetching data. So we don't really need the full Drupal. We don't need like build content types there, we don't need widgets, we don't need formatters. So it's like for this case we didn't know Drupal. So whenever we are building an application and there is not content centric we check the solution instead. Instead of going Drupal and then turn on JSON API and GraphQL and build something in top. Because I mean in the end you can use the same front end solution or recipe and use anything you want to like Drupal or Django REST or Go or build your own in JavaScript if you want to. Any other question? I can probably, I mean I can add, I mean it feels like with the code, I mean that won't be a problem. I can add this, I mean on the slide and when I upload it it will be updated. You can do that by using the group roles and then you use the, so whenever you're logging with JWT you have access to the user on the PHP side of things. So based on the role that user belongs to you can define, you can change doctrine queries on the fly and select what you want to see or want not to see. And creating those groups is how you define. Yeah, you declare some reason and annotation on the entity. Any other question? Thank you so much. In fact, in the example of when I changed the JWT, we added the organization ID or the role ID. We added the role ID in the login. The dates and you have it with the JWT code. Sorry. When you use JWT code you can, I mean because the JWT token from there you can access the role in this side. But I mean really with that on the client it's a little dangerous. I mean I really like to pre-fetch the data. That's what I want. But I want you to see the value itself. But you can, I mean definitely you can do that. Some people say the storing data on the client is dangerous as well. So this is, then just figure it out. Yeah, but remember whenever you call the API from the back end and you can, there is a lock train. You can use the lock train to change the code. You have access to the user that's locked. Because you pass it on to the back end, you pass it on to the token. You know which user is in with the user. You know the roles and all that. So you can solve that on the back end if you want. I find a lot of these things. They tend to use tools, same-round, role-building, other sort of role-building. These companies put out these amazing solutions. To me, I understand that we're going to hurry. For example, this one actually. Yeah, that's awesome. Every website in one single user. Yeah, I mean you know, that's for central. Central, that's for central. That's for the website, right? That's all that I was exposing the user. We put in the data and it's closing in. Then we have some very large applications. Different, meaningful endpoints. Then you can create this graph. Yeah, like million. So I was just like, I wasn't through this training. Provided by, you know... We don't need to record it. Have revisions for me. In this list of minutes, I mean, in green, it's actually how you do it. It's like... You know...