Working with GraphQL

Create Magento App Create ScandiPWA App User Manual GitHub
Search…
ScandiPWA requests the data it needs from Magento via GraphQL. By default, Magento already defines a GraphQL schema and corresponding resolvers, enabling the frontend to request certain data via GraphQL. However, the API provided by Magento is not complete, so ScandiPWA has a set of custom modules that extend it to serve a broader range of data.
If you need develop custom backend functionality in your site, or if you want to adapt existing functionality to ScandiPWA, you will need to make sure it can be accessible via GraphQL.
Technically, you could fetch data using a REST API as well, but this has several disadvantages and is discouraged in favor of GraphQL. The ScandiPWA codebase entirely uses GraphQL.
Defining a Query
A GraphQL schema describes what types of data the GraphQL server deals with, what queries and mutations it provides, as well as the expected parameters and responses of those queries.
Queries and Mutations in GraphQL are like GET and POST request endpoints in REST – they implement one specific functionality of the API. A key difference is that all queries and mutations are done through one actual endpoint, managed by GraphQL. This allows for more flexibility. You can read an introduction to GraphQL if you are not familiar with it.
In Magento, you can extend the schema by creating a GraphQL schema file, at etc/schema.graphqls in your module. The schema files from all modules get merged together to producs the final schema, accessible to the frontend. This means that you can define new queries or types, as well as extend existing types.
Consider this example schema:
scandipwa/catalog-graphql/src/etc/schema.graphqls (annotated excerpt)
1
# this block contains the queries we define in this schema file
2
type Query {
3
    category (
4
        id: Int @doc(description: "Ids of the category")
5
        url_path: String @doc(description: "Url path of the category")
6
    ): CategoryTree
7
    @resolver(class: "ScandiPWA\\CatalogGraphQl\\Model\\Resolver\\CategoryTree")
8
}
9
​
10
# this type is already defined elsewhere; we merely want to add
11
# another field to it
12
type CategoryTree {
13
    is_active: Boolean @doc(description: "Category is enabled")
14
}
15
​
Copied!
In GraphQL, types followed by an exclamation mark ! are required. Since we have specified id: Int and not id: Int!, neither of the parameters are required.
This schema defines a new GraphQL query that accepts either an id or url_path and returns a category. The CategoryTree type is already defined elsewhere fields representing a category, so we don't need to re-define that. We do, however, want to add a new field to specify if the category is enabled.
Implementing a Resolver
A GraphQL resolver is a piece of PHP code that actually implements the queries defined in the Schema. It takes the query parameters as function arguments, and must return a PHP array or associative array of the shape specified in the schema.
The query defined in the schema above specifies a resolver class using the @resolver annotation. The Magento GraphQL mechanism will use this class whenever a cmsPage query is made.
By convention, resolvers are located in the Model/Resolver directory of the module. All resolvers must implement the Magento\Framework\GraphQl\Query\ResolverInterface to ensure they are able to work with the GraphQL system.
Here is the resolver used by the category query:
scandipwa/catalog-graphql/src/Model/Resolver/CategoryTree.php (simplified)
1
class CategoryTree implements ResolverInterface
2
{
3
    // [...] field declarations, constructor using dependency injection
4
​
5
    /**
6
     * @inheritdoc
7
     */
8
    public function resolve(
9
        Field $field,
10
        $context, // some context info (e.g. the user ID if any)
11
        ResolveInfo $info,
12
        array $value = null,
13
        array $args = null // an associative array of the parameters passed
14
    ) {
15
        $rootCategoryId = $this->getCategoryId($args);
16
​
17
        // a bunch of helper functions.
18
        // $category ends up being an array-like value with the data we want
19
        $categoriesTree = $this->categoryTree->getTree($info, $rootCategoryId);
20
        $result = $this->extractDataFromCategoryTree->execute($categoriesTree);
21
        $category = current($result);
22
​
23
        return $category;
24
    }
25
}
26
​
Copied!
When writing most simple resolvers, you will need to know:
$context contains some information about the user's session
$args contain the arguments passed to the query/mutation
The function must return an array containing the data you want the query to return
Testing the Query
You can use a tool such as Altair GraphQL or another GraphQL client to check that your query is working properly. The GraphQL endpoint, by default, is <your-server>/graphql.
If your query works as expected, you can now use it on the frontend!
Extending Existing Resolvers
Resolvers, like any other Magento class, can be extended using Magento Plugins (interceptors), or the DI preference mechanism. You can also extend the GraphQL types of their responses to specify that they now return some new field as well.
Working with Magento modules
GraphQL Security
Last modified 1yr ago
Copy link
Contents
Defining a Query
Implementing a Resolver
Testing the Query
Extending Existing Resolvers