Migrating to GraphqL from REST
Translating from REST IDs to GraphQL IDs
To help with migrating from our REST to the GraphQL, REST responses now include the GraphQL Admin API ID field,
You can use the ID in this field to query the object directly using the GraphQL Admin API.
The following example retrieves a product variant in REST, and then uses the
admin_graphql_api_id property to query it in GraphQL.
GraphQL IDs are opaque
GraphQL ID generation is implementation dependent, and as such does not follow any convention other than being a URI. There is no guarantee that GraphQL IDs will follow a similar "structure" (gid -> shopify -> resource -> rest_id) to the previous example, and so you shouldn't IDs programatically.
The following example shows how the
admin_graphql_api_id property doesn't always follow an expected structure:
Always treat the
admin_graphql_api_id string as an opaque ID.
Storefront API IDs
The Storefront API is also queried using GraphQL, and it uses its own separate IDs.
The GraphQL Admin API provides the
storefrontId field, which you can use to get that object's Storefront API ID.
The following example shows how to request the
storefrontId field on a product.
Using connections, you can get information from related objects with a single request. For example, in the case of an order, you might want to know the total price, the customer's name, metafields, as well as the title of other variants belonging to the product in the order.
Using REST, we'd query the following endpoints and filter excess information.
Using GraphQL, you can make a single request using connections to get the desired data.
In REST, you paginate via the query parameters. Using
limit, you can split the total entries into manageable groups and paginate through them with
In GraphQL, you can apply similar concepts with cursor based pagination.
When using connections, you'll want to provide the
last argument, which specifies the number of items you want returned. This is equivalent to
Requesting the cursor field lets you get a reference to the position of a node within the connections. You can use that reference to obtain the next set of items. This is equivalent to
page, but with more precision, robustness, and flexibility.
Finally, request the pagInfo field to determine if there are any more pages to request. The nested fields “hasNextPage” and “hasPreviousPage” are boolean fields which let us know if we'll be able to paginate forwards or backwards. If both are
false, there are no more results or pages.
Tying it all together
This example query explores the connection between shops and orders. In our request, we’ll explore the connection between shops and orders, and how we can get only the fields we’re interested in.
This query asks for the first three elements on the orders connection. On each of these orders, the
pageInfo fields to handle pagination.
The query returns the data for the first three orders. In order to get the next 3 orders, we’ll have to add the cursor value to our connection arguments.
The data returned indicates that each node has a cursor. Using the last cursor that was returned allows you to continue from that point.
Continue paginating using the same method until