All You Need Is a Contract…

Rate this content
Bookmark

How many times have you had to wait for your backend team to finish building the API so you can start your tasks? What if all you needed to move that task to in progress was the API contract? What if there was a library that did this for REST and GraphQL APIs and, at the same time, taking your tests to the next level? Join me and prepare to enhance your developer experience while learning all the battle-earned experiences of using one of my favorite libraries: Mock Service Worker.

29 min
20 Oct, 2023

Video Summary and Transcription

The speaker discusses the challenges of server state and test maintenance, and how they found solutions using React Query and Mock Service Worker. They emphasize the benefits of defining contracts for faster development and stress reduction. The speaker also highlights the advantages of using Mock Service Worker over mock servers and explains how it allows for easy customization and test overrides. They mention the upcoming release of V2 of MS-Double and encourage the audience to stay updated.

1. Introduction and Annoyances as a Developer

Short description:

In this part, the speaker expresses gratitude towards the audience and acknowledges the hard work of the conference organizers. They also mention three things that annoy them as a developer: unmaintainable code, tests affected by unmaintainability, and late tasks in sprints. The speaker promises to share a story about how they and their team fixed these issues.

Okay, so let me just clear up the room. There's not going to be contract testing here. This is a joke we were talking before coming on stage. Also, I'm going to move a lot, so I'm trying to figure out the spot. That's cool, if I don't get blinded by the light.

Before anything else, React Advance, thank you so much for having me here. It's a pleasure. I'll walk around for that spot because apparently the camera won't get me on the other one, so I'll try not to move a lot.

I just wanted to start this talk with like, I would like to give a cheerful applause, because there was so many hard work setting up this conference for everyone from Git nation, everyone from the tech team. I don't know if you're aware, but when we started today, we were having some issues plugging everything, and now everything is working up already so far, so can I get an everyone that's working on this? Okay. Thank you so much.

So, let's start this because already one minute went away, and there are really three things that annoy me as a developer. The first one is when you have unmaintainable code. You know the feeling. Your code is not really that good sometimes. The more you add, the worse it gets. It's struggling. Yeah, it's hard. And then the second thing that really annoys me, it's when that unmaintainability finds a way of getting into your tests. Now it's not bad that your code is not good, your tests are not good as well. Probably you're not sleeping that well at night because you know what flaky tests feel like. And the third thing that really annoys me, and I'll promise to not start a rant here, is when you have a task that arrives late into the sprint. I know some of you relate to the feeling. Let's picture we have a team where two parts are working on a task and the first part takes 98% of the time, and once the task gets to you, you have 2% of the time. So obviously your product manager is going to expect you to deliver that thing yesterday. And this is a feeling that I could start talking about here and I wouldn't stop.

So let's continue, because I have a story about how me and my team fixed these issues a couple of years ago. So let's start at the beginning on how we had just cleared up the first issue. Me and my team had just defeated the unmaintainable code monster. Because this had been something that is been working around, it was threatening us, it was hard.

2. Server State Challenges and Test Issues

Short description:

The speaker discusses the challenges of server state and how they had to implement various functionalities themselves. They then discovered React query, which solved their server state issues. However, a new challenge arose with unmaintainable and flaky tests. The speaker eventually found a solution and introduces themselves as Daniel Alfonso, a developer advocate at OLX.

And what was the reason? Well, the reason was server state. Now, I don't know if you are aware of what server state is. It's typically the state that exists somewhere on the Internet as external to your application. And it has a bunch of challenges. Caching, deduping requests, data prefetching. There is a maintainer here from React query which you can talk about of many of these challenges and you can probably understand how much pain it is understanding and having to implement this thing by hand and I can tell you that me and my team, we didn't have React query back then or in the beginning, we didn't. So we were implementing all of these things by ourselves and the more code we were having, the worse got the unmaintainable code monster. So we started thinking, why are we implementing this ourselves again? What are we trying to prove to going in this direction? And well, a couple of months went by and this was when a couple of, well, these months went by, a co-worker, like the King Arthur in the Sword and the Stone movie. I think that's how you say it in English. Sorry, non-native English speaker here. One co-worker approached the stone and brought out a 10-stack query. So apparently, this new thing, React query, had just come up and it was the solution for our issues. And 10-stack query brought harmony to our code because now all the stuff and issues we had with server state were solved and we didn't have to worry about implementing that thing for a while that is.

Now, a new threat was lurking in the shadows. You see, that unmaintainability found a way outside of our code and going inside of our tests. Now, I don't know if you remember this image I showed you a couple of minutes ago, but this is Hydra. And you know what they say about Hydras. Cut one head, two more take its place. And this is kind of what was starting to happen with us because now our tests were not just unmaintainable. They were flaky. They were complex. I couldn't sleep at night because I had no trust on what the heck I was doing and now you're wondering, okay, what's the relation? What are we going to see? Well, safely now, a couple of years ago I can tell you that me and my team managed to fix these issues. And the fun part was that all we needed was a contract. So this is the part where I actually start the talk.

Let me just introduce myself real quickly. I'm Daniel Alfonso. I'm working as a developer advocate at OLX. I'm an AGIT instructor and an out-there ambassador and you can find me, I'm going to say Twitter because of the pool before on Twitter and pretty much any social network at the end So Daniel GC Alfonso. Also something about me, I recently published a book called State Management with React Query. Thanks.

3. React Query and Test Issues

Short description:

The speaker expresses gratitude towards the audience and thanks Joshua, Mateus, and Tejas for their feedback. They mention that the talk will be a case study, sharing issues faced by the speaker and their team, and how they fixed them. The speaker acknowledges that implementing software doesn't always have all the answers and that there may be questions about why certain decisions were made. They then mention an issue with unmaintainability in their tests, specifically unit and integration tests.

I would also love to talk to each of you about React Query because you're going to see from this talk it's something that I really love. Another thing, I'm all up for sharing love. And I want to thank Joshua, Mateus and Tejas because they gave me feedback from previous versions on this talk and this made me able to improve it and have the talk that we have today. So please stay tuned for that talk. So can I get an applause for them. Just there sharing the love.

Okay. Real quickly because five minutes went by. This talk is going to be case study. I'm going to show you some of the stuff. I already showed you some of the issues that me and my team had and how we fixed them. Obviously, while I'm presenting, some of you might be thinking, oh, I wouldn't have done it this way or probably I would have done it this way. Well, that's the thing with implementing and doing software nowadays. You don't always have all the answers. Luckily now we had some of them. But when we started doing this thing, it was not the best scenario. So if you have the question on why didn't you do this or why didn't you do that? Well, probably we didn't think about it. Or if we did, there's no reason to understand why.

So just recapping real quick what I was mentioning. Now we had an issue with unmaintainability in our tests. That thing was not working well. And when I mean test, in this scenario, I'm talking about unit and integration tests. And that thing... Whoops. Okay. I'm not going to move again because it seems like it was when I moved. That thing was hard. Because I don't know if you're aware of what are the challenges on testing interactions with server state. But let's just recap real quick. Okay.

4. Data Fetching and Mocking

Short description:

The speaker discusses the process of figuring out the scenario of tests and the need to avoid going to the internet to get data in order to prevent flaky tests. They explain that they started with manual mocks using Jest, but as more code was added, it became difficult to maintain. They then decided to use Axios mock adapter to handle mocking data.

Let's figure out if something is going on. Do we got the signal back there? That's what I'm going to do. Okay. It's showing up again. So... Let's see. Okay. Woo! It's done.

So typically what happens when we're doing interactions and doing data fetching requests, we have the browser and the browser sends a request to the internet and the internet replies with the data. That's kind of what happens typically. So now we're going to... And I'm going to continue speaking while trying to figure it out because this thing is prepared. Now there's another scenario. So what you should be seeing here is an image on tests. So now on the scenario we have tests. And in our tests, we don't want this to happen. We don't want to actually go to the internet to get the data because that would mean we probably get different data every time. That would mean we would get flaky tests. And that would probably mean, once again, you wouldn't sleep well at night.

So me and my team had to figure out the best solutions to dealing with mocking data that come from server state. So we started with manual mocks in the beginning. We were using Jest, Jest FN, a bunch of manual mocking stuff. And it worked for a bit. But the more code we were adding, the worse it was getting. Because now we had to maintain a bunch of these things. And then we got to the other scenario. OK, let's add Axios mock adapter. Because we were using Axios as the client. So now we were maintaining manual mocks.

5. Challenges with Manual Mocks and Axios

Short description:

We were maintaining manual mocks and Axios mocked adapter scenarios. However, every time we made changes, something would break. We wanted an ideal solution that intercepted all requests in one place, without any setup. That's when we discovered mock service worker, an API mocking library that uses service workers to intercept actual requests.

So now we were maintaining manual mocks. And we were maintaining Axios mocked adapter scenarios as well. And then I can swear, at certain point, there was even some sort of magic. Some witchcraft. I have no idea what that code still does to this day. I only know something. Every time I had to update manual mocks, the manual mocks would break Axios mock adapter. Every time I had to break, use, update Axios mock adapter, that thing would break the magic. And you guessed it. Every time we changed stuff in the magic, it broke the other thing. So this was the environment on writing tests every time we had to do them.

It was stressing. It was not working out for us. We wanted an ideal solution. We wanted something that worked better for us. And allowed us to get rid of all the things we had before. So in an ideal scenario, what if we could just have a solution that intercepted all the requests? One local place? We didn't have to do any setup on the testing environment? And by using a contract that we used to specify the API and the data that we were expecting for it, by using that thing, we were able to test our application and not worry. And this would be the ideal scenario. And really, that's what we have. But we didn't know what solution would fit us. And this was when we got to know about this thing called mock service worker.

So mock service worker, for those of you who are not aware, is an API mocking library that uses service workers, a ServiceWorker API, to intercept actual requests. So I know what some of you might be thinking. But wait, we're talking about testing, so that's probably in an old environment. Service workers only run in the browser. What are you talking about? We'll get into it a bit. But let's just recap how mock service works in a bit before we continue the story. So we already saw this thing. Usually, every time we need some data, the browser does a request, and the Internet returns us the data. Now, with mock service worker, there's something new.

6. Mock Service Worker and Setting Contracts

Short description:

There's a ServiceWorker that intercepts requests from the browser and uses a defined contract to decide which data to return. If no contract is specified, the browser makes a normal request to the internet. Mock Service Worker has request handlers and response resolvers for specifying the contract, API, and route. It works with both REST and GraphQL scenarios, allowing you to return specific data for each route. This allows you to set up your own contract with Mock Service Worker.

There's a third user in this scenario. So there's a ServiceWorker right in the middle. So every time there's a request from the browser, the ServiceWorker is going to intercept that request. It's going to check the contract that you have defined within it, and by using that contract, it will decide which data to return. So pretty much, you can have a way to return mock data from there.

Now, some of you might be thinking, okay, but what happens on the scenario that we don't have a contract specified? Well, in this case, we just go to the Internet, we just let the browser do the normal request that it would do, and then get the data back, return it to the browser. And that's pretty much the gist of how mock service works.

Now, for us to understand a bit more on how this thing works, I'm just going to show you some fundamentals of this thing. So the first one are request handlers, and the second one are response resolvers. The request handlers are responsible for doing something, which is, well, pretty much specifying the contract, the API, and the route that you're going to hit. So let me just open this thing here. Oh, I don't want to draw. This happened last time. So let's try to get back here. So this is what happens when you try new stuff on stage. Let's see if I can get rid of it. Try it again. It's still there, but let's ignore it for a bit because I cannot seem to take it. So in this scenario, what's happening is we're importing the REST API. So pretty much we're saying, okay, we're going to have a REST API, and whenever you get a get request, pun not intended, I guess, to the route, Daniel GCFomes, you're going to return a response resolver. And that's pretty much the gist. So you're defining pretty much what protocol you're using, which type of scenario you're going to handle, in which route you're going to hit. But the fun part of Mock Service Worker is it also works with GraphQL. So you have REST. If you have a GraphQL scenario, you can import GraphQL, and you say, whenever there's a query for get users, you return this response resolver. So all of these that we have here, it's a request handler. What we have here is a response resolver. From the response resolver scenario, and let me take this part of here, the response resolver scenario, what you do pretty much there is specify the data that you're going to return whenever that route is hit. So whenever we have a GET request to the Neo4j CFoS, in this case, returning a response, which inside is going to return the JSON object, in this case, with the first name John, and the age 38. And that's pretty much the gist on how you can set up your own contract with Mock Service Worker.

