دو حکمت عملیاں: offset-based (limit/offset) اور cursor-based۔ GraphQL میں کوئی built-in pagination نہیں، مگر community کا معیار Relay Connection spec ہے، جو cursor pagination کو باضابطہ بناتا ہے۔
دو حکمت عملیاں: offset-based (limit/offset) اور cursor-based۔ GraphQL میں کوئی built-in pagination نہیں، مگر community کا معیار Relay Connection spec ہے، جو cursor pagination کو باضابطہ بناتا ہے۔
items(limit: 10, offset: 20)) سادہ ہے مگر لائیو data پر ٹوٹ جاتا ہے: اگر user کے pages بدلتے وقت کوئی row داخل ہو جائے، تو items کھسک جاتے ہیں اور آپ کو duplicates یا خلا نظر آتے ہیں۔ گہرے offsets پر یہ سست بھی ہو جاتا ہے (DB پھر بھی چھوڑی گئی rows کو scan کرتا ہے)۔ایک connection list کو edges (ہر ایک میں cursor اور node) اور pageInfo میں لپیٹتا ہے:
type Query {
posts(first: Int!, after: String): PostConnection! # first = page size, after = cursor
}
type PostConnection {
edges: [PostEdge!]!
pageInfo: PageInfo!
}
type PostEdge {
cursor: String! # opaque token for THIS node's position
node: Post! # the actual item
}
type PageInfo {
endCursor: String # feed this back as 'after' for the next page
hasNextPage: Boolean! # so the client knows when to stop
}
// resolver: fetch ONE extra row to compute hasNextPage cheaply
const rows = await db.posts.find({ after: args.after, limit: args.first + 1 });
const hasNextPage = rows.length > args.first;
const page = rows.slice(0, args.first);
return {
edges: page.map((p) => ({ node: p, cursor: encodeCursor(p.id) })),
pageInfo: { endCursor: page.at(-1) && encodeCursor(page.at(-1).id), hasNextPage },
};
Cursor opaque ہوتا ہے — عموماً sort key کی base64 — تاکہ clients اسے ایک token سمجھیں، نہ کہ کوئی عدد۔
Offset بمقابلہ cursor کا انتخاب دکھاتا ہے کہ آپ بیک وقت لکھنے کے دوران consistency اور گہرے page کی performance کو سمجھتے ہیں۔ Relay connection کی shape جاننا اہم ہے کیونکہ Apollo/Relay clients میں اس کے لیے built-in cache handling موجود ہے۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں