 Yeah, Roy, feel free to share and just scream, I guess, and start with your total force. Yes, we'll do. Yeah, the audio is great. Oh, hi, thank you. Oh yeah, do you see my screen now? Sure, everything is great, so you can go for it. That's good. So hi, thank you all for being here. Like if you've missed my introduction, so I'm Roy. I work and live in Amsterdam and I'm going to tell you something about testing GraphQL. So before I'm actually going to tell about what testing in GraphQL could look like, I'm going to ask the question, who is this talk actually for? Because a lot of people I know, they actually don't test their code. So they either test the code in production or they test it just by clicking some buttons and then pushing their futures to production. So I'm not saying you should test your code with code. You can also have manual testing or there are services to help you with testing. You should always think about how to test your code. So like I told you, I'm Roy, I live and work in Amsterdam and most of my time I spent on working for the city of Amsterdam, where we develop open source products. And we also develop some GraphQL servers built on top of internal APIs. And I also work with some other companies and you can find me on Twitter with the handle at gethackteam. So if you've got some questions after the talks, that you couldn't ask in the live chat, then make sure to find me on Twitter. So why write tests? So there are multiple reasons to write tests and it isn't only to be safe to be sure about your code, but there are also actual reasons to test your code. So one of the things I really like is check if code behaves as expected. And this is something you can do in a lot of way because it's really simple to test simple code. So if you have a function that sums up to numbers, it's really easy to test that code behaves as expected. But if you have a function that calls other functions, maybe it is a composed function, or maybe it's even an entire UI, you want to make sure if the code in the neatest test is behaving as expected. And something else I really like to do is check if errors and edge cases are handled correctly because a lot of time I write error messages in my code or I have edge cases that I don't really document. So if you don't document them, probably the next developer working on the project or maybe even yourself, if you look at the code after a year, maybe you don't even know what the code is about anymore. So one of the things I really like that writing test for is for errors and edge cases because edge cases should really be documented. And there are more reasons to test your code, right? So other reasons are making refactoring easy. And especially if you're not using something like TypeScript, just like plain JavaScript, or maybe even like Python, if you start refactoring your code and you don't have any tests in place, it's really hard to make sure that the outcome will be the same. So I talked about the edge cases just before. If you have edge cases in your code that aren't defined somewhere, like in documentation or in tests, and someone starts refactoring, then there's a really big chance those edge cases will get lost. So the next developer will probably write new code, refactors everything, and then maybe that one moment when someone pushes a button from a certain location, your edge case will be gone. And yeah, so it also improves your code quality, in my opinion. So if you're working with code reviews with team members, then probably your codes get better after every review. If you are writing tests for your code and it's really hard to write a test for your codes, then probably your code is hard to read. So if you don't have someone to review your code, you should definitely review your own code by writing tests and see how easy it is to write a test for the outcome of your code. And the same as I told about the edge cases, test can also be documentation for your code. So improves your code quality, right? Because who likes debugging? And about documentation, it can really serve as documentation, because if you look at this function, so this is from a design library I've been working on, so you're gonna import some functions and then you're gonna test these functions. And then you can actually write down what your test cases are. So maybe your test case is to check if it returns undefined, maybe it should throw, maybe there are other test cases you want to be in there. And especially if you're familiar with test-driven development, and something like this is really helpful because test-driven development is gonna help you document your code before you even write the code, which is actually a really great approach. And this is something you can have for GraphQL as well, both server side and client side, but we'll have a later or we'll have a look at that. So what can we actually test when we're testing GraphQL? So we can test schemas, right? Especially if you're working with schema-first designs or maybe you're programmatically creating your schemas, then you should definitely test those schemas. So you should know, you want to know if your field is actually a string or a number before it goes to the GraphQL query. So you don't want to test your schemas on runtime because it's gonna throw errors. You actually want to test your schemas maybe in compile time, or maybe even just when you're running your test and you're pushing your code to production. So these are ways to test your schemas before actually having users use the schema. You can also test resolvers, right? Because if you're familiar with resolvers, and you probably are unless you've only been using GraphQL client side, but you can test resolvers. Resolvers are just functions. They either async or the synchronous. They probably have promises in there and they're probably gonna make a connection with a database, external services, maybe internal services. And these are things you can test. So you can test if your resolvers are collecting the right data for your responses as defined in your schema. So you should really have a separate look at testing schemas and resolvers because they're doing different thing. But in the end, they can come together and they can be the same, they're gonna share the same tests. And are there more things you can test on server side? There probably are, right? Because maybe you can also test performance, performance of your GraphQL server, server side, and maybe do a performance testing, see how many concurrent users you can have, what will go wrong if you're sending the same query like eight different times, or maybe sending the same query with eight different arguments. But these are all things you can do with performance testing. Or like I told you, you can test client side. And this might be really interesting to test the client side because in that scenario, you're not actually testing GraphQL or how GraphQL works. You're more testing if the libraries or packages you're using for GraphQL are working as expected. So with how to test GraphQL, so with the schemas, resolvers, and maybe you want to test how schemas and resolvers work together, right? So how to actually test this, the multiple way. So one of those things you should have in there is static type checking. With static type checking, maybe with TypeScript, or maybe just by utilizing the schema itself, you can make sure that there won't be any incorrect fields in your schema. And also unit test, like the resolvers I told you about, they are functions. So they could be really easy to test with unit test. Or maybe your resolvers will have helper functions or utilities, those probably are really good to have unit test. And integration test is for situation where you want to combine your schema, your resolvers, and see if they really have the correct outcome as you expect. So maybe you're gonna have an integration test that's actually checking your schema to your resolver, and then maybe even sending a query or mutation with it. And then where you can test the entire flow or parts of the flow, which is very similar to end-to-end test, right? Because you can imagine there might be an end-to-end test where you're testing something client-side. So you're requesting a query client-side. This query is gonna be sent to your server and your server should be handled with the schema and the resolvers. So that way you're probably testing the entire chain for GraphQL, both client and server-side. So that could be an end-to-end test. So the strategy for testing, and probably if you're really into testing or you've read a lot about testing yet, there are different strategies to test your application. No matter if it's a server or a client, there are different ways to test applications. So one popular approach is the pyramid approach. There is probably the oldest one just as pyramids. It's a pretty old approach for testing software in general. And there is also the reverse pyramid. So both are actually patterns you could use for testing. And let me tell you about the first pyramid first. So this is like the traditional pyramid of testing. And as you could see, it's a pyramid. So at the bottom, there's a lot and at the top, there is less. So usually you would have type checking like right down the middle, right below the middle. Because type checking is important. It's really easy to do a lot of type checking and it also runs pretty fast. Next to type checking, you also have unit test in there. So unit test and type checking, according to the traditional pyramid of testing, they should really form the basis like the fundament of your testing pyramid. And then in the middle, there will be integration test. As integration test, they're a bit harder to write because you're actually gonna connect multiple surfaces or pieces of code. And that's why they also run slower. You're not testing a single function or a single object you're testing, multiple functions, how they work together, maybe even doing some front end and back end at the same time. So integration test, you can test like it's more mission critical and it takes longer to run. It also takes more time to write. They're definitely helpful. And at the top, you can find end-to-end test. And those are really testing your entire chain. So you can imagine these tests are harder to write. They run really slow. So that's the pyramid of testing, right? So you have a pyramid, unit test, integration test in the middle and at the top, you would have end-to-end testing. And then you could have a reverse pyramid. And this is actually, if you talk with business managers, they probably really like the reverse pyramid because reverse pyramid, there's a lot of end-to-end testing. So if you're asking non-technical people and they want you to test your code, they probably say, yeah, we're going to test if someone clicks on my checkout button if they will actually buy the product. That's something it's really hard to really test this real good because someone clicks a product in your client, is going to send requests to servers. It should resolve, it should give information back. So if you're really technical, you'll probably feel this is an anti-pattern. If you're a business manager, you'll probably really love having a lot of end-to-end testing in there. And then quite recently, or maybe like a few years ago, a new pattern erupted for testing. So out with this anti-pattern and a new pattern came in, which is actually, it's a Champions League of testing. So this actually is a Champions League trophy, I guess. And actually the idea about this at your very core is static type checking. So static type-chapping should be at the base. You would have some unit tests above and you have a lot of integration tests because integration tests, they are important. Integration tests actually test multiple pieces of code together and end-to-end tests, they're at the top. There are some less end-to-end tests but there's still quite a lot. And basically what this trophy is saying, every type of function should have their own sort of testing. So you can't test all your code because the coverage of 100% is really hard to get there. And also integration tests, they're more important because you can test the one function work, you can test if the other function works. It doesn't really mean that both functions will work together. So there are different types of testing and for GraphQL actually like this approach. So you can actually, you can split it around. There are multiple use cases. Resolvers have their own kind of testing. You should definitely test resolvers and schemas together. Maybe you shouldn't test whenever you're sent a query if your resolver's being called right because your schema can probably handle it. So let's start by looking at testing schemas. And testing schemas, you can do them in a lot of different ways. Something I really like with testing schemas is you can actually check if your product type which I've defined on the left actually matches the product type as you want it to be. So I'm not sure if this test actually says something because you're just testing if of your abstract syntax tree from GraphQL on the left side is equal to the right side. So this is a test you could make. I'm not sure if you actually get real advantage out of this test. So for bigger schemas, there are other ways to test it. And one of the packages I really like for this is EasyGraphQL. And EasyGraphQL is actually made by someone who works for Cypress, so he's really into testing. And it's really easy to install as well because it's just an MPM package. And you can use it for mocking, for test assertion so you can test if your schema actually fit certain criteria, if you are allowed to make certain queries. And it looks something like this. So at the very base, you're gonna start with importing your schema because without a schema you can't test the schema, right? So basically you're gonna feed your schema to EasyGraphQL tester and you'll be able to test assertions to it. But for sending assertions, of course, you should mock it because you have to make assertions with some kind of data on mind. So you can see it on here. So I'm testing a schema, you can see it's a query and I'm gonna send a variable in this as well. And at this part with tester.mock, I'm actually gonna send my query, I'm gonna send my variables and I'm gonna say I want to mock stuff. So now I'm actually testing if the review is field of my product, if it will be an array. And you can even extend this test by seeing if it will be an array with a certain length, with certain fields in there. So these are things you can quite easily test with this one just by using this package. And it's gonna save you a lot of time writing assertions with maybe enzyme or just or whatever you're using on your side. And just gonna see if you're mock actually returns data. And of course, instead of mock data, you can actually use your real data or maybe even create mock data if you want. Or assertions directly. This is actually something I really like because if you look at this one, it saves you a lot of time. If you look at the previous one, there's actually a lot of saying here right here, we have a query, you have to find the abstract syntax tree and you're just gonna have easy graph test or see if your product ID will return a certain field for something. So now we're actually testing whether my query works. And you cannot find all information about this package on this website. You can also just go to NPM or go to and find the project there. So for schema testing, it's really nice to have easy graph query because it saves you tons of times. So resolvers, resolvers are actually, they're a bit different to test, right? Because there are a lot of stuff, there's a lot of stuff at stakes for testing resolvers because maybe you have a database or existing services beneath it. So resolvers, they are a bit more tricky to test. But there's one important thing you should keep in mind. Resolvers should be pure function. You don't want side effects in resolvers. You want every side of, every effect for your schema to have its own resolver. And then you probably want to merge them together later on. So you don't want resolvers to be something else than pure functions. And if they aren't pure functions, it's gonna be really hard to test them. But it will be even more important to actually test them because if you don't test functions with side effects, you're probably gonna regret it later on. So pure functions and your resolvers, actually they should be a black box, right? So you would have this black box, something goes in, maybe it's beer, it's some friends. It goes all, everything goes in the black box. And what you want to know is the outcome to black box, right? But no matter what happens inside the black box, so your pure function, you're pretty sure it will always be fun. So there will be a lot of fun coming out of your resolvers if you put some friends and beer in there. At least that's what I suppose. But so pure functions should be the same way as this black box. So you send something in and you're pretty sure whatever you send in, it will return something based on what you send in in an expected form. And that's what your resolvers should do, right? Because resolvers, they should get the information for your schema, from your database, for your services, or maybe from computing it somewhere else. So for testing resolvers, it's quite easy to just write a search in. So you're gonna send in, so I have a function or maybe a resolver, invite friends, probably link to mutation. You're gonna send some variables in there, so six friends, some alcohol. It should be a success, right? So whenever you send this mutation, you're probably gonna be pretty sure that you're gonna invite friends, six in total with some alcohol. The outcome should be success party, and maybe it should mutate some field. So these are all you should do with your resolvers. So in practice, this means something else, right? Because this is all pure theoretically, but you should also write code to do this for you. So you would have a resolver. It could be something like this. So maybe you're getting reviews for certain products. We just saw someone talking about an e-commerce store. This could actually be a resolver for that e-commerce store if it was written in JavaScript, right? So you're gonna send the parent object in there, which is probably a product or maybe it's reviews, some arguments and the context. And it's gonna return probably the reviews. So it's a pure function. There are no side effects. We aren't calling anything in between. And then to test this pure function, you can, if you're using JavaScript, like I usually do or TypeScript, you can just use just for it. So we're gonna test this resolver. We'll return the reviews. So we have an object that probably should fit this object. You're gonna see if it equals and it does. So this is all you need to do if you're testing resolvers. So maybe you have some normalizations in there. You probably should test those normalizations as well. And then we get to a bit more tricky part, right? Because we already saw a schema testing, which can be done with easy GraphQL tester. This is our resolver testing, which should be done with Jest or whatever is your program language as you're using. An integration test, actually, you're gonna bring these two together. So you wanna test your schemas with your resolvers, it resolves with your schemas. You want to test if queries work, mutations work, if they generate the right information, if they mutate, whatever you want them to mutate. So these are stuff you do in integration tests. And like I told you, integration tests, they will be a bit harder to write than unit testing. And you can actually see the schema testing we did, a sort of a unit test for your schema. So we're actually gonna bring back multiple unit tests together, right? We have unit tests for schemas, unit test for resolvers. And now we're gonna write an integration test that's gonna see how they work together. And for this, you actually need to mock your server because you need to get some information from somewhere. And yeah, so mocking is probably the easiest because if you aren't mocking at this point, you're probably testing against your real server with your real client, which you shouldn't actually want to do. And integration tests, they're also a bit funny to me because you can test if two functions work together, but it doesn't mean the entire houses built correctly. So maybe you're just testing, oh, I built a new house. Let's see, oh, I've got working electrics and I got a front door. Doesn't mean you have a house. So integration tests, they aren't like the Holy Grill, but it's a step towards getting to that Holy Grill. So Apollo has some cool functions to do this, to have server mocking and have integration tests. So assume we're using Apollo server, you're just gonna set the mocks variable to true. So this is the, if you're gonna instantiate the new Apollo server, you have some fields, some options you could put in there, and you're just gonna say mocks is true. So now a Apollo server will mock whatever you're using with your schema resolvers. And you can actually try this together with postman. So I'm using postman for mostly when I work with REST APIs, I want to get the return of the REST API. But now postman also have option to send GraphQL. So you can use GraphQL queries in postman just from the interface. And basically it means you should have a pretty new version of postman installed. That means you can send GraphQL queries just from postman. So instead of using GraphQL Playground, you can just stick with the tools you already have like postman. And I've created a test for this with some code here as well. It's probably easier if I send you a link afterwards as well. So you can actually see the code, see what I did there, and see how I'm testing my server GraphQL. So schemas and resolvers, that kind of stuff. So on the client side, there's other stuff you can test as well. Because so far we just go with servers. And servers are usually easier than clients because the only thing that's happened, you have schemas, resolvers, you're sending some stuff on and on. If you're testing client side, we also have to test the tools we're using. So my preferred tool for the front end is React. So which mean if I'm testing client side, I should also test React. So I should test if I can send reps, how to handle local state, all that kind of stuff. It will be here test as well. So client side testing is a bit more complicated. That probably looks something like this. So what I've done over here, I've used Apollo query components, and I'm sending a query to get some product information. All the query components returns me some variables like loading, error, data, and I'm gonna map those. And this is like a pretty simple front end application, right? I'm just gonna get some data with a query and I'm gonna display them in application. And something we actually want to test is this component, right? We want to see if our query component returns the query. And so forth, I want to test the query component actually renders all the other stuff that we put in there like how to display the products. It should actually run right on this scenario. So for this, there are things you can use and something you can use is the mock provider from React Apollo. And also you should need some sort of testing library for React. So in this scenario went for test renderer from React. You can also use React testing library or enzyme to do this for you. So the first thing you need to do, we actually need to mock the GraphQL client. You don't want to work with a real GraphQL client because then you're probably gonna test Apollo's products. Well, actually they should test around product, right? So we want to test the code that's in there so we're gonna mock a provider so we don't have to deal with actually live data or maybe any other data that shouldn't be in our mocks. And a test pretty much look like this. So you should mock your data, mock the response of the query component like we did on the right side. Then on the left side, you can see we have a mock provider, we're sending mock data. We're gonna render our products component and we're gonna see if our products components is rendering their correct products. Actually we're gonna see, we're gonna look for a H3 element and we're gonna find it in our component and then we're gonna expect this H3 element to be displaying the title test. And if this all works, it works. And we can also use snapshots for this but I'm not really a fan of snapshots. So I would probably prefer to go just by seeing is the title set correctly? Do I have the correct amount of products rendered? These are all things you can easily test client-side. And for this, I also created some code. And again, I will post this code later on so you can display it on your own. You can also post it on my Twitter after this. So this is a really pretty basic forward example of testing client-side react with GraphQL. And for end-to-end testing, there is more stuff you can do because end-to-end testing like we told you, you're gonna test the entire chain of GraphQL and your client application and your server together. So for this, we're gonna use almost the same tools except for this time, we're gonna be using the actual Apollo provider instead of mocking it. So before we use the mock one, which means we're not fully testing the server, this one we're gonna go for Apollo providers who could actually gonna test our server which is a bit more exciting, right? Because now a server comes in place. Before we just mocked everything, now our server might send us some actual responses. And I believe the example for this is also in this code sandbox as well. So if you would open this link, you would go to a code sandbox and you can actually find how to do this. So we covered end-to-end testing. And for desert, something that I haven't told you just yet is you can also use load testing to see what your performance of your GraphQL server will be. So in the beginning, I already told you that you could do some other test server side like performance testing. And for this, there's a package called easy GraphQL load tester, which is pretty great. Let me see if we can get this up right there. So basically, it just kind of takes you some config and it's the same package as we saw before but then a different version. So easy GraphQL is the package that showed you before to test your schema. You can also use it for load testing, basically is this one. And if you are already familiar with load testing, you can see you can already use tools that you use for other load tests as well because let me see where it is. You can use with artillery, which might ring a bell if you've used load testing before. And I believe there's also some other tool you can use it with. Oh no, for now it's basically using artillery IO. So in here, you can have some config in there. You can set a duration like how much you want to test on the arrival rate. You can set some headers and it's all based on a single JSON file. So you're gonna send queries with it, with arguments, get more information out there. You're gonna test against local servers. You're gonna have selected queries, headers. And this is actually the very basics getting started with load testing for GraphQL servers. And if you aren't familiar with this, definitely check it out because you know one of the reasons GraphQL servers should be tested really well is because you could get performance issues. If you look at the GitHub API, they actually expose two APIs. One is with REST, one is with GraphQL. And the response limits for the GitHub REST API are way higher than for the GraphQL API. So you can send like 10 times or 100 times more requests on the REST server than you can do on the GraphQL server. And that's because with all those NIST relationships, it can get quite tricky to co-del the data that you requested. So that's why I definitely should check out load testing. So to summarize what I've told and sorry, I usually speak very quickly, so it's a lot of information. So to summarize, I talked about testing GraphQL and we're gonna use, you should use static type-chipping for it. So type-checking really is important and we're gonna GraphQL because your schema have types. So probably if your code doesn't have types, you're gonna run into problems sometime. We also have unit test because resolver step your functions, you can just use unit test to test the resolvers. And the same goes for the schema. You can also use unit test for your schemas using the package I showed you. An integration test, they're one of the most important things to do. So you want to test how your schema work with your resolvers, how your schema works with your clients. If your client's actually gonna send requests, how to handle those requests, these are things you will do in integration tests. And then to end this, yeah, we saw we can just use and write. So we can mock our provider when you're using client side. We can also choose to have our actual provider in there and test against our live server or maybe your test server or set up all other sort of testing principles with both client side and server side at the very same time. And load testing, which was sort of a small dessert I gave you at the end. But definitely check out that package because you might be really amazed by how your GraphQL server performs and using it and sending like five or six queries at the same time. Maybe you're really shocked, but definitely have a look and see how it actually performs before sending the GraphQL server into production. And the very last thing I want to give you with you is 100% test coverage doesn't mean you don't have any bugs. Like bugs will always be there on any code no matter if the code is 10 year old or a one year old. There will always be some bugs and testing is a way to reduce the amount of bugs to make your code more stable to improve your code experience. It shouldn't be a game to get to 100% test coverage because if you're writing one feature and you can test 80% of it, probably that's enough. If you can't test that last 20% and those last 20% is the most important part of your code, then you did something wrong because you should also test the important part of your code, but you don't want to test components when you're probably pretty sure it will render or it won't render. So pick your battles and don't try to get to 100% test coverage because bugs will always be there. That should just be there to streamline you and to reduce the amount of bugs. So for this, maybe we can take this one offline. So which do we actually prefer? Do you still prefer the old fashioned pyramid of testing or are you actually going to go with something a bit more modern where there is like an almost even spread with integration test, unit test and end to end test because it takes a lot of time to write end to end test but they can be really helpful, right? So let's take this conversation maybe to the chat and see which one do you prefer. And so yeah, if you want to learn more, definitely find me on YouTube, just search for my name and you will find tons of videos about me talking about React or GraphQL. Or just find me on Twitter or Instagram which you can find me with the username gethackteam or have a look at these other two websites to find out more about GraphQL and testing GraphQL both client side and server side. So let's head over to the chat and see if there are any questions from you. Thanks so much Roy. I really enjoyed the talk. It was great. I think like Destin with such like new technology as a type of script, GraphQL and React together is something that we have to like figure out all the people that have to try to have more information about it in order to add up into their protein-grade apps. So is there not, there's not a, there are not a questions in YouTube right now but I do have a questions. So lately I've been working on a like kind of tools that developer are doing always same like GraphQL, like Node and JavaScript in the backend side with GraphQL and API and then React and you know, like taking advantage of the GraphQL scheme as I think also true to have a both, for both sides from the server side from the front side of my types as I know that you do are used to doing that which is great. But I'm trying to figure it out the way that I might have a better, like let's say speed when I'm developing new features in my front end side. So let me put you in context. So let's say we're gonna have a type of script with GraphQL with React. So now in React, we're gonna use a, let's say Apollo, that's fine. So I know that, you know, like testing is super important and we should do a integration test, unit test. But let's say that I'm gonna, you know I'll take all my types from my GraphQL schema. So I'm gonna have, let's say I'm gonna be using what can call giant. And I'm gonna use a red hooks. I'm gonna type all the return data from my API. And also I'm gonna have like 100% that's coverage in my GraphQL side, in the server side. So, you know, if something goes wrong, I gonna get even a custom error with a specific error that I had in my backend side. And I'm gonna send all that information to the front side. So let's say that we have that. So now in the front end side because let's say if I'm like fetching a users and I'm gonna have the type for it and I'm gonna have the, like the guarantee that a GraphQL is gonna return me the data that I asked for. If not, I'm gonna get the customer error. How do you see writing unit test for like simple operation as a fetch data works well when you have to create a new feature. So let's say that tomorrow I'm gonna create a new feature in the dashboard of my application. So would you implement unit test for like, let's say that I'm gonna fetch the user and just display them. Would you create a unit test for that, a let's say new feature that you would recommend or you would really like be confident in the guarantee that the GraphQL is gonna give you. That's it, like GraphQL to be with TypeScript. I stated those types. Yeah, probably if you set up a project like that with a different TypeScript on the front and back end automatically generate your components from your schema. You're probably saved yourself a lot of time writing tests that are a bit useless. So that's a good start. So I'm not really sure on your scenario because I guess if you've statically creating those components from schemas, then probably the only thing you need to test is if React is doing what React should be doing. Okay, so that's okay. The perfect, I think I don't have a fair question that you would really answer it. And then, so let's say that I have this component and that component is gonna have a several state that is gonna mutate the behavior of that component. Then is when you are suggesting to do unit testing in order to ensure that that is gonna do that, let's say by a stateful component container, React, it is gonna do the mutation in the state that it should write. Is that correct? Yeah, so what you want to test is when you press a certain button, will the documentation be sent using your query component or whatever you're using. So those are things you would actually want to test. And for the rest is basically, GraphQL should work with that correctly because otherwise there's something wrong with the components you automatically created and you shouldn't create components that you automatically create because, yeah, otherwise you should just write them yourself because you don't trust them. Yeah, that's awesome. And just like with last quick question, are you running low-test, like high-performance tests in your current application and what could be the best way to start with that? Because I didn't do that yet and I think I'm gonna do that right after the middle. No, so basically I'm not running them a lot of times. I basically when I'm constructing a new GraphQL server and I'm testing different ways of schema implementations, that's when I actually use it. Okay, that's great. So you want to test your schema implementation when you choose to for functions that have its own resolver or maybe have a resolver inside another resolver. Those are ways you can actually test with load testing, see if you could run into any performance issues. Okay, yeah, that's great. It just sounds great. And I think the easy GraphQL, it helps you a lot in order to set this up, right? Yeah, it helps you a lot. And basically it's using artillery IO underneath it. So that shouldn't be too hard to get started with as well. Okay, that's fair, right? So yeah, we are gonna go with card thickness. So thanks so much for joining us from France. Yeah, stop the problem, let's be here. Yeah, nice, sir. Yeah, I will over yet. And yeah, thanks so much for selling this such incredible knowledge. Thank you, sir.