दोन धोरणे: offset-based (limit/offset) आणि cursor-based. GraphQL मध्ये built-in pagination नाही, पण community चा standard म्हणजे Relay Connection spec, जो cursor pagination औपचारिक करतो.
दोन धोरणे: offset-based (limit/offset) आणि cursor-based. GraphQL मध्ये built-in pagination नाही, पण community चा standard म्हणजे Relay Connection spec, जो cursor pagination औपचारिक करतो.
items(limit: 10, offset: 20)) सोपे आहे पण live data वर तुटते: user page करत असताना एखादी row insert झाली, तर items सरकतात आणि तुम्हाला duplicates किंवा gaps दिसतात. खोल offsets वर ते slow सुद्धा होते (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 निवडणे दर्शवते की तुम्हाला concurrent writes खाली सुसंगतता आणि deep-page performance समजते. Relay connection चा आकार जाणणे महत्त्वाचे आहे कारण Apollo/Relay clients मध्ये त्यासाठी built-in cache handling असते.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या