visit
I’m in the category ‘GraphQL’. And . Your support would be appreciated!
TL;DR: You can find the complete documentation on paginating GraphQL using StepZen .
Pros:
Cons:
Pros:
Cons:
Pros:
Cons:
The two essential parameters you need to specify for every type of pagination are type
and setters
. The type
parameters define the pagination style you want to implement. It has three possible values: PAGE_NUMBER
, OFFSET
, and NEXT_CURSOR
. Next comes the setters
parameters, which need to be pointed towards a field that indicates how many results or pages the response will output. You can find the list of all parameters with different pagination styles in the .
The below snippet illustrates how to implement GraphQL cursor-based pagination using StepZen for REST APIs supporting offset pagination. Note that the parameter first
is set to the number of required results. The second parameter, after
, is set to the starting point of the pagination.
customers(
first: Int! = 20
after: String! = ""
): CustomerConnection
@rest(
endpoint:"//api.example.com/customers?limit=$first&offset=$after"
pagination: {
type: OFFSET
setters: [{field:"total" path: "meta.total_count"}]
}
)
Since it's the first request, the after
parameter is equal to an empty string. The first
parameter is set to 20
, which means that the first 20 results will be returned. On the second request, you can change the value for after
to be equal to the value of first
from the previous request. Every new request will be a multiple of the first
parameter.
customers(
first: Int! = 20
after: String! = ""
): CustomerConnection
@rest(
endpoint:"//api.example.com/customers?page=$after&per_page=$first"
pagination: {
type: NEXT_CURSOR
setters: [{field:"nextCursor" path: "meta.next"}]
}
)
The above example illustrates some important aspects. The after
parameter is set to an empty string, which indicates that it is the first request. In contrast, the first parameter is set to 20
, meaning that 20 results will be returned per page. Remember, the value of the first parameter remains the same for subsequent requests as well. The after
parameter in the upcoming request will be according to the page number you want to be returned. For instance, it is 3
for the third and 4
for the fourth page.
Implementing cursor-based pagination is very similar to the other two pagination methods. The only difference is that you need to specify the type
parameter as NEXT_CURSOR
, and change the setters parameter to point towards the field that indicates the next cursor.
customers(
first: Int! = 20
after: String! = ""
): CustomerConnection
@rest(
endpoint:"//api.example.com/customers?first=$first&after=$after"
pagination: {
type: NEXT_CURSOR
setters: [{field:"nextCursor" path: "meta.next"}]
}
)
This, of course, only applies if your REST API already supports cursor-based pagination.
Let's look at the Connection
type that is used by cursor-based pagination:
type Customer {
activities: [Activity]
addresses: [Address]
contacts: Contacts
description: String
designation: String
}
type CustomerEdge {
node: Customer
cursor: String
}
type CustomerConnection {
pageInfo: PageInfo!
edges: [CustomerEdge]
}
The CustomerConnection
type is the one that is returned by the customers
query. It contains a pageInfo
field, which is of type PageInfo
. The PageInfo
type contains the following fields:
query MyQuery {
customers {
pageInfo {
endCursor
hasNextPage
hasPreviousPage
startCursor
}
}
}
These fields inform you about the current page, and whether there are more pages to be fetched. The endCursor
and startCursor
fields are the cursors that you need to use in the next request. The hasNextPage
and hasPreviousPage
fields indicate whether there are more pages to be fetched.
The edges
field contains a list of CustomerEdge
objects. The CustomerEdge
type contains a node
field of type Customer
. To get the information about the customer, you would need to use the node
field:
query MyQuery {
customers(first: 3, after: "eyJjIjoiTzpRdWVyeTpwYXJrcyIsIm8iOjl9") {
edges {
node {
id
description
}
}
}
}
The concept of "edges and nodes" is a bit confusing but very straightforward. It comes from the concept that everything in GraphQL is a graph. The edges
field contains a list of CustomerEdge
objects, information that is specific for this connection but not shared by all nodes. The CustomerEdge
type contains a node
field of type Customer
. This is the actual customer information.
For Relay, you can find more information on GraphQL connections in the .
The common and the most straightforward kinds of pagination are offset and page number. Although they are relatively simple to implement, they are more suitable for static data. In contrast, cursor-based pagination is complex but best for changing data as it prevents data inconsistencies. With StepZen, it's straightforward to implement cursor-based pagination for any API.
I’m in the category ‘GraphQL’. And . Your support would be appreciated!
Also Published