બે વ્યૂહરચનાઓ: offset-based (limit/offset) અને cursor-based. GraphQL માં built-in pagination નથી, પરંતુ community standard એ Relay Connection spec છે, જે cursor pagination ને formalize કરે છે.
બે વ્યૂહરચનાઓ: offset-based (limit/offset) અને cursor-based. GraphQL માં built-in pagination નથી, પરંતુ community standard એ Relay Connection spec છે, જે cursor pagination ને formalize કરે છે.
items(limit: 10, offset: 20)) સરળ છે પણ live data પર તૂટે છે: જો user paging કરી રહ્યો હોય ત્યારે કોઈ row insert થાય, તો items ખસી જાય છે અને તમને duplicates અથવા gaps દેખાય છે. તે deep 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 તેને number તરીકે નહીં પણ token તરીકે ગણે છે.
Offset vs cursor પસંદ કરવું બતાવે છે કે તમે concurrent writes હેઠળ consistency અને deep-page performance સમજો છો. Relay connection નો આકાર જાણવો મહત્વનો છે કારણ કે Apollo/Relay clients પાસે તેના માટે built-in cache handling છે.
વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો