Paginasi SvelteKit yang buruk bisa memperparah query lambat di Postgres. Artikel ini langsung menunjukkan cara menghubungkan load function atau endpoint SvelteKit dengan Postgres tanpa mendorong database lewat offset besar: gunakan parameter pagination yang tervalidasi, batasi jumlah data per halaman, dan pilih strategi pagination yang sesuai pertumbuhan data.

Penjelasan berikut mencakup bagaimana load function menyiapkan parameter paging, bagaimana indexing membantu filter dan sorting yang umum, perbandingan offset vs cursor untuk volume data menanjak, hingga teknik monitoring query lambat dan caching ringan demi respons yang stabil.

Mekanisme load function SvelteKit dengan database Postgres

Load function di SvelteKit berfungsi mempersiapkan data sebelum komponen dirender. Saat berinteraksi dengan Postgres, pastikan:

  • Parameter pagination (misalnya cursor atau page) divalidasi dan dibatasi untuk mencegah permintaan tak terkendali.
  • Koneksi ke Postgres dikelola melalui pool agar tidak menghabiskan resource.
  • Query memanfaatkan filter dan sort yang sudah di-index untuk respons cepat.

Contoh load function yang membaca parameter cursor dan limit dari query string:

export const load = async ({ url, fetch }) => {
  const cursor = url.searchParams.get('cursor') ?? null;
  const limit = Math.min(Number(url.searchParams.get('limit') ?? 20), 50);

  const params = new URLSearchParams({
    limit: String(limit),
    cursor: cursor ?? ''
  });

  const response = await fetch(`/api/posts?${params}`);
  if (!response.ok) {
    throw new Error('Gagal mengambil data');
  }

  return await response.json();
};

Load function di atas memungkinkan endpoint API internal menangani logika SQL. Batasi limit agar Postgres tidak memproses lebih dari yang diperkirakan.

Identifikasi bottleneck SQL dan strategi indexing

Query lambat biasanya karena full table scan, join tanpa indeks, atau sorting tanpa indeks. Untuk pagination, biasanya filter dan sort terjadi pada kolom timestamp atau ID. Terapkan indeks gabungan pada kombinasi kolom yang sering muncul di klausa WHERE dan ORDER BY.

Contoh strategi indexing praktis:

  • Indeks pada kolom yang digunakan filter utama, misalnya CREATE INDEX ON posts (status) jika filter berdasarkan status post.
  • Indeks gabungan untuk sorting: CREATE INDEX ON posts (status, created_at DESC) membantu query seperti WHERE status = 'published' ORDER BY created_at DESC.
  • Indeks unik pada kolom cursor: Saat menggunakan cursor pagination (misalnya id atau created_at), indeks mempercepat pencarian baris setelah cursor terakhir.

Selalu gunakan EXPLAIN ANALYZE pada query produksi untuk memastikan Postgres menggunakan indeks tersebut dan hindari serial scans.

Offset vs cursor pagination dalam pertumbuhan data

Offset pagination sederhana tapi tidak skalabel. Saat data tumbuh, Postgres tetap membaca OFFSET baris awal meski tidak ditampilkan, menyebabkan latency naik tajam. Cursor pagination menghindari ini dengan menggunakan nilai terurut sebagai referensi posisi terakhir.

Perbandingan:

  • Offset: Mudah implementasi, cocok untuk dataset kecil dan saat pengguna perlu melompat langsung ke halaman tertentu. Tapi tambah waktu baca database seiring OFFSET naik.
  • Cursor: Lebih kompleks karena harus menyimpan nilai cursor terakhir (misal timestamp atau ID), namun query tetap cepat karena memanfaatkan indeks. Tidak memungkinkan melompat ke halaman tengah secara langsung.

Pilih cursor untuk feed yang terus bertambah dan offset hanya bila pengguna harus lompat bebas antar halaman.

Monitoring query lambat dan caching sederhana

Gunakan fitur Postgres seperti pg_stat_statements untuk memantau query paling berat. Cek kolom total_time dan calls; kombinasi tinggi menandakan query yang harus dioptimasi atau dibatasi. Kombinasikan dengan tools observability (contoh: Grafana + Prometheus) agar bisa memantau latency endpoint pada level aplikasi.

Caching sederhana bisa membantu mengurangi beban. Contoh pendekatan:

  • Simpan hasil query halaman pertama di in-memory cache (misal Redis) dengan TTL pendek.
  • Di endpoint SvelteKit, cek cache sebelum menjalankan query Postgres.
  • Beri invalidasi saat data berubah agar tidak menyajikan stale data lama.

Cache sangat efektif untuk halaman yang sering dibuka namun jarang berubah.

Ringkasan dampak indexing dan pagination terhadap latency skala data

Indexing yang tepat memungkinkan filter dan sort berjalan langsung di indeks tanpa membaca seluruh tabel, sementara pagination yang tepat (cursor saat volume besar) memastikan Postgres hanya mengambil baris yang ditampilkan. Gabungkan keduanya dengan parameter load function yang aman, monitoring query lambat, dan cache sederhana agar latency tetap rendah meski data berkembang.

Dengan pendekatan ini, SvelteKit mampu menyajikan halaman cepat, Postgres bekerja lebih hemat sumber daya, dan Anda siap menghadapi pertumbuhan data selanjutnya.