7. Mock Service Worker Setup and Request Handling

Short description:

In tests, Mock Service Worker allows you to set up a service worker or a server to return data based on defined contracts. By setting up a worker with a request handler, you can intercept GET requests and return specific data. If a route is not defined, the service worker will let the request pass through to the internet. This approach helped the speaker eliminate unmaintainable code by deleting all the unnecessary mocks.

Now this is where we get back to the part where I said, okay, this thing works in the test. Because while Service Workers run on the browser, Mock Service Worker also has a node intercepting package that allows you to run in node environments. And this is kind of how this thing works in tests.

So if you set up a worker, you can use a setup worker API to say, okay, I want to set up this service worker that's going to use this contract that I defined, and whenever the browser picks up, it's going to return the data. On the other scenario, you can say, now in another environment, I want to set up server, and this is going to listen for my test. So when my test triggers a request, that thing is going to return the data. So from an example that we have here, we are setting up a worker, so we are setting up a service worker with the request handler that we just saw. Every time there's a GET request to Daniel J. C. Afons, it's going to return the first name Daniel, last name Afons. And then what we do, we start the worker. And this is pretty much all the setup that you need to do in the browser to have mock service worker work.

Well, that was fun. Okay. So let's feature a scenario once again. There's a GET request to Daniel J. C. Afons. The service worker is going to intercept it. So what it's going to do, it's going to ask itself, do I have a defined request handler? And if so, it's going to return the data. And this is pretty much what we saw previously. In the scenario that it tries to get to a route that we don't have defined, like random, it's going to still ask itself, oh, I don't have something. So let's just go to the internet, let the request pass through and send it back. And this is pretty much what helped us save our tests. Because now there was only three steps that we had to follow to get rid of all that unmaintainability that we had. The first one is delete all the MOCs. Delete all the manual MOCs, all the access mock adopters. Delete all that magic, all the thing. It was the best part. I love deleting code.

8. Mock Service Worker and Late Sprint Tasks

Short description:

Those poor requests are amazing. We looked at the contracts of the APIs we were using, defined request handlers, and started our server before tests. Our unit and integration tests were no longer flaky because there was one source of truth for the data. In another scenario, when tasks arrived late during the sprint, mock service worker fixed the issue. This piece of software saved our team from pointing fingers and struggling to deliver faster. It provided a solution when other processes failed.

Those poor requests are amazing. You just go there, like, oh, so much code deleted. It's so good.

Then we looked at the contracts, the contracts of the APIs that we were using, so we just went there, defined all the request handlers for our API and we start our server before our tests. And just like that, our unit and integration tests were working. They were not flaky because now there was just only one source of truth for the data that we were fetching, and this was pretty much me and my team afterwards because now we could rest for a bit and chill because now we could sleep at night. So we had to trust in the test we were building.

Now, remember, that was a third scenario, which is the task arriving late during the sprint, and mock service worker also fixed that funnily enough, so let's recap what was happening in my team. Now, usually, we had two-week sprints, and my team was comprised by backend developers and by frontend developers, and what happened usually when we were trying to build a new implement the respective screens for that was the backend took all this time working on a task. And I'm not criticizing here. Building an API is hard. There's so many stuff that you have to build. They couldn't speed it up enough. But this also meant that during the time that they were doing this thing, we had to do something else. We were building some unrelated smaller tasks, some more smaller tasks, and some more smaller tasks, until there was just this little thing here. And if you remember my intro, this was the time we had left to save the sprint. So it was that 2%. And this, like I said, caused the struggle. We were pointing fingers. We were like, we need to deliver this faster. The PM is all over us. We want to ship this faster to the users. I understand. We want to do our stuff as developers. It's our main goal. But when you have an environment like this, it's kind of stressing. And we can go now start talking about these functions of teams and agile processes and whatever. Probably you could have done that better. But this was a scenario where this piece of software fixed our issue. Why? Someone said, hey, look.

9. Benefits of Defining a Contract

Short description:

If we define a contract with the team, we can work on tasks simultaneously with the backend team. This allows us to ship faster and reduce stress. We only need to follow three steps: define the contract, create request handlers and resolvers, and start the service worker.

Mock service worker runs on the browser, right? It does. Cool. So what if we define a contract while we're starting the sprint? And someone said, okay. But why? What's the reason of that? Because hear me out. If we define a contract with all the team together, we can go into mock service worker and define the request resolvers. We could specify the contract. Yes. And then we can start this thing up on the browser. Yes. I'm following you. And then pretty much we're gonna have an API that's mocked for data. While the API is still not ready. So this means that while the back end is still working on the task, we can work on the task at the same time because now we have defined the contract and then we work against the mocked API. Once we finish, that thing is already in development or in QA environment, we turn it on against the right API and we test it. And it worked, it fixed that issue because now we were pairing work, we were shipping faster and we were not stress anymore. Then we had time to still work on the smaller tasks, but now we were not stressing at the end of the sprint to deliver stuff for yesterday. It made everything much better for us. And once again, we only had three steps to save our sprint. Define the contract at the beginning. Secondly, create all the request handlers and response resolvers. And finally, start the service worker. These three steps that worked on the testing also worked on the scenario now for fixing this dysfunction that me and my team had. Left us all celebrating at the end because it felt good.

10. Open Source and DIY Engineering

Short description:

Org-led engineers deliver amazing things for our users. Before adding to the DIY over engineering mode, consider that someone else may have already published an open source package to solve your issue. These tools saved me time and worries, and I trust them in every project I build.

Now we didn't have to argue at the end of each sprint. As I'm reaching the end of my talk, I want to share some love. Artem, the creator of mock service worker, has this great set of blog posts about mock service worker. Where he goes from all of the inception of what led to its creation, all of the challenges, and recently announced a course on that. I'm super excited to see how that thing is looking up. Just sharing some love, give Artem a follow because mock service worker is great.

On the last two minutes of my talk, I just want to take something home from here and remind you of something, which is, org-led engineers deliver amazing things for our users. Our users want these things for yesterday. They want them fast and they want them working. I feel like very often, and me and my team suffered through that a lot, we were getting stuck into this complexity loop. We were getting stuck into what's called solution engineering versus problem solving. We were getting stuck into the DIY, do it yourself, over engineering. We were stuck in all these tests because we said, oh, we're going to implement all these things by ourselves. What we didn't figure out there is we were losing time. We were losing time that we could be delivering stuff faster to our users. If we're losing time, we're wasting money of our company. So what I'm preaching here and I would like you to think about is, before you add into the DIY over engineering mode, think about something. Probably someone else out there in the world already had the same issue that you have, and probably they already went ahead and published an open source package. And probably that package is maintained, is tested, is secure, and it has even more scenarios than the things that you consider nowadays. So please consider that. Because we have so many great open source projects, we have so many open source maintainers here with us today. So give a look into those projects before you go into the DIY mode yourself. So if I had known 10 stack query before a couple of months earlier, probably, like I said, I would save much more money to my company and to my team. If I had known mock service worker before, I would have saved even more money. I would have saved me sleep hours, which, if you feel like me and you have a lot of insomnias, it makes it worse when your tests are not working. So yeah, these tools saved a bit of the way that I was building software. And they are my favorite. Pretty much every project that I build nowadays, I install them, because, well, they saved me so much time, saved me so much worries. And I really trust in everything that I need. And that was a fun fact in all of these things.

QnA

Contract Changes and Sprint Delivery

Short description:

The fun fact that fixed all the issues that me and my team had at the end, was that all we needed was a contract. Let's just jump into the audience. Let's see what people have to say. What if the contract changes during the sprint? This happened to me last week. Usually, the contract changes that happened are not going to be that many, hopefully, unless they go ahead and rewrite everything. But there's going to be some scenarios that you have some smaller contract changes. And when there are smaller contract changes, it's probably easier to go back, check for that specific scenario than for the entire contract. And at the end of the day, you still have to reiterate over the work you did, but it's not going to be all at the end of the sprint and having to deliver everything at the same time. So the bit that you're going to have to work is going to be a bit less compared with everything that you went before. Nine out of 10 times, the contract won't change.

The fun fact that fixed all the issues that me and my team had at the end, was that all we needed was a contract.

So, thank you so much, React Advanced. I'll be now for the Q&A, right? I had a joke prepared. You had a joke. Yeah, and it's completely lost. It's completely lost. So probably even if I find it, it's not funny anymore. But great talk. Thanks for sharing.

