GraphQL is a query language for APIs. Using such queries has a lot of advantages. Take a look below at the two most important:
When you send a query, you describe what you want, and in response, you get precisely what you wanted.
You can get all the data you need in one query. Thanks to this, it is not necessary to send queries to different URLs to collect all the necessary data.
GraphQL is becoming more and more popular, and there is a trend to replace REST APIs with an API built to use GraphQL. Such a change is taking place in Magento, and PWA Studio is an excellent example of using a GraphQL API.
In one of my recent articles, I wrote about another GraphQL advantage, one which is significant from the Development Team’s perspective:
Suppose some functionality needs data from the backend or somehow needs to communicate with the API, and this data is not available, or the API hasn’t been done yet. In that case, the Frontend developer needs to mock up some sample data. Take a look at the examples below:
A development team is working on displaying additional information about a product on a product page. The data are called “Key features” and consist of an image, a name, and a description. This data will come from the backend. The backend team hasn’t started working on this functionality yet, so the Frontend developer decides to mock up this data and display this mockup on the frontend. When the backend is done, the mockup data will be replaced with real data.
This functionality lets customers send a message to a seller. A customer fills out the form. He enters his name, surname, e-mail address, and message. Additionally, they must accept consent to the processing of personal data. The frontend developer has already built the form, validation, and is at the stage of sending the form to the backend. The backend must pick up the form and return a success or error message, and this message will be displayed to the user. The backend part is not ready yet, so the Frontend developer needs to mock this interaction with the backend.
A frontend developer is also a programmer, right? Exactly, and programmers sometimes have problems, especially issues with code, and the most serious, most common difficulty is:
In this case, it’s good to talk to another developer about the problem and find a solution together. Unfortunately, sometimes there is no other programmer nearby because, for example, you work in a different time zone, or you do not let anyone into your garage where you are writing a new web application for the government. In this case, you need a programmer mockup, that is:
Oh yes, the rubber duck can help too, and let those who have never used its help throw the first stone! ;-)
Today, I will show you how to mock up data and interactions with a GraphQL API on a simple module for PWA Studio. Our module will display the mocked data on the storefront. It will also be possible to send a form. I will show you how to easily mock up:
With this knowledge, you will be able to work on your frontend more efficiently, even when the backend is lagging far behind.
First, we will create a skeleton of our module. I will not elaborate on this topic because I have already done it here. If you are not familiar with the PWA Studio Extensibility Framework, be sure to read this article first.
We will start with the most important file for this article’s topic, i.e., mocking GraphQL data.
Now open this file in your editor. We will successively add new elements to it.
graphql-tag is a library that parses GraphQL queries and allows you to use them in JS.
Faker.js is a library that will help mock data.
We just made our first query that will get fake data. The key here is line 3. On this line, we point to the name mocked_data, which we will refer to later on. Adding the @client flag here is necessary for the API to know that it shouldn’t send this query to the backend, but look for a mockup on the client-side (frontend). In the fourth to the sixth lines, we define what data our query is to return. In this case, it’s ID, name, and description.
Now we will add a mutation called addMockedItem
The mutation takes two parameters: name and description. This data will come from the form that the user completes. As you can see on line 9, we added the @client flag, which means that this mutation will only be processed on the client-side.
Now we will export our query and mutation as an object to use them later in the app.
Time to define the resolver. This is the object where we define our mocked queries and the GraphQL mutations.
We will add to our query, which we defined in the previous steps as mocked_data, to the resolver.
We made a function that returns mocked data. We created data using the Faker.js library. We return arrays with objects that have three fields: ID, name, description. As you can see, these are exactly the same fields we declared earlier in the GraphQL query.
Above, we have declared the addMockedItem mutation, and here is its implementation. The mutation takes two parameters (name and description) and returns them here for the test. Additionally, we return the ID, which is a random number.
Our file is completed, and here is the final version:
For our resolver to work, we need to add it to the PWA Studio resolvers configuration. This is found in the file:
I recommend that you overwrite this file in a separate module using the Extensibility Framework.
On line 3, you can see that we import our resolver, and on line 31, we export it along with the others.
Time to see our fake friends in action. We will make three components:
Create the lib/components/MockedComponent directory.
The most important lines here are lines 11 through 15, where the getMockedData query is
Create the lib/components/MockedItem directory.
Time for a component that will use our mocked mutation. We create the lib / components / AddMock directory.
See line 17. There we use the useMutation hook, which takes our mocked mutation as a parameter. This hook returns two things to us:
Note that the useMutation hook does not execute mutations. We do it later, and the data in the data object will be available only after the mutation is performed. We display this data, and the code on lines 52 to 59 is responsible for it.
The last thing we need to do to make our components visible on the frontend is to inject the MockComponent component into PWA Studio. For testing, I injected it into the Main component. Below is the result of our work:
If you would like to see how it works, you can use ready-made modules that I have prepared.
In this article, I showed you how you can mock GraphQL queries and mutations. Compared to a REST API, mocking GraphQL queries is much easier. The subsequent transition to real data only really involves a change in GraphQL queries and resolvers’ removal. In my opinion, mocking data in GraphQL is much easier than in REST, which is unquestionably beneficial for everyone.
Each share supports and motivates me to create new content. Thank you!
Certified Magento Full Stack Developer, based in Poland. He has 7 years of professional Software engineering experience. Privately, husband, father, and DIY enthusiast.Read more