ਦੋ ਰਣਨੀਤੀਆਂ: 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 shift ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ duplicates ਜਾਂ gaps ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਇਹ deep offsets 'ਤੇ ਹੌਲੀ ਵੀ ਹੋ ਜਾਂਦਾ ਹੈ (DB ਫਿਰ ਵੀ skip ਕੀਤੀਆਂ rows scan ਕਰਦਾ ਹੈ)।ਇੱਕ connection list ਨੂੰ edges (ਹਰ ਇੱਕ ਵਿੱਚ ਇੱਕ cursor ਅਤੇ node) ਨਾਲ ਅਤੇ pageInfo ਵਿੱਚ wrap ਕਰਦਾ ਹੈ:
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 ਹੇਠ consistency ਅਤੇ deep-page performance ਸਮਝਦੇ ਹੋ। Relay connection shape ਨੂੰ ਜਾਣਨਾ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਕਿਉਂਕਿ Apollo/Relay clients ਵਿੱਚ ਇਸ ਲਈ built-in cache handling ਹੁੰਦੀ ਹੈ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