Let's just jump into the audience. Let's see what people have to say. Yeah. Sorry, I'm looking at them there as well. So there's the funny ones there, but I can read them here, but I got a message from our wives. Oh, is everything okay? Okay. Just kidding. Just kidding.

What if the contract changes during the sprint? This happened to me last week. Question from Anonymous. Thank you, Anonymous. This is probably the most answered question every time I do this talk. And it's funny, because that happened to me as well. But I would say that usually the contract changes that happened are not going to be that many, hopefully, unless they go ahead and rewrite everything. But there's going to be some scenarios that you have some smaller contract changes. And when there are smaller contract changes, it's probably easier to go back, check for that specific scenario than for the entire contract. And at the end of the day, you still have to reiterate over the work you did, but it's not going to be all at the end of the sprint and having to deliver everything at the same time. So the bit that you're going to have to work is going to be a bit less compared with everything that you went before. I don't know if that answer the question, hopefully it did, but that's kind of the most common question that I get every time I do this presentation. Yeah. Nine out of 10 times, the contract won't change.

Customizing Scenarios and Contract Maintenance

Short description:

You can define the entire contract and customize specific scenarios for specific tests with mock service worker. It eliminates the need for complex setup like mock servers and allows you to easily override response resolvers for specific tests. As for maintaining the contract, you can add or remove most of it and make small changes manually. Importing from Swagger is not yet supported, but it would be a valuable addition.

So you'll save time and that one out of 10 times, well... Yeah, great sum up. Yeah, that's the sum up. Yeah.

Another question from our active questioner, anonymous, how do you change the mock response per test so that you can test different scenarios in a test specification? Yeah. So that's one of the parts I had to cut because usually at the end of this talk I have a small demo, but well, we have 20 minutes. Pretty much you can define the entire contract, it has answers, it's request response, resolvers, and response. I forgot how to speak, sorry. Like Sara was just saying a couple of minutes ago, native is not my English not my native English, sorry, my brain just went on to answer this thing. Basically you can define the entire contract, but then for each specific test, you can go ahead, you can get access to the server instance that you're using, or in this case to the, yeah, to the server instance and you can say, okay, for this specific test, I want you to use this response resolver. And you can say only for this specific test, you override it. And then everything after that, that's just reset to the default. So pretty much you can customize specific scenarios for specific tests, which makes it a bit more simple than, for instance, setting up stuff like a mock server, if you had experiences of setting up mock servers, that's a huge pain, especially when scenarios like this, because then you have to go ahead and say, oh, okay, for this specific scenario, when I received this parameter, I want you to throw an error. With mock service worker, you don't need to just import the server that you're using to listen to everything and say, okay, for this specific test, I'm doing this and it just works out of the box. That's not a lot of setup that you need to do that. Awesome. Thanks.

Next question from Anonymous, how do you maintain the contract? Does mock service worker import Swagger, for example? Oh, that's a great question. I've been trying to see if that exists for a bit. I think it doesn't exist yet. So there's an opportunity, if any of you wants to try it out. I've been wanting to, but I haven't had the time yet. So usually what I've been doing is, the contract that I had in my team, usually when you build APIs, you either add most of it, or you can remove. But it's easy to remove. It's just go there and delete. And when there are small changes, you can go there in a specific scenario and just tweak it by hand. Obviously it would be ideal if we had something that could improve import from Swagger, like this example here. It would be really good, but to my knowledge, it still doesn't exist. I can question Artem, and I'll try to get back to this on Twitter or on LinkedIn, but it would be really, really good. Nice.

Advantages of Using Mock Service Worker (MSW)

Short description:

The speaker discusses the advantages of using Mock Service Worker (MSW) instead of a mock server. They highlight that MSW requires less configuration and maintenance, and allows for easy scenario customization. They also answer a question about preventing the re-implementation of the backend in MSW, explaining that dynamic responses can be overridden for specific tests, avoiding the need for complex setups.

Right. I'll keep an eye on your Twitter then. The next person is using an express-based mock API and wants to know if there are any advantages to using or switching to MSW (Mock Service Worker). I was on my way here, chatting with some of the other speakers, and I was saying, I deleted one slide on why didn't I use a mock server instead? And someone is going to ask it. So here's the question, and I have the answers prepared for you.

So first, there are like five steps to this question. First, mock servers need configurations. You have to do a bunch of setting up the mock server, maintaining it, and configuring it to run on pipelines or wherever. For instance, if one of the tests fails and breaks the mock server, all the other tests will fail afterward. There are a bunch of disadvantages that you could name for these things. What I really like about using Mock Service Worker instead is that you don't have a lot of configuration. Once you have the contract, you don't have that much maintenance, and you don't have to worry about all the other scenarios. For instance, if we're using a mock server, we would have to go there and configure just a specific scenario. With Mock Service Worker, you just import whatever you add and say, 'For here, throw an error.' So you don't have to configure separate stuff aside. You can include this thing in your own solution because Mock Service Worker is around with your own projects. And the other better part is that you don't need to change configurations in your tests to point to the mock server every time you're running the test. You just start the server, and that's pretty much it with Mock Service Worker.

Next question is from Jack. How do you prevent just re-implementing the backend in your mock service worker, for example, to test the returning dynamic responses based on the parameters? That's a great question as well. For this scenario, most of the time, it's just a simple mock answer, some JSON or whatever, or some text transformations over the stuff that we had. If you need these dynamic answers, then for each specific test, you can just override it in that specific test. So if you're doing a test case on that desk, you can just say, 'Okay, here I want you to return this instead of returning that.' And that way, you avoid having to program dynamic answers on mocks on your contract, instead of having everything set up separately. So you mostly just pass the responsibility for the test that you're doing to give you the answer that you need, instead of adding all the other stuff on the request handlers.

Dynamic Mocks and Test Overrides

Short description:

Most of the time, it's a simple mock response or transformation. If you need dynamic answers, you can override them for specific tests. This avoids the need for dynamic mocks in the contract and simplifies the request handlers.

So let me just really prevent just, okay. So for this scenario, most of the times I haven't had this experience. I haven't, most of the times it's just a simple mock cancer, um, just some Jason or whatever, or some exit transformations over the stuff that we had. If you need this dynamic answers, then for each specific test, you can just override it in that specific test. So if you're doing a test case on that desk, you can just say, okay, here I want you to return this instead of returning that. And that you in this way, you avoid having to program, having dynamic cancers on mocks on, on your contract, instead of having everything set up separately. So mostly pretty much just past the responsibility for the test that you're doing for giving you the answer that you need instead of adding all the other stuff on the, on the request handlers.

Mock Server and GraphQL Schema

Short description:

The speaker acknowledges that they don't have much experience using mock servers with GraphQL. They suggest checking the documentation and reaching out to Artem on Twitter for specific questions. They mention the upcoming release of V2 of MS-Double and encourage the audience to stay updated.

All right. Thanks, Jack. And thanks Daniel. First, next question is, are mock statically checked against the GraphQL schema? That's a great question. I don't know the answer to this one, to be honest, I haven't had a lot of experience with using these with GraphQL. I did some demos, but mostly the environments I've been working at rest based, I would suggest you to check the documentation because it's really, really good. And now they're going about just, they're about to release V2 of MS-Double. Some, some stuff might change. So yeah, my suggestion here is check the documentation and if you have a specific question, this specific question, you can just go on Twitter and tag Artem and we'll probably give you the feedback, right? As you need. So he's the source of truth for this. Maybe Lenz is still here. I don't know. Maybe he knows. He left already. He left us. But we'll figure it out. I'll also try to ask and I'll try to get back to the person who asked this, anonymous, I'll try to find this person. Good luck. Keep me up to date. Okay.

Defining Mock Servers with Varying Handlers

Short description:

The speaker addresses a question about defining different mock servers with varying handlers for requests based on different application states. They explain that you can achieve dynamic scenarios by defining routes in MSW and specifying different parameters for each scenario. The speaker acknowledges that they didn't fully understand the question but encourages the person to reach out for further clarification. The Q&A session concludes, and Daniel thanks the audience for having him.

Oh, anonymous is another one. Can you define different mock servers with varying handlers for requests in example, based on different states of an application. Okay. So different mock with varying. Okay. So you want specific handlers depending on the scenario. Is that the, I'm trying to understand this question. So define different mock servers with various handlers for requests. Okay. So I'm assuming, and that's, I'm assuming if the person who asked here is here and you could clarify, I would love to, but I'm assuming that you want once again, dynamic scenarios, depending on what you have on your application. So once again, usually when you're doing a request, your request is going to go to a route and that route is defined with MS double. So imagine that you have a scenario that you want, you're going to the API A and that API is going to receive parameter B. So this is one scenario, but you also know that you'll have another contract specify that when it goes to the API A with parameter C, something is different. You can just in your request and would specify that specific route and they're probably, there's going to be different states is going to be different routes as well. Or you can just go the other way and just define that in your test. Well, I didn't understand this question so much, so I gave up a bit vague answers, but if the person who asked you this is here, please reach out to me, or if you're online as well, reach out to me and we'll try to figure it out together.

All right. Well, that's all the time we have for Q&A. So Daniel, thanks a lot for joining us here today. Thank you for having me. Now you're off the weekend. Enjoy.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
React Day Berlin 2022React Day Berlin 2022
29 min
Get rid of your API schemas with tRPC
Do you know we can replace API schemas with a lightweight and type-safe library? With tRPC you can easily replace GraphQL or REST with inferred shapes without schemas or code generation. In this talk we will understand the benefit of tRPC and how apply it in a NextJs application. If you want reduce your project complexity you can't miss this talk.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
You will learn about one of the most popular package managers for JavaScript and its advantages over npm and Yarn.A brief history of JavaScript package managersThe isolated node_modules structure created pnpmWhat makes pnpm so fastWhat makes pnpm disk space efficientMonorepo supportManaging Node.js versions with pnpm
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Step aside resolvers: a new approach to GraphQL execution
Though GraphQL is declarative, resolvers operate field-by-field, layer-by-layer, often resulting in unnecessary work for your business logic even when using techniques such as DataLoader. In this talk, Benjie will introduce his vision for a new general-purpose GraphQL execution strategy whose holistic approach could lead to significant efficiency and scalability gains for all GraphQL APIs.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
WorkshopFree
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.
React Summit 2022React Summit 2022
147 min
Hands-on with AG Grid's React Data Grid
WorkshopFree
Get started with AG Grid React Data Grid with a hands-on tutorial from the core team that will take you through the steps of creating your first grid, including how to configure the grid with simple properties and custom components. AG Grid community edition is completely free to use in commercial applications, so you'll learn a powerful tool that you can immediately add to your projects. You'll also discover how to load data into the grid and different ways to add custom rendering to the grid. By the end of the workshop, you will have created an AG Grid React Data Grid and customized with functional React components.- Getting started and installing AG Grid- Configuring sorting, filtering, pagination- Loading data into the grid- The grid API- Using hooks and functional components with AG Grid- Capabilities of the free community edition of AG Grid- Customizing the grid with React Components
Node Congress 2022Node Congress 2022
98 min
Database Workflows & API Development with Prisma
WorkshopFree
Prisma is an open-source ORM for Node.js and TypeScript. In this workshop, you’ll learn the fundamental Prisma workflows to model data, perform database migrations and query the database to read and write data. You’ll also learn how Prisma fits into your application stack, building a REST API and a GraphQL API from scratch using SQLite as the database.
Table of contents:
- Setting up Prisma, data modeling & migrations- Exploring Prisma Client to query the database- Building REST API routes with Express- Building a GraphQL API with Apollo Server
React Advanced Conference 2022React Advanced Conference 2022
206 min
Best Practices and Patterns for Managing API Requests and States
Workshop
With the rise of frameworks, such as React, Vue or Angular, the way websites are built changed over the years. Modern applications can be very dynamic and perform multiple API requests to populate a website with fresh content or submit new data to a server. However, this paradigm shift introduced new problems developers need to deal with. When an API request is pending, succeeds, or fails, a user should be presented with meaningful feedback. Other problems can comprise API data caching or syncing the client state with the server. All of these problems require solutions that need to be coded, but these can quickly get out of hand and result in a codebase that is hard to extend and maintain. In this workshop, we will cover how to handle API requests, API states and request cancellation by implementing an API Layer and combining it with React-Query.
Prerequisites: To make the most out of this workshop, you should be familiar with React and Hooks, such as useState, useEffect, etc. If you would like to code along, make sure you have Git, a code editor, Node, and npm installed on your machine.