Két stratégia: offset-alapú (limit/offset) és cursor-alapú. A GraphQL-nek nincs beépített lapozása, de a közösségi szabvány a Relay Connection spec, amely formalizálja a cursor-alapú lapozást.
Két stratégia: offset-alapú (limit/offset) és cursor-alapú. A GraphQL-nek nincs beépített lapozása, de a közösségi szabvány a Relay Connection spec, amely formalizálja a cursor-alapú lapozást.
items(limit: 10, offset: 20)) egyszerű, de élő adaton elromlik: ha egy sor beszúródik, miközben a felhasználó lapoz, az elemek eltolódnak, és duplikátumokat vagy hézagokat látsz. Mély offseteknél is lassú (a DB továbbra is végigolvassa az átugrott sorokat).Egy connection az edges (mindegyikben egy cursor és egy node) plusz a pageInfo köré csomagolja a listát:
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 },
};
A cursor opaque — általában a rendezési kulcs base64-változata —, így a kliensek tokenként kezelik, nem számként.
Az offset vs cursor választás megmutatja, hogy érted a konzisztenciát egyidejű írások mellett és a mély oldalak teljesítményét. A Relay connection struktúra ismerete azért számít, mert az Apollo/Relay klienseknek beépített cache-kezelésük van rá.
IT interjúkérdések gyűjteménye részletes válaszokkal — Juniortól Seniorig.
Adományozás