Pagination is crucial for managing large datasets efficiently, ensuring smooth navigation and data retrieval without overwhelming clients or servers.
Default Pagination
The IXO Blocksync GraphQL API uses a default pagination value of 10 items across all queries.
Pagination Parameters
first
Defines the number of records to return in each query.
query {
entities(first: 50) {
edges {
node {
id
name
}
}
}
}last
Defines the number of records to return, starting from the end of the dataset.
query {
entities(last: 10) {
edges {
node {
id
name
}
}
}
}after
Cursor to indicate the point in the dataset from which to continue fetching results.
query {
entities(first: 20, after: "YXJyYXljb25uZWN0aW9uOjEw") {
edges {
node {
id
name
}
}
}
}before
Cursor to navigate backward from a specific point in the dataset.
query {
entities(last: 10, before: "YXJyYXljb25uZWN0aW9uOjIw") {
edges {
node {
id
name
}
}
}
}Response Structure
A paginated response includes metadata for navigation:
{
"data": {
"entities": {
"edges": [
{
"node": {
"id": "did:ixo:entity:001",
"name": "Entity One"
}
}
],
"pageInfo": {
"endCursor": "YXJyYXljb25uZWN0aW9uOjIw",
"hasNextPage": true
}
}
}
}Response Fields
- edges: Array of results
- pageInfo.endCursor: Reference point for next results
- pageInfo.hasNextPage: Indicates more data availability
Best Practices
Use 20-100 items per query for optimal performance
Check hasNextPage to determine if more data is available
Use cursor values from responses, don't hardcode them
Implement rate limiting strategies to avoid 429 errors
Error Handling
400 Bad Request
Occurs with invalid cursor values. Always use cursors from previous responses.
429 Too Many Requests
Implement retry logic with exponential backoff when rate limits are reached.
For optimal performance, implement client-side caching of paginated results when appropriate.