 Hi guys, thank you so much for staying up for the last talk for the day So this happens to be my third talk actually fourth if you count Meta refresh and I think here on your JS who has been Going awesome and more and more awesome. So a big cheer to the has gig team and I think to the entire community as such And I really appreciate the money details that you guys get into and keep improving every single year. So that's awesome Okay So talking about demand-driven applications primarily with graph ql I Tend to think there are three big problems when it comes to being web development The first two you probably already heard of which is cash in validations and naming variables And I like to add a third item to that which is adhering to Jason contracts And the reason why I say that is because pretty much in most of the engagements that have been a part of The Jason contracts that we agree upon at the start never seem to be the same when it project goes like things keep changing over and over and that's not a great thing and That essentially leads up to this whole situation of where the API tends to become a bottleneck for us So if you look at it, you have the data layer and you have the experience layer So data layers where you have all your databases Out of them being powered by microservices and you have the experience layer That's being built on your angular's your reacts and the view Jesus of the world and the mobile applications on Swift and maybe Kotlin nowadays so these of them keep moving at a great pace and is the API layers job in the middle to try and make sure that the Data that's coming from the data layer is Massaged and represented in the right way that your experience layer can see it on the top and that's where things don't work very well and The date the API layer is also where a couple of problems keep on occurring So the first one is like I said your API is keep changing and changing an API is never a good thing for anybody Every time new features get added in and you want to change an API your front end There's a very good chance of front-end applications can break and to sort of avoid that what you land up doing is sort of versioning your API's and when you version your API's you'll end up having to maintain a whole bunch of API's with just small incremental changes over The other thing is network latency, and I think network latency is the one that sort of affects the most to your API layer And and that is more pronounced when it comes to mobile and then that's family because of the way cellular networks work Right, so every additional request that you're making to an API The amount of payload that it downloads or the amount of time that it takes or it actually puts in a lot of Slowness to the loading of your app. So network latency is one of the biggest factors that affects an API layer And the last one is documentation The way rest works the way we build our rest API's Nothing is the whole API is of no use unless you have documentation that tells you what API's to hit or what data's to get back on So those are couple of challenges that we land up facing with your API's and the whole idea of Demand-driven architecture is to sort of minimize some of those problems and make life a little better So before we get into that Just a quick look at how traditionally we have been working So if you look at it, we obviously nowadays work in a component-based architecture You have a parent component and a couple of child components under them And the parent component is usually the one that goes makes a network request gets back a big chunk of JSON Takes the data that it wants to render renders that passes the data further down to the child components And each of the child components render the data So they pick up the data that they want to see render it up a lot of data gets wasted unnecessary information Which you do not get to use at the same time certain components need some data Which they haven't got from the parent components and what they land up doing is when they go and make another network call Get that data and and render so that's essentially how most of the application that we build nowadays work and Which is fine, but you know if you look at it your components are sort of doing pretty mundane things You know, there's no smart intelligence over there. You get the data I just render it and that's probably other reason why you call them as dumb components I know they call them commons for a different reason, but you know the baby biller applications are pretty much rather dumb When it comes to demand-driven things work a little differently So here every component knows that this is the data that I want to display and the component will make a request to the Parents saying hey I need to display the component give me these three or four fields that I need and that goes to my parent component And that intern goes to the root component and the root component will collate all the data fields that That all the child components need makes one network call to the top gets the data in and renders all the data back down And what happens with that is every component gets exactly the data that they asked for which means not more not less Which is a very efficient on the network for us. So that's how one of the primary principles of the way demand-driven architecture works Right and graphql is one of the tools that works on this principle and if you ask me what graphql is Basically, just three things that you need to keep in mind one. It's a query language for your API To it runs on the server. So it's a server set runtime and it uses a type system So that's three basic things you want to keep in mind And while you're talking on this you also want to know what graphql is not because there's a lot of confusion around it People tend to misunderstand it. So just want to come throughout a couple of points out there So for one, it's not a database Things like graph database like Neo4j is a graph database graphql does not store any kind of a data. It's a transport protocol It's a client-side statement. It's not a client-side state management library Just because it was made by Facebook does not mean it is limited to only being used with react and relay And actually it's not even just limited to JavaScript and the node world. It's much bigger than that And finally it's got nothing to do with Facebook social graph. I Had people coming up and asking me so what I we built enterprise-based applications and we got nothing We don't need Facebook friends. We don't need friends or friends and likes so can you still use graphql? I was like, of course you can use graphql. It's got nothing to do with the social graph So these are a couple of things that graphql is not so what exactly is graphql? So when Facebook decided to launch graphql They simply pushed it out as a set of specifications of how query should be written And that's all that they did they did launch a small reference application on top of that But the main thing that Facebook owns for graphql is the specifications and what that did to the community is every community went in picked up the specifications and built a graphql server on their own favorite languages and by that now We have got graphql servers available in pretty much every possible language That's out there. So which means you do not have to know JavaScript to use a graphical server if you work with Scala Haskell Ruby you can work with graphql In addition to that, you also have a couple of client libraries that use graphql. These are optional You may choose you want to use them it makes life a little easier But otherwise you can just write plain vanilla JavaScript. So relay and Apollo are a couple of clients that are a lot more popular in the space How does the graphql topology look like so? You have the bottom You know your databases You've got your order management systems or inventory and all of that or the data from that is being powered up by micro services And then you have a graphql layer that is sitting on top of that It's essentially doing the plumbing over there so you take data from all these data points and Graphql builds one big scheme over there and your frontend application whether it's Angular react or if it's a native App built on Swift or maybe native script all of them hit one single endpoint There's only one endpoint that all of them hit to get the data back So you don't need to know what are the various APIs that are there I don't need to know what is the parameters that I'm going to receive nothing I just need I just work with one single endpoint. So that's the beauty of graphql So the way graphql works is so as I said every component defines the data needs So here I have a component that says I need name email address Whatever I simply create a JSON object of that send it to graphql And graphql respond back to me with the JSON object with the data filled in and what comes with graphql is a very nice interface called Graphql wherein, you know, you can live Sorry, pretty much live mode writer queries and see how the responses look like I'm going to try and show you a couple of examples of this like I said graphical is a very nice interface for building For testing a graphql and there's also something called launchpad Which you can access it at launchpad dot graphql.com So this allows you to write build a JSON schema Build your queries and actually see the live results. So think of it like J has been but for graphql So you have a left interface wherein you create your schemas and in the center pane is where you create your queries And on the right hand side is where you'll get to see the outputs of this queries So I have a couple of Pads that you can just look at so at the heart of graphql is something called the graphql schema So this is where like I said, you do the plumbing work, you know all the data coming from the deep from your API You keep them all concentrated in the center and you create a various fields that are there out there and your front-end application Will simply ask for this fields and inside a JSON schema There are just primarily two basic things one is the fields and the second one is what the field should resolve to So if you look at this particular thing, these are a set of fields that I have So let's look at the first field is one field called. Hello, and it's of type string So like I said graphql is a type system So every field that you define you have to define what the type that goes along with it and for this field called Hello, I have a resolver function and a resolver function is nothing but a JavaScript function and inside that I could do whatever I want So for the hello function, I simply say respond back with a hello world and If I have to build my graphql query, I Will write hello. So that's my field name and if I run it It should respond back with a hello world wanted to respond back with something else. I just change the parameters here So let's say Yes, who rocks it would update my field on my rat panel So that's the output over there and you will see that value has changed to j rocks. So it's as simple as that Let's look at the next example where you have a field called show cities So so the field is called show cities what it returns back is actually an array of strings and in my resolver I'm simply returning back an array of strings out here so if I go in and say Sure cities and you notice graphql is doing an autocomplete. So, you know makes life a lot easier for all of us if I run that I Probably get an array of cities over there. So that's my second field So you can create fields that respond back with integers Skillar values like strings bullion floats. You can also respond it back with a string This is a third type of Feel that I've created it says get area it takes in an input of a radius Whose type is integer and it runs back a float Very simple thing and in my resolver. I essentially have a formula that calculates the radius of a circle so if I have to try this out I get area and I say radius and I give a radius of say two and Should get my radius over here so Graphql at the core of it is very very simple a field and a resolver function Which is nothing but a JavaScript function and do whatever you want inside the JavaScript function And what was the resolving value comes back as a response to the field that you requested for That's that's the whole base of Graphql and if you look at it so easy that you know you can actually start seeing how you can start mocking it how we can use it for mocking data because clearly when you're building front-end applications Your API is never ready right how many times are in situations where you're building a front-end application that your API is a hundred percent ready Very rarely your API is are never there your contracts are there Yes, your existing contracts are there you agree on the contracts We take them put them into static JSON files and go and start building your entire front-end your applications are very close to Going life your peers are still not ready and by the time your APS come in ready They're different from the contracts that you have gets very frustrating And I think that's where graphql's beauty comes in because that solves a problem for you So one it's a very Sorry, that's an example of mocking so I set up a graphql server I define my data types and you say these are my data types and this is how my Schema is going to look like that's all that I need. I don't need to care about anything Now because graphql knows that every field is associated with a certain type It knows what to respond back with so if it's an integer is going to respond back to the random number It's a string is going to respond back with the hello world That's how you can do that and that's a small library that actually does it for you So over here there's a small module which says add mock functions to schema It's available as a part of the graphql tools the ones you import that in Mocking capabilities available for you over here. I can go in and try so I've got a couple of queries and You know you can see that I've just named the queries. I say got a query called with an name called author Maybe I can go and run that if you're going to run author on the right hand side You see the responses have come up. So that's all mocked data So whether there's an integer field it will respond back with a random number if it's a string It's going to respond back with the hello world because that's what my module is providing me right now Which sometimes isn't very great. You know, I want to have a little more realistic looking data Or I want to get more control over my mock data. I can probably do that So thankfully I can go in here and I can define that if it's an integer Respond back with a triple one in this particular case So if you notice Where there's an integer it will show up as triple one. Maybe I can go in and add a age field over here Let's see how that works. So H would also show up as a triple one If I want to define a certain string Simple enough, so that's my custom string that's going to show up now for every sting value that there in the system if I want to get a little more creative I can actually get rid of that and do something pretty crazy is like In the string because it's a function. I see I create an array of random strings and I randomly assign a single string to Any random value that showing up over there. So every time there's a string it'll randomly pick up an element from the array and show It up over there. So that's how you can start over customizing your mock data, but you can do even better There's a very nice library out there called casual. It's a nice npm module called casual You can input the casual module in and what casual does is it creates very realistic looking fake data for you so yeah so I can input casual in and Over here say for example, if it's my user object, I'm just going to go and disable Come in the score out and I say get me a real looking name and get me a real looking age So if you see you got a nice name called Mrs. Jonathan snub, Sheena and The age is 48 and the reason the age is 48 is because I've defined that I want the age to be a number between 18 to 75 So so that's casual for you. I can even go ahead and Give an address field and when I want I want a stream name. I want a city and You actually get random names of the cities and all of that. So this makes it a really functional mocking server for you Use this get started go and build your entire application Now your schemas are set in tomorrow when your API is ready All you need to do is just go back and add your resolvers to each of the fields your fields do not change They should ideally never change your fields not change and if it feels don't change all the front end application that you build your mobile apps and native apps They're all going to and you react apps. They're all going to work as this is just the resolvers. What are you going to change and do the plumbing over there? So you can take a mocking server and take it to production without having to discard anything away So that's another classic example of how graph kill can actually help quite a bit so there are three types of operations that you can do with graphql the first one is a query which are essentially reads and That's what you saw The other one So that's how a graphical query will look like you essentially pass an object These are the three fields. I want to respond back with those three fields The second are mutations so mutations are where where you go and update record So these are right operations and in a mutation you pass the parameters that you want to change and you pass the parameters that Graphql should respond back with after the change has happened and they could be different They don't have to be the same in this example because they're likes I'm just responding back with the like but I could say update the likes but respond back to me with the name of the product That is there that will still work The third is subscriptions and I think that's one of the coolest features here. So Subscriptions allows you to do real-time reads on specific fields and they keep listening to certain mutations So even if a mutation happens the subscription will trigger and those fields will start showing up Now from a query standpoint, they're pretty much similar to the way you work with a read query But things start to change on the server side So so I think till about a few months back these specs for the subscription was still in draft mode And they were not fully released But the Apollo team went ahead and kind of released a full fully featured version of subscriptions on the Apollo server And that's primarily based on web sockets So if you want to use subscriptions in your application lead to do a little more You know for queries and mutations is just about going and adding a resolver function and you're all set But with subscriptions, you have to go about setting up a small Subscription endpoint you need to set up a subscription endpoint and you need to set up web sockets So this is on your express side prefer code additional and In your resolver you'll have to use pub sub so use a pub sub to keep listening to an event of a mutation and every Other event mutation is happening. It's going to go about updating the fields So for me if you ask me, I think subscription solves a lot of Modern-day problems that we have faced right so just so one of my pet peeves is this you know We live in a tablet world we have like 30 40 tabs opened up in a browser and out of which seven or eight Tabs belong to the same application that we have like we work on github I work on github pretty often and I'm working on a repo. I got a bunch of PRs I got a bunch of issues that all opened up in different tabs I've blown close a couple of issues merge a couple of PRs and my damn count is different on every single tap So the I'm count count of opening issues is very different. I guess very frustrating So need to keep refreshing each step to make sure that my counts are all same same as a thing with e-commerce, right? I've got four or five different product pages opened up I've added a couple of them to the cart and my cart items and cart number is not the same across different tabs And and I think that's where subscriptions can actually come in and solve that problem for you So this is a small example that one of my colleagues built in Shalini is Shalini around here? But so Shalini is a very young colleague of ours and you know I kind of help her out with GraphQL and today can you help me build something with subscriptions and she came up with this down in a couple of days So what this is is a product listing on the left hand side and it's a cart on the right hand side And you got subscriptions enabled for your items to cart and your cart page every time a product is getting added to the cart Yes, up things should start popping up over here without having you to do a refresh She's had to cut immediately it shows up on your cart page and the count is also changing on the top So now your browser tabs are all synced with each other So that's a small video of how subscriptions can work in Query fragments. I think another cool thing about GraphQL. So if you remember at the start I talked about how you have queries How every component can make a demand of the data that it needs and it'll pass up to the parent in GraphQL you do that with something called the query fragment and if you look an example over here on the top There's probably like a card component a profile tile can call it as so you got a profile pick You got the name and some information on what the status is and how long have they been a member? So all the data is now created as a fragment and that fragment will simply define that hey This fragment is called public profile It's on type of the user type of person and it's got a name field profile field status and a message and Then you also have another component called the billing component billing address component Which defines that I need the street address. I need my city. I need my state and we zip code so on and so forth So every component I just define the fragment of the data that is required for that component And then what happens is on the parent level using a simple spread operator These fragments are pulled in and your entire Query is built. So again a simple example for this so on my left hand side is The whole GraphQL schema. It's got all the information about the user first name last name display about the blah blah blah every single thing And what I've done in my query is I simply create small fragments So this is my public profile information which simply shows display name and avatar and I've got my private profile It's got more information with things like email Billing address and stuff like that and then depending on what page I'm going to query from I define What data should I be pulling in if it's going to be my personal profile page logged in profile page? I want to pull in both my data if it's just my public profile, then I'm just going to pull in my public profile information So if I query profile page I would probably get all the information in so data from my public profile and also from my personal profile and if I query only Public profile I get only those two data points in and now because these are fragments I can just go in and I can so for example I know I know this component is being used in like five or twenty different places and now your project manager comes in and says Hey, you know what just can you just add this one additional field over there? Which essentially means you need to go and add it and all the different places not only the component But also the component is probably the same place But the APA that's been using we'll have to make sure that that feels are available all over there But now with very fragments. I just need to do it at one place So I could just define it over here and every single place where this fragment is being used will automatically that additional information of members since And that's all casual by the way. That's casual mock data. That's out there So right from date and everything can be pulled in so that's graphql fragments for you. Okay, so So these are a couple of good things about graphql There are a couple of not so good things about graphql and the first one is the classic n plus one query problem Uh, so the way graphql is structured right every resolver function runs asynchronously asynchronously within a promise What can happen due to that is the same record can be hit multiple times So the n plus one problem is where you got multiple queries hitting the same record and returning back with the same result And that happens very often with graphql So if you see this example over here, I got a list of friends And I got a best friend for each of those friends And there's obviously a convenient possibility that that my best friend is somebody else's best friend also And when I run a query like this, what happens is on the network is or on the database is going to make all these calls And it will realize that the person with an id2 is getting called multiple times, which is essentially not a very good thing And that's a problem happens very often with graphql And I can probably show that with a small demo So the same example that we saw put it up in graphql. I got a list of friends and I'm trying to get the name of the best friend and also my friend's best friend So when I run that I get to see a bunch of names And you'll obviously notice that some names are duplicating over here. So shellesh for example Is the best friend for a lot of people. So his name shows up here multiple times And on the database What's happening is that particular id is getting called Multiple times and that's the problem. So to solve this you have something called A data loader So this is a very small library that lay by and put together apparently it's like I mean He and is one of his friends sort of where programmed and wrote it in a coffee shop And he's just about 300 plus lines of code So very small library, but this sort of solves the whole problem of rn plus one And it does it in two ways So your data loader basically does just two simple things it does batching of all the queries and secondly it does Caching of the records that have already been queried for Right and if I have to go and enable this in my application reasonably simple I would go and import my data loader in And I also obviously create a new data loader instance And then in my queries where I'm simply doing A very regular find by I'm going to route it via my data loader So I'll just save it I run my same query again. I get the same results Which is great, but the good thing also is It's just like one So one call went into the database for the data. So at the most you just get one or two calls So that's later data loader And I think if you're using graphql on the server, you should definitely give this a concentration The next thing is uh, so a lot of A question that keeps coming up very often is how do you do authentication and authorization with graphql? And I think the plain and simple answer to that is you don't So as per the specs and for the guidelines, it's recommended that you do not do any kind of authentication in the graphql layer But uh, you kind of do it above and below. So just to get everybody on the same page Authorization and authentication is likely two different things right authentication is where you want to validate whether the user who's coming in Is a genuine user or not? So if the person is a genuine user then let them even access the api They're not a genuine user Just return back with an error and don't even let them touch the or api. So that's authentication Authorization on the other hand is you want to check whether the person who is making the transaction Is he authorized to make the transaction or not? So It could be like, you know, if you're an admin, then you're able to make right changes to certain fields If you're not an admin, then you're only able to read so that's authorization And the recommendation is that you separate them out and you do it this way So you have authentication on the top so you sort of in your express layer or in your server side layer and once that is uh And once your authorization layer is there and the first request that's coming in is valid Then it goes through your graph ql layer, which is transparent doesn't do anything And then it goes and checks on your authorization, which is essentially Sitting on your business logic or in a database layer And then if that's valid, then you allow or disallow certain transactions to happen So that's essentially the recommended practice that how you recommend using using authorization or authentication with graph ql If you're using node and express very standard tools, you had use passport You can use the jwt tokens. You can use by crept the standard things that you do So they all on the express layer that's there graph ql you do not want to ideally do that Having said that you can do it if you really want to do it, but the recommendation is that you do not Sure, I did not do that So that's about it. Okay quickly Uh, let's try and play a small game So this is an application that we kind of built together It uses angular on the front end because angular is an awesome app. Yes and It uses graph cool, which is a hosted version of the graph ql server And app is very simple. Essentially it shows you a bunch of libraries go click on it and just vote for a library Uh, it it has all three implemented in it. So it is using queries to read the list of Libraries and show it to you. There is a mutation. So you don't have to click on a star It goes and mutates the value of that particular object And with subscriptions, it will keep sorting and making sure that the the library with the most number of stars comes first It's on firebase and it's using free graph cool So not so much of traffic or load is going to take but let's give it a shot So that's a url if you guys can just open up your mobile phones and try and Hit it bit.ly slash get hyphen stars. So bit.ly slash get hyphen stars. That's the url open it up on your mobile phone You see a bunch of libraries Sorry, get stars. So go ahead and start if my subscriptions and if my servers hold up, hopefully you will see these The library is opening up. You can try and see if they're in staying in sync with what You are clicking and what i'm getting to see. He was moving forward Nice to see angular out there. Let's react our react the angular move forward Wait a minute and then you can just stop it so Yeah, so anyway, that's a small demo out there and the codebase is also available on bit.ly slash get hyphen stars hyphen code Essentially take it to a GitHub url and go and play with it. Like I said users angular for with aot and users graph cool in the back end So that was about it for the demo and so I never was an opportunity to give public service announcements at js so So we as a community are extensive users of open source pretty much every tool that we use every library that we use is open source our npm projects are you know our npm modules have anywhere around 800 to 900 Modules in and all of them are free, right? So we're huge consumers of open source and I think it's sort of time for us to start contributing back To the open source community and you can do that in every possible way very small small things You know, obviously you can raise issues Over your various libraries that you're working on and not only just raising issues I think it's more important to try and make an attempt to fix those issues So try and make an attempt to fix those issues raise a pr Try and see if you can do some improvements on this. I think just in the course of me doing the stock I found I was just obviously playing through a couple of github libraries and I found there are so many opportunities for me to contribute back in terms of improving their code simple things, you know like Missing out of package.json just going at those dependencies in or as simple as your npm start script is not probably using nodemon make it use nodemon So very simple things do very small small things But start contributing back to the open source community because unless you do that Uh, the core people who are maintaining this is probably getting burnt out trying to just answer all your issues. So That's one if you are Getting started with open source, uh, the talk was happening down there was many went for a moment Otherwise there's a very nice article on medium by kensy dot which is first time was only go and have a look at that It talks about how you can start contributing to open source And also in github go and look out for these tags called first time was only beginners or help wanted so Pretty much a lot of libraries of their web pack and angular and so many more they have Tasks which are simple Which are more you know, which new people can go in and start working on go and search for those particular tags For those repose see if you can make any contributions and send keep raising prs I think that will really help us grow as a great open source community And that's about it from my end. We will take questions. I still can't hear you Hello, yeah, yep better. So, uh So this is about probably the demerits of graphql how we can You know get into trouble with using graphql. So typically rp applications. We want to authorize So as if someone has rolled this he can only Uh see these fields and he can only uh, this is an important call because this is put In graphql. How do you handle those things? And sometimes it probably becomes an overkill if you are using graphql for such applications I think graphql makes sense. Uh, when you're you've done something like Give me all the comments for this user id and then for that comment give me the user id and for that user id give me all the likes Where the schema is more dynamic But in applications you want to restrict what the user wants like you will say that once a user hits this I'll only give him the specified response. So what are your views on this? So I would kind of disagree a little bit saying you cannot use graphql for enterprise applications You can but to answer your question with regard to how so I think a question is more with regard to How can I selectively show certain fields to a user based on the type right? Yeah, so so What you can do with graphql is so there are directives called skip or include So I can say at the rate skip or at the rate include and I can mark certain fields for that So, you know, for example, you can use query fragments with the classic example was a public and private So there is a public private profile I can put it under a directive saying at the rate include and I say if that user category or bullion is set to true Only then include these fields. So even though it's a part of my query, it will not render it unless my condition is set on the top So that is possible with graphql selectively showing fields The other question was with regard to sorry Yes, so Yes, so your graphql sort of gives you access to all the schemas that are available But then the person who's building an api for you So if you look at the person who's building an api, he or she also has access to the entire database in a certain way So the same person is the one who's kind of transferring on to graphql. So I wouldn't But then like I said, if you look at the example that I showed you the authorization You could still have authorization on your microservices layer So even though you have that field in graphql, you could still reject that at your microservices layer or on your actual core application layer Let's do that We have time for one more question So I am new to graphql. So, um, and I would like to know a little more about the uh server side deployment That's that's what I would I would like to know all right, um, so One of the one of the when you say someone's a deployment, do you mean languages or how are they deployed? Yeah Yeah, yeah, so so specifically like can I can a single server also cater to graphing as well as a rest base calls or that has to be a dedicated servers No, they would be different servers. So yes, they would be different and um, how how do they interface with database? So like I said in graphql, when you have a resolver function inside the resolver function You could write whatever code that you want to return back So if you want to write code to hit a mongo db database or to hit an interest api and bring it back You can do that. Okay, so it's nothing to do with graphing as such No, so graphene. No, nothing when we say it's a graphene Or graphical graphql. Yeah So graphql is like the server language graphene is I think is an open source tool that allows is similar to graphql Actually, it's I think a product of graphql. Yeah, I think that's just a spin-off of Yes, it's a graphql implementation on one of those languages. I think I have a number on my list So that's a python port of graphql. Yeah, that's there. Yeah, and uh, so it is just it works just like graphql It is a graphql server Um, another thing is, uh, can you show me, uh realistic request Not not just the payload, but I think this might be something better taken offline so that we can let everybody go home So you want to see how a network looks like with the graphql? Yes. Yes. Sure. I can show that It's essentially just a post with an object attached to your url So even a query is going to be a post. I'm sorry even a query is a post. Please catch up with Vinci after the talk Thank you very much