Comment pagineriez-vous un endpoint de collection volumineuse, et pourquoi ne pas simplement utiliser limit et offset ?

Préférez la pagination par clé, aussi appelée pagination par curseur : triez sur une clé unique et stable, renvoyez un curseur opaque pour la dernière ligne et demandez les lignes situées après. La pagination par offset oblige la base à lire puis jeter chaque ligne sautée, donc la page cinq mille est lente, et les lignes insérées ou supprimées pendant le défilement provoquent des doublons et des trous. La pagination par clé reste à coût constant par page et reste stable sous les écritures.

Je pars par défaut sur la pagination par clé. Le client demande une page, reçoit des éléments plus un curseur opaque, et la requête suivante dit donnez-moi les lignes après ce curseur. Sous le capot c'est une clause where sur la clé de tri, donc avec le bon index c'est une recherche d'index et le coût est le même à la page un et à la page mille. L'offset ne peut pas faire ça, parce que la base parcourt et jette quand même tout ce qui précède, et pire, si une ligne est insérée pendant que quelqu'un défile, toutes les pages suivantes se décalent et il voit un doublon ou rate complètement un élément. Le détail qui piège, c'est le départage : si je trie par created at et que deux lignes partagent l'horodatage, l'ordre n'est pas déterministe, donc le curseur encode created at plus l'id et la comparaison porte sur la paire. Ce que j'abandonne, ce sont les sauts de page arbitraires et les comptages totaux peu coûteux. Sur un flux à défilement infini, personne ne les regrette ; pour une table d'administration qui a besoin de numéros de page, j'utiliserai un offset avec un maximum borné.