Comment paginez-vous les résultats dans Django et DRF ?

Question

Accepted Answer

**La pagination** divise un grand ensemble de résultats en pages discrètes, afin de ne pas charger des milliers d'enregistrements à la fois. Elle est essentielle pour les performances et l'utilisabilité. Django fournit une classe `Paginator` pour les templates/vues, et DRF offre une pagination intégrée pour les APIs. ## Le problème que la pagination résout ```python # ❌ loading everything — slow, memory-heavy, bad UX with thousands of rows articles = Article.objects.all() # could be 100,000 records ``` ## Paginator de Django (pour les vues/templates traditionnels) ```python from django.core.paginator import Paginator def article_list(request): articles = Article.objects.all().order_by("-created_at") # ORDER matters for consistent pages paginator = Paginator(articles, 20) # 20 items per page page_number = request.GET.get("page") # ?page=2 page_obj = paginator.get_page(page_number) # the requested page return render(request, "list.html", {"page_obj": page_obj}) ``` ```html {% for article in page_obj %}

{% endfor %} {% if page_obj.has_previous %}Prev{% endif %} Page {{ page_obj.number }} of {{ page_obj.paginator.num_pages }} {% if page_obj.has_next %}Next{% endif %} ``` Le `Paginator` divise un queryset en pages et `get_page()` retourne un objet page avec des helpers de navigation (`has_next`, `next_page_number`, etc.) — notez qu'il ajoute `LIMIT`/`OFFSET` à la requête, donc seule une page est récupérée depuis la base de données. ## Pagination DRF (pour les APIs) ```python # global default in settings.py REST_FRAMEWORK = { "DEFAULT_PAGINATION_CLASS": "rest_framework.pagination.PageNumberPagination", "PAGE_SIZE": 20, } # now list endpoints are automatically paginated, returning: # { "count": 1000, "next": "...?page=3", "previous": "...?page=1", "results": [...] } ``` DRF pagine automatiquement les endpoints de liste une fois configuré, retournant des métadonnées de page (count, liens next/previous) aux côtés des résultats — les clients naviguent via les URL fournies. ## Styles de pagination DRF ```text PageNumberPagination → ?page=2 (simple page numbers) LimitOffsetPagination → ?limit=20&offset=40 (flexible offsets) CursorPagination → opaque cursor; consistent & performant for large/changing data (avoids OFFSET performance issues on huge datasets) ``` ## La nuance de performance ```text ⚠️ OFFSET-based pagination (page/offset) gets SLOWER on deep pages of huge tables (the DB must skip OFFSET rows). For very large datasets, CURSOR pagination (keyset, using a WHERE on an indexed column) is far more efficient. ⚠️ Always ORDER BY a stable field, or pages can be inconsistent/repeat items. ``` ## Pourquoi c'est important La pagination est essentielle pour construire des applications performantes et utilisables qui traitent des volumes de données réels — sans elle, les endpoints de listing et les pages qui chargent des tables entières (potentiellement des milliers ou millions de lignes) deviennent lents, consommateurs de mémoire et inutilisables, surchargeant à la fois la base de données et écrasant les utilisateurs et les clients. Comprendre la pagination est une connaissance pratique quotidienne : le **Paginator** de Django gère les vues/templates traditionnels (divisant les querysets en pages avec des helpers de navigation, récupérant efficacement une seule page via LIMIT/OFFSET), et la **pagination intégrée** de DRF gère les APIs (paginant automatiquement les endpoints de liste avec métadonnées et liens de navigation une fois configurée) — tous deux sont nécessaires selon que vous construisiez des pages serveur-rendu ou des APIs. Savoir comment implémenter la pagination dans les deux contextes est nécessaire pour pratiquement n'importe quelle fonctionnalité de listing de données. La **nuance de performance** est particulièrement une connaissance précieuse au niveau sénior : la pagination standard basée sur OFFSET se dégrade sur les pages profondes de très grandes tables (la base de données doit ignorer toutes les lignes précédentes), donc la **pagination par curseur (keyset)** est le choix efficace pour les ensembles de données énormes ou en rapide évolution, et **toujours trier par un champ stable** est nécessaire pour éviter des résultats incohérents ou dupliqués entre les pages. Comprendre à la fois la mécanique de base (Paginator, classes de pagination DRF) et ces considérations de performance (OFFSET vs pagination par curseur, tri cohérent) est important pour construire des applications qui restent rapides et correctes à mesure que les données augmentent — la pagination est une exigence omniprésente, et bien la faire, surtout à grande échelle, est une compétence pratique qui affecte directement les performances de l'application et l'expérience utilisateur.