Paginacja dzieli duży zestaw wyników na odrębne strony, więc nie ładujesz tysięcy rekordów na raz. Jest to niezbędne dla wydajności i użyteczności. Django udostępnia klasę Paginator dla szablonów/widoków, a DRF oferuje wbudowaną paginację dla API.
# ❌ loading everything — slow, memory-heavy, bad UX with thousands of rows
articles = Article.objects.()
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})
<!-- in the template -->
{% for article in page_obj %}
<h2>{{ article.title }}</h2>
{% endfor %}
{% if page_obj.has_previous %}<a href="?page={{ page_obj.previous_page_number }}">Prev</a>{% endif %}
Page {{ page_obj.number }} of {{ page_obj.paginator.num_pages }}
{% if page_obj.has_next %}<a href="?page={{ page_obj.next_page_number }}">Next</a>{% endif %}
Paginator dzieli queryset na strony, a get_page() zwraca obiekt strony z pomocnikami nawigacji (has_next, next_page_number itp.) — zwróć uwagę, że dodaje LIMIT/OFFSET do zapytania, więc tylko jedna strona jest pobierana z bazy danych.
# 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 paginuje punkty końcowe listy automatycznie po skonfigurowaniu, zwracając metadane strony (liczbę, linki do następnej/poprzedniej) wraz z wynikami — klienci nawigują za pomocą podanych adresów URL.
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)
⚠️ 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.
Paginacja jest niezbędna do budowania wydajnych, użytecznych aplikacji obsługujących rzeczywiste wolumeny danych — bez niej punkty końcowe listowania i strony ładujące całe tabele (potencjalnie tysiące lub miliony wierszy) stają się wolne, pamięciochłonne i nieużyteczne, zarówno obciążając bazę danych, jak i przytłaczając użytkowników i klientów.
Zrozumienie paginacji to codzienna praktyczna wiedza: Paginator Django obsługuje tradycyjne widoki/szablony (dzielenie querysetów na strony z pomocnikami nawigacji, efektywne pobieranie tylko jednej strony via LIMIT/OFFSET), a wbudowana paginacja DRF obsługuje API (automatyczne paginowanie punktów końcowych listy z metadanymi i linkami nawigacyjnymi po skonfigurowaniu) — oba są potrzebne w zależności od tego, czy budujesz strony renderowane po stronie serwera czy API.
Umiejętność implementacji paginacji w obu kontekstach jest niezbędna dla prawie każdej funkcji wyświetlającej dane.
Niuans wydajności jest szczególnie wartościową wiedzą na poziomie senior: standardowa paginacja oparta na OFFSET pogarsza się na głębokich stronach bardzo dużych tabel (baza danych musi pominąć wszystkie poprzednie wiersze), więc paginacja oparta na kursorze (keyset) jest wydajnym wyborem dla ogromnych lub szybko zmieniających się zbiorów danych, a zawsze zamawianie po stabilnym polu jest niezbędne, aby uniknąć niespójnych lub zduplikowanych wyników między stronami.
Zrozumienie zarówno podstawowych mechanik (Paginator, klasy paginacji DRF), jak i tych rozważań wydajności (paginacja OFFSET vs kursor, spójna kolejność) jest ważne dla budowania aplikacji, które pozostają szybkie i poprawne w miarę wzrostu danych — paginacja jest wszechobecnym wymogiem, a robienie tego dobrze, szczególnie na dużą skalę, to praktyczna umiejętność, która bezpośrednio wpływa na wydajność aplikacji i doświadczenie użytkownika.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj