Video details

Martin Artola - Powering the Front-end with React, GraphQL and Relay - NDC Copenhagen 2022


Nowadays, fetching and managing data has become the critical pathway of many apps, whether you’re trying to simplify and speed up development or looking for the best user experience.
Technologies like React, GraphQL and Relay play a tremendous role in shifting not only the way we build apps but also how we write code.
If you’re new to this ecosystem, don’t panic! I’ll share with you some tips and walk through some hands-on examples to show you how easy it is to get started and open a world of possibilities.
Check out more of our featured speakers and talks at


Hello everyone. Welcome and thank you for coming today I'm going to talk I'm going to talk about power in the front end with reactor appear in real. I will share way to build applications that scale from the day one. My name is Martin Ottola. I work as a front and engineer in Swiss life, leading provider of pensions and financial solutions, where I help different teams to build and cheap world class applications. But the way I have been coding and doing contributing to open source for very long time, over 30 years already. But before we get started, I will give this a little bit of context. Once upon a time we were building simple websites. The web was all about sharing, text, people links, a few images and nothing else. But since we're evolving, mostly technologies were evolving, becoming every time more important also did our collective mindset of what made good business sense. And we started to build web apps. What we call usually single page application. If you were calling in those days, you will recognize some of these names. I have at least very long list here, but really you can add more. Batwon Edinburgh, nocount meteor Kancies, Dorio, marionette plus from Angula, CS, JavaScript, MBC, beer MBC and so forth. I work in several of them. Over time there were a ton of frameworks. Most of them were MBC alike frameworks, MBC alike implementation. All of them were looking how to start a JavaScript application. But the code bases were growing. We were requiring every time more and more to these single place applications. And then we started to struggle with that application, started to become very complicated and unpredictable. In that moment we knew somehow that we need to react the way that we build. You eyes, right? And fundamentally we need to make it a lot more simple. At that moment the things began to change. Right? Let's introduce in this password react is a JavaScript library for building user interfaces. It was developed by Meta Facebook. I will use one of them over time and it was publicly released in 2013. And this week did nine years already from the public release. That means that Meta was using it even before. I need to hear say big sense and do a mention to the people that did this possible, right? Tomokino Jordan, Walter picked Hand, among many other contributors of that times. And even but not less than abramov that continue pushing the limits of this library. The act was all about rethinking best practices. And if the crowd of approach to do the things change the way that we structure our JavaScript applications nowadays. Let's explore some traits of these applications to understand what it means. Every component is a building block for our UI. These components are loosely coupled one to the other. Imagine like Lego blocks. We have a lot of them in different shapes and colors and we can still build and play with them because they satisfies a common API that allows us to do that. Components help us to separate concerns, not in the way that we were doing before. At that time, ten or 15 years ago that we were separating HTML, CSS and JavaScript, that we started to separate business to logic from presentation. Logic components are very several pieces of UI. It is simple to understand this when we see a button. How many times is in our application? Components are built up regular JavaScript and as you know, JavaScript is one of the most used languages and it is just listed after English. Components are important functions that describe the UI at any point in time. Given some state this workstation, we can derive that UI that's view in general, we call this state Props. Okay, given some props, we can derive our UI in this example. This is a hello world component. Very simple. We can see how simple is to create a component and how easy to use it if you have frontend guys. Okay, this is trivial, right? But we will see how this fits in the world story. Right here we have an intensive version of the component where just changing a little bit. The API allow us to pass the property and get a different outcome. Components are unit testable as they are. JavaScript function are easy to test. A JavaScript function that retain markup and then we test that thing. React is all about composition. We build components from other components because one characteristic is that components are composable. In algebra. If we have F and G, like two functions, we read this like F composite with G or F after G and we can compose these functions as long as the output or grand function match the expectations of the input of the next one. We can use props to define the API of the components a little bit. We showed before these props that we derived to state and it is very common to include the property. The final property that is called children. Like in this example, right, we have an app component with a bunch of children and each of these children at the same time we contain other components inside. Now we know that we have different platforms. Each of them has different look and feel capabilities and even contrast. And as front end developers, we must deliver the best user speeding for each of them. For example, we have Web Mobile, Windows, Mac OS and Event TV devices. With React we can build applications for any of these platform without knowing that the lion technology. Like it doesn't mean that you don't need to know anything else, but you will be mostly able to do a good job with not so much training. In this example we can appreciate how similar are writing a component for the web, like writing a component for native. Mostly what we do is train a little bit, a few days, a few weeks, whatever, just to understand what are the difference between one and the other. And we are able to start to create applications for all of them. Now, let's go directly to do some coding, right? Again, I repeat, this is trivial. It's up to show that things work. We have here normal JavaScript application. This is done with next year. Just to make it simple. All the set up is next year's application. Here we have a component that in this moment render nothing, right? And easily we can write here our Hello World, right? And we can see that that is the outcome. We can, in case this component, as we were showing before, adding here the property and even defining here the default value. And now we can interpolate it here, right? This again, I repeat on desperate is trivial for us. Okay? Okay. Then this is super trivial. Things are working, but we can do things a little bit more complex, right? For example, here I have not passed the property. And where we use the component, we can start to pass some name. For example, my name. Even better. Okay? Now I will remove this, wipe out this information, we will see a bit more interesting thing. Okay? Here we have a Hello World application, right? A little bit more complex than what we did before, but now we will go to this endpoint. That is the pup endpoint. For this APIs, I am passing some token that is access to my account. And then we will ask to the server for my name. I am logging in now with this token in GitHub. And I can retrieve my name from GitHub. That looks interesting. But the point is, look how since I start to become a little bit complex, right? And remember that we have here, for example, a lot of lines to manage how to fetch from the server. What to do with that response in this case is shades on string. Then we need to convert it in shades on object. And even we need to handle some kind of error, right? And that's probably not the best, but if we have an error, this is what will happen. But what is interesting probably for what will continue later, is that what happened when we do these calls, right? I will refresh my screen here. But now we have here the tools, right? Then we can see that there is a call to the GitHub API. And that is what happened. The API gave me all this information. Maybe I was interested in my name. That is among all these properties somewhere there. But also I got all this stuff, right? And then remember very well this point, because this will continue in our talk. Because the next point the kick off for GraphQL, right? Then remember that I want just the name, but I got this thing we say usually like this, right? I want the banana, but I get the monkey and also the wall shingle behind. An example can be more complex if you are a guy, right? Here I have a version that says, okay, what happened? If the component is mounted, then we need to have an Abort controller. We need to stop that call that we are doing there. We will have problems, we will have memory leaks and so on, right? And this is just the tip of the iceberg. Even this is an approach, right? Then let's think that this is finished. Let's move to the next one, right? Then our components are able to derive the UI, what we see in the screen, right? What we see in our devices from this state or props, okay? But usually that means also going somewhere for that information. But then we have been doing this with recipes. These APIs, like we were looking here, this API has very well known limitations, right? And mainly two of them are under fetching and over fetching. This is by over fetching. Over fetching is what we saw here. I want the name, but I got back the wall Shangle, right? We were getting a lot more than what we need. And that means two things, right? We are getting more information, more transport, and this takes longer, right? And the other is under fetching we did not see before here. But that means when we make a call and we don't get all the information that we need, maybe we get some ideas and then we need to go back to another recipe to get more date to solve this problem. To overcome this problem, there were mainly over time two approach speeding APIs or BFFs back and forth. Let's talk for example. They are different technology, differently between them, but both more or less in the same way. For the front end part, what they do is like saying, okay, if you will need the name, I will create an endpoint where you will get the name. That means that they start to match what we need in the front. This is very well and works very well. When we have a very small application, one developer, one is the same guy back in the front. And then it's very easy probably to keep track of that things. But the things are not scaling somewhere. When we have hundreds of developers, when we have more than one client, maybe we have a desktop application, a mobile application. In the desktop application we show 20 fields, but in the mobile application has four. Then we need to start to do a lot of things, but also the mobile applications. The user can have it longer than the website that just need to make a fight to get a new version, right? That means that we need to also burst on and keep them over time. It's very difficult to maintain, has few flexibility and creates mostly bad user or developer experience. At that point, I think that experiencing this problem. Not only me, the people from Meta came with the idea of GraphQL. What is GraphQL? GraphQL is a query language for your API. It was developed by Meta. It was publicly released in 2015, then in 2019 was moved into the Graph QL Foundation. That means that nowadays is not a Facebook scene. Else is part of the foundation where a lot of companies belong. Here I need to say again big thanks and do a mention to the Cocreators Leviron, Dan Shaffer and Nick Schrock among many other contributors but that are the original creators of this GraphQL language. The GraphQL stand for GraphQL language but it is not a query language as we could understand SQL a query language for getting data from the database. It is rather a way to define how we communicate from the client to the server. Due to the fact that GraphQL is defined by an open standard but not a public implementation, that's not an official implementation. You can create your implementation in any language and then you can do whatever you want with that. You can use any kind of database. It's not necessarily that oh, I need to have a Graph database because it's a GraphQL not doesn't matter. You can use whatever you want and support any kind of client. Clients can be written also in many different languages as long as you follow the specifications, the rules that are in the specification. Let's explore some traits of this Draft. Draft shifts the contract between the client and the server. The clients have the power to require what they want and get exactly that from the server. Nothing more, nothing less, which leads to a better user experience, especially in slow network connection. The graphical schema here we can see one represents your business model. This is your business model written in an schema in terms of types and fields against which you can perform queries. Queries are mostly a way to specify fields that are exposed in that schema. You can see here for example, in this query we are requiring for the active user the name and the response of the server mimic the shape of the query. In this other I added a couple more fields and we can see that the server respond exactly with that information and again mimics exactly the same shape of the query. Then, while typical recipe you are required to look at multiple employees, multiple viewer. With GraphQL you can get everything in a single request. Reducing the numbers of calls saves time and money saves time and bandwidth, especially in a slow network connection. Graphical queries access to properties that can be deep nested. For example, in this case we have the name like we saw before, but also we are requiring the notifications that that user can have imagine kind of inbox messages and all of them are coming in just one single request. Usually this before we were doing two calls to get this thing first to get the idea of the user second call to get the notification because each of them are different resources, right here we get everything in one single call. Graphic continued to ball because the community is growing every day and the new capabilities are added in general they are added like directives. For example between the last one we got different and stream. But let's take a look to the core of GraphQL, okay? Developer tools like code intelligence, like compilers, like clients usually maybe you know graphical. But today we will talk a lot about BCP banana kpop that are possible because they leverage the type system through graphical introduction we can get the information from the schema and with this information generate documentation and reach ID. Again you will see that BCP use this introspection to create a lot of information in general and this is part of this core. Capabilities of the GraphQL fields are nullable by default. This is very important because GraphQL is a network service and any network service there are a lot of problems that can happen in the connection, right? Because these network services is backed by databases, by other services and then a lot of things can go aggressive and it's much better to return now in a field that totally failed the request. While there is nothing about version in GraphQL like any other Rest API in general you can totally avoid to do this. You can add new capabilities by adding new types of new fields without creating a breaking change. That means that you continue to bold the schema without need for version. GraphQL defined a different operation to communicate with the graph. We have mainly this comparison you can see probably in Rest you get it very easy but in Graph well apart from the queries, that is the way to retrieve data of the mutations that are a little bit strange. Because we can do two things we can change data but also at the same time in the same call we can get information about the results. Until that point, mostly we match the Rest API but we also have subscriptions subscription user to listen real time events coming from our server. There is no equivalence in recipe. Now I will show you a little bit of code. Okay, let's start with first I will introduce you because as you will know I would like to say which tools we are using. Here you can see this chili cream platform. Okay? Chili cream. The chili cream team creates a lot of tools for the graphical ecosystem. Today we will be using especially some of them. Here you can see how the chili cream has been doing a lot of things. I think that is very important for you. Maybe you know them better than me because this is very important for.NET guys, right? The hot chocolate server that we can see here is a net implementation. If you are not using it today in production or if you are not using your company at all but you want to test GraphQL you can spin up a graphical survey in a couple of minutes and I find that awesome but apart from that we will see other tools and we will use this one apart from the VCP from Cochoculate that is the server that we are using now in the back end that is already running in hot chocolate we were using a lot this Banana Kpop banana Kpop is a GraphQL client and me like developer I use it a lot to make my queries and to get information from the GraphQL server right? And if you are net guy again you will have also Strawberry Shake that is a tool to create a net client okay that's it this is BCP okay sorry this little is a little bit small I hope that you can see but anything is very simple this is the query that we saw before right? And in this query I am asking for the name right? Then we do the query to the server and this is the answer that we get you can see that mimic the shape of the query how is this possible? Right? This is possible because here in the configurations I said okay I will use this backend server it's a graphical server running in this endpoint and I also got all the schema the tool is automatically syncing with the schema and grabbing the schema and among the operations that I can do there are a lot because this service is a real example of server we can see this one that is what we are looking now I can ask for the me that is of type user and for that I can get the name but also we can get other information we saw before maybe the display name or the notification all this information is visible here you can see that in different ways there is a lot of information all these come from the schema this is very nice because we can see that the tool itself documents everything then if I want to hear for example as for the display name I just need to add it and you can see that I have intelligent cocompletion and so on right? And then I got it back, right? But also it's possible to for example do things like ask for the image, right? I want to get the email for my profile for my avatar, right? And you can see that I have not an image there in my avatar then here I will do a mutation in this moment and what we will do is like we can set the display name for example my name I could change it for example for Martin in upper case and I could also add for example here an image and this image will be this photo that I have here okay then we do this mutation and the server should get it back this information. That's it. This is a little bit strange because here we did something. Yeah, it's a little bit slow. Internet is not going the best. But you can see that I did the mutation and the display name changed it to uppercase. That is because I did a change. And at the same time I can query by the results and I can see the result of this operation. Also, another thing that is a little bit strange, let's say I can't even upload. That is we can do this even with the glass. Then the server got this image and they tell me the URL and then store it there. This is a nice thing because in the web, especially in the front end, for us, it's nice to have this URL because we can long term cash them, right? But this is about the capabilities that we have for something so simple. Now I will go back to the presentation. I will show you something a little bit more complex. Let's say this is an application that we are creating, is a real application. We call it the crypto application that we create in the workshop. The workshop we run a full fletcher application back in and front, okay? And we create this application with a lot of views. One is this view, that is the dashboard view. And you can see like front end. What we do here is identify the components that have data. The others around are just for presentation only, right? Just to play with application. And these are showing a lot of list of currencies. And then we identified that, for example, these leads are full of list items. And each of these items are rendered in different ways. In one place they are just showing in the ticker. Like in the top maybe you can see here, this is called ticker. And in the other they are showing like charts, for example, right? But are a lot of leads of bites. And what is important that each of these components in each of these areas in red has different data requirements. For example, in the first one in the ticker, we want to show there the ten K cryptocurrency sorted by market cap. In the second one we preselect three of them. For example, bitcoin and a couple more. And in the other we want to get five top selected gainers and losers of the day. And the thing is we need to create a way, we need to create a query to get all that information. Imagine how many calls you need to do in Rest APIs to do these kind of things and what can be the flexibility to do it. Okay, let's try to create that. This is a long query. I will explain to you what it is, how we build it. Okay? This is just copy paste from what we did in the workshop. But you can do it here. We will need like ten minutes to do it. Then you can see we have a dashboard container. This is a component. This is like grabbing all the queries that we need for each part. We have the ticker, we have the feature, these three bitcoin and two more. And we have that spotlight that gain us and losers of the day, each of them is a fragment. We will see that these fragments are the way that the component has to define the data dependency. And what we do is split these fragments the way to compose these queries and that is what I did here. Let's start, for example, for the ticker, look, I opened the ticker fragment that we can see here, matching and look this thing, I can be very impressive here and say I want a list of assets, assets at these currencies, I want the first ten ordered by market cap, ascending, all of that. I can do it there, right? Plus we have more fragments inside these items are each one of them saying exactly which data they need. For example, they need, let's see this one they need, for example, to have the symbol and the color, because each one rendered the color plus the price and the percentage change and these kind of things. And the same we did for the next groups, right? For example, this feature, these three selected, we say okay, give me the list of assets, just matching bitcoin, cardano and algorithm that are these three currencies. And we did exactly again the same and we composed again fragments and fragments. Each of them say exactly what they need. For example, for that now we will see again back to the application. Then you will remember we need to make the change the charts. And the charts require historical data. That is what we require here. It charged us around two or 300 points and that's required for each of these currency. And we have the same for gainers and losers that are this one that we have here. Imagine gainers and loser are more or less the same thing, but we select different date. But again, look, give me the first five selected, in fact this way sorted in this other way, right? And the point is like when we execute this query, we get all this back in just a single call. And I think that this is us. But we got a lot of data and all these points as how we make these charts and we can get this in one single call. Maybe we did one single call. Then we collected a huge information for our view. In general, most of the views are just one single call, right? But we can do a lot more. For example, not all the data is so important. We want to have the ticket on top as fast as possible, we want to have the chart as fast as possible. But the losers are probably outside of the viewport. It's not so important to have it so fast, right? Then we have mostly this need to have it top down. We have these directives in the language in GraphQL like differ that for us from the front end are kind of hint for the back end. If I say you can prioritize these parts, this is not so important for me. If you can make it fast, the server will define it, maybe send it immediately. But if cannot, it will take more time. Probably will come late. See, what happened here for us was like a single call, right? We did really a single call. But what we get is something a little bit different. Look here, I did it two times. Maybe it's better if I just refresh and do it third time. Okay, I got it. There. Really. We did one single call when we express exactly what we need for our view. But we got these things first. We got a part and for the top, where we have the ticker with all the information for the ticker and later the server send it some milliseconds later. It could be maybe 2300 milliseconds or 2 seconds later they started to send the other parts. You can see that gainers or losers in this part, they were not there. That means that we received this in different times. And later on we started to receive this rainer and later we received the loose. Okay? And again, we did all of these with just a single query, right? And that is starting to show the power that we have to create data driven applications specially for enterprise. Okay, that's it. We will move a little bit more and I will go back to the percentage. Then, as I said a couple of times, it was not intentional. I said graphical is awesome here. I need to say again the same. And I really think that's right. When I saw graphical for the first time some years ago, I had this problem with the rest endpoint so much with the backing guy. And when I say oh, we can do this solve all our problems, then this is the thing lasts give us a lot much better developer speed. We could use, as you can say, graphic bill is about sending a query to the server and the same server will answer with that data in the front. And we could do that using just fetch, right? As I did in a nice way to fetch from the GitHub API. But that will not scale, right? That is not what we want for data driven application. When we need to do this one hundreds of times, then we can do it a lot easier. We can do it faster. It easier, much simpler. At that point we introduced Billy is a graphical client that scale with you, as they say. Also it's a meta project. It was publicly released in 2015. And there are a lot of contributors that I want to mention as young cousin because I do a lot of work with him. Andrew Luno because the same and choice of owner that is like leading the team and doing a lot of stuff. Then Pilla is a JavaScript framework for fetching data from GraphQL and it is for client applications, right? It combines two things the clinical approach to declare the data that we need in our components plus a build step, right? And static optimization. Then what we do is our component define exactly the information that we want. But we will compile this code and we will optimize that query, we will validate them, we will do other stuff and then we are sure that when we execute the query is valid and also it's optimized for runtime. Let's explore some of these rates of Relay then relay makes, as I said, data patching very easy. Has an incremental compiler written in super fast. Super fast. It was even the JavaScript one with ten hundred thousand components is really fast. We have I think a thousand of components and we can see a couple of seconds just in grass implementation for our scale components declared the dependencies that they need and it's really we will fetch that data and will pass into the component also we'll be in charge of doing this in an optimized way and avoid to render the component if it is not necessary. First of all, there is one more thing. Even if we have a lot of components in our view that share the same query, each component can only access the data that they require. This is called data masking. It's a characteristic of relay. Even if in our query we query for 20 or 30 or hundred fields, our component will just be able to get that few fields that they need and cannot see. The others really is doing all this heavy lifting for us. It's compiling for us and it's pre computing for us. Let's see this thing. For example, when we know the very well that in general our applications are bundled web package doing that, for example, that means that application artifact is not changing once that we deliver that artifact. That means that we can do a lot of optimizations in that bill step and avoid to do that in the runtime. Especially if we think that our consuming will have low end devices, right? But even I believe that even if we think that our customers will have high end devices, it makes no sense to do this in the hands of our usage will take a lot of milliseconds that we need for something else. Then Relay keeps all the components updated and this is doing it more or less in this way that we can see here. Okay. When we make a query to the server, this query is normalized and goes into a store. What is interesting of this store that the component has subscribed to changes in the store and for the field that they are using. That means that if the field is changing in the store then that component will rerender, the other components will not rerender then one thing that is important for us like developers is this work faster, right? And we can do it easily if we know that we have safety behind relay can compile out of the box using the relay compiler can output or not type in if you don't want at all. Or you can output past click types or flow types. It's up to you what you want to use. But one important thing is like to get the best of relay you need to use a server that stick to the best practices. In general, graph will define some best practices and your server should fulfill that practice. That is the case of Coconut, a service that will fulfill that best practices because they are baked in the service. Okay here we took it before and we saw even in the examples how we define fragments, right? Fragment is a contract that we have between the component and the API. Our component defines the data requirements. We can see here how we do it. We saw before when I show in BCP how we did it we have usually a data container, component container like we did in Redux many times that will collect all the fragments that we need. But now when we look into our component, each component will use this hook use fragment to define the data requirements. Did you see that long query that I did before was just a copy and paste of this fragment that we have here. That means that we are colocating the data requirements to the component. That makes very easy to see what we need, where we need it, right? Very easy for us to find that if this symbol is here defined it's because few lines bellow we are using it. If it is not, we should just remove it. But it makes very easy to maintain our component. We can think in abstraction, we can just look into our component doesn't matter what is happening in other parts of the application. This is also another thing about the best practices, okay? Really provides first class support for cars or Pacific. This is called GraphQL connections as a model for representing list of data. So they can easily be passionated in any direction. Also can contain rich information about what is in the connection. I think that is very difficult to see here. But if we have a list of friends that connection could contain information about since when I am friends with that person, right? That kind of information can be in the connection. This is something very specific for Relay. We have these kind of unique ideas that provide a way for caching the data and also for refreshing the data. Okay? These are necessary to be there when we receive data from the server. We use that global IDs to normalize the data. If we receive for example in the first call for my user just name and in another I receive the display name. We can match this in the same object in the memory because they have the same idea behind here we can see how this works. This is mostly for the back end part. Let's say anytime that use the node interface then we'll who use this global identification and will allow this refugee. Okay, now I would like to show you the second part of this application. This real world application. This is what we will do now. This is the application. We will put it there. Now on we will see that here we click on one of these cards and see for example bitcoin take care of this price. It's a real price. But we did it like two months ago. Don't run now to sell. Because then if you click in one of the crypto currencies you can see this other view, right, that we call Buuber and you can see information about cryptocurrency. Most of the information that we see here we did like before. I did separate the data components. Each of these blocks are components, most of them are key value parts. I can show here that we have a lot of key value parts which has presentation for them. We have a lot of these components, but we have a little bit more of activity here. Okay. Anyway, you can see how we make this view collecting all the data that we need. Then you can see here again, we have these data requirements in the header. Apart from showing the logo, the name of the cafe, the symbol of the cafe, we have two mutations. I will show you this one. That is the star, that is a mutation to add and remove from the watch list. Kind of like a button, right? But we also removed this currency from our watch list. And in the second part we have this. That is the snapshot that is showing the price activity and also the chart where we can select the time span. And the chart will change the rest of the components and can be a lot more, right? For example, as presentational data, we have key value pairs and we do something with that. Then let's do that application first. I will stop the other. Then I can use the same port. Yes, I have this application also running next year. I use next year. Just to make it simple, right. And it's a bit cool but you can use app or do it by yourself as you want. I am looking into the component that we have here. This is what we saw before. Just because we were looking at data that we were collecting but we did not see the application working. Okay, that was a ticket that goes there around and here we have the chat information and a lot of cards and so on, right now the point is like when I click on one of them like bitcoin then we see information about that one and that is what we want to build now, right? Then as I said before we have this information on top where we are interested in the mutation and we have a little bit of activity here plus all the other parts that are just key value parts to present. Then I will start by the index of the burn. If you do react you should get it we are using here react 18 sprinter version even, right? But more or less what we saw here will work in any react version 18. Then we are using for example this bonding is a way that will allow us if there is for example in the network connection we call automatically retry for example then we put some logic in that component, right? Or we can just show it to the user and say do you want to retrieve? Or we cannot do it later, come late. We cannot do it now, come late. Suspended boundary, right? Then what we are doing here is saying okay, as long as we are receiving the data for the view show this activity indicator that is my fault but I this activity indicator is a little bit smart, will not show up, will not be visible for three or 400 milliseconds, right? In that way we don't get a flaky screen, right? Then if it is taking longer than we will start to see the indicator and then we have this container, this container component that collects all the data needs. Let's look a little bit at that. You can see I did exactly the same that I did in the other this container component collect all the information that needs for the header for example, we need the symbol, the color, the name of the currency and so on and so forth, right? And then we have the snapchat information, the snapchat fragment, that is another component. Now we will go deep into that, okay? Here at this level what we do is just split the fragments into the part inquiry, right? And that's it. The UI is you can see it's stuck where we stuck the different parts. Okay then let's take a look for example to the head you can see I collapsed here a little bit just to show up. So now you can see this fragment for the header is saying exactly, okay? For this component I need to have the symbol, I need to have the name, I need to have the image URL. I want to know if this is already in my watch list or not. Then we can paint this like selected or not already, right? Okay, this alert is for the other button that I am not showing exactly now, right? And the same we do with the other parts, especially this one snapshot. That is all this area that we have here, okay, we have data requirements, each of them you can see we require exactly what we need for our component, right? Then let's look two things. One is like how do we do this mutation to add or remove from the watch list. Then in the header we can see that there is up to the watchlist. This is a hook and there is one removed from the watching. One thing of GraphQL is that our operations are not something like delete patch or so are more semantic. We can exactly say exactly what we are doing. Then you can see here for example, in the watchlist we are performing that mutation exactly as I did before. With the other we have a mutation operation and then we pass a variable with the value of the currency that we want. This input that we have there, the currency that we want to add or remove from the watch where we use it here. Bellow we can see that what I do is like say, okay, if it is in the watch list, remove it if it's not there as it right. I pass here. Just to make it simple, I passed the wall asset option. But we are interested mainly one or two fields there to do this operation. When I click on the button, what we do there we can see that we have or we remove the thing that we see is like there is a fast response, right? And this is not exactly like this. Let's say the response is fast, that's for sure. But it's not happening so fast, especially from the server side point of view, right? Then you can see when I click there is a request to the server and this request is taking even some that could take even longer. What we did here is we do an optimistic update put into the store the information that will come from the server. In that way we get a pass answer for the user while we are performing this in the back end. This works very well for these cases, right? For example, putting a like button in a message, something that is not so important up to some point, right? I will take more care if I am transferring some millions to someone in some bank account because probably we want to be sure that that happened, okay? But in general for trivial things like this could be enough. And even probably the user doesn't need to know what is ongoing. What could happen if I put in a like in a message? King Car Russian gets one less than 25 million. I mean, we don't care so much. Then the point is like we can probably store that information in local storage and try this several times before showing to the usage that there was something wrong, right? And probably during that time we solved the problem and then the usage is not even aware, right? In other contexts in business, I will say bank transfer things more important, we probably will love the UI in that point and we will wait for an answer. We will put a nice spinner. We are doing your transaction wait a moment until we get proper confirmation from the server, right? But we have the possibility to do it. We can do one thing, we can do the other. We can just wait, put on screen and do whatever we want. The other thing that I want to show in this screen is how we do this chart, okay? In one hand I did the chart even in DC, I did my own version of the chart. But it's just on top of these three. Okay? But that is the presentation part that we know how to do. Or you use high charts or any other library. The nice thing here is like when we query for a different time and span, because this charge has two or 300 points, we need to say day by day or times, time by time, exactly what was the value in that moment, right? And this is a lot of data. Then when we enter the first time, we are just showing for one day span the values and this creates my chart. If the user clicks different times span, for example, one week in that moment we go to the server, we come with the data and then I produce that animation from A to B, okay? That is what we can see here. And let's see I did already one call, let's refresh. Maybe it will be nicer because we can see other powers of relay in this construction. I did the first call when I refreshed the page and we can see that here we go to all this information. Now, when I click one week, we can see that there is another call here ongoing, okay? And we got back information and I do one month and we get the third call, right? But now if I go back and I click in one week, we can see that we have already all that information in our store. We don't need to go to the server, really can fulfill our data requirements directly from the store. And that is really interesting, right? I mean, it is up to us how we set the configurations in our queries to do it like this. And we have different configurations. Something like use the store else goes to the network or use the store while you are going to the network. But when you get the value from the network, I pay my component. You need to be careful my banking application I have my problem that I see my balance and it's very nice and he'll change and that's usually bad, probably. I think that guy did not so well, right? I will prefer to wait longer there that get a value that will change. But in other context you could play with that better, right? Good. Then you can see here we have a lot of stuff on going. We have a lot of components and was easy to do this thing. If you are interested in the internals of this thing, especially how we did this mutation in the chart from the front end point of view, right? This is for something guys we have here when we perform the change, we use this new API. React 18 was not possible to do before. We need to do a lot of work to do that. But now we have this possibility to start the transition. Then we have keeps showing the data that we have until we get the new date. Before we were putting probably in spinner probably placeholder. I think that is much better use of speeding to do that. Especially because the screen is not collapsing, right? That was flickering a lot and also we can play a lot with this kind of animation. This is just React 18 and you can use it, okay? The same that I showed before because we will run short on time. React I think has a lot of possibilities here we are using React experimental version that is looking forward to Reactivating and we can do with a lot of different place. Just to be clear, it is experimental but React has been using this for three years already. That means that it's not so experimental. It looks like they are using it in production for three years with 1 billion user. Then I guess that we can use it too. Okay, but this year they promise that will be cheaper this thing. Okay, just to finish here, I took this saying how we can build application that scale. Now the point is like what means really to be scalable, right? What means this scale? Right? Then we have two kinds of scales. One that probably especially black and I know how to do it very well. That means about having a system that can handle a growing demand, right? What keeps the same user experience, right? That means that we have more users, more orders, more customer hot system, peak demand and still our system resist to all of that. That is one kind of business collaborator, right? And we know how to do that horizontally, vertically, more server, more this, more that is an old fashioned way. The point for me is more important especially when we work with large teams of developers. A lot of changes, a lot of applications is to have been scalable in the front in the way that we are able to deliver more features at the same speed without going every time it's lower and slower, our code will continue to grow and we have still the same time to deliver the feature. Because our code is simple, it's based on known patterns and it's easy to maintain, right? And that is what we try to do in the front end. And a lot of these is because we choose the right tools. From my own experience in having working in many companies but in the last few very huge companies we saw that in this ecosystem react plus relay we got really good performance. We got a lot of people speeding up and easily to do. It's easy to get people. I know that you are net guys where you but my friends in the back end, my company the back end is done all in net except the front end. Because I am there. If you want to know more, if you are interested to know more, look the chelly information all about the hot chocolate service, about the BCP client that you can use with any other even if you don't use Cochocolate, you can use this like in a standard application with any other GraphQL server. We did it already in Portland, we did it here in Copenhagen. I will do it also in Minnesota. This course with my colleague Michael Style, he's doing his out of Cochocula was years as minute before. And then we will run it in Minnesota, probably in Sydney. Okay? If you go to Oslo, by the way, I will not be there. They will do the same thing, but with Maui for you, if you're interested in this. I don't think probably it's a little far, but next year we will repeat that. We have been here this week two days doing it. We have a lot of fun, we have a very nice exchange the people there and we are very happy doing that because it's also part of our opensource effort to contribute into the community. That's it. That's all. Thank you very much. Bye.