İki strateji vardır: offset tabanlı (limit/offset) ve cursor tabanlı. GraphQL'in yerleşik bir sayfalaması yoktur, ancak topluluk standardı, cursor sayfalamasını resmileştiren Relay Connection spesifikasyonudur.
İki strateji vardır: offset tabanlı (limit/offset) ve cursor tabanlı. GraphQL'in yerleşik bir sayfalaması yoktur, ancak topluluk standardı, cursor sayfalamasını resmileştiren Relay Connection spesifikasyonudur.
items(limit: 10, offset: 20)) basittir ama canlı veride bozulur: kullanıcı sayfalar arasında gezerken bir satır eklenirse, öğeler kayar ve yinelenenler veya boşluklar görürsünüz. Ayrıca derin offset'lerde yavaşlar (DB yine de atlanan satırları tarar).Bir connection, listeyi edges (her biri bir cursor ve node ile) artı pageInfo içine sarar:
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'tir — genellikle sıralama anahtarının base64'ü — bu yüzden istemciler onu bir sayı değil, bir token olarak ele alır.
Offset ile cursor arasında seçim yapmak, eşzamanlı yazmalar altında tutarlılığı ve derin sayfa performansını anladığınızı gösterir. Relay connection şeklini bilmek önemlidir, çünkü Apollo/Relay istemcileri bunun için yerleşik cache işlemesine sahiptir.
Junior'dan Senior'a detaylı cevaplarla bir BT mülakat soruları kütüphanesi.
Bağış Yap