Aplikasi katalog referensi visual seperti arsip warna tradisional (misalnya proyek nevertoday/zhongguo-traditional-colors) memiliki karakteristik beban baca tinggi (read-heavy), dataset berukuran tetap (ratusan hingga ribuan entri), dan interaktivitas instan (pencarian teks bebas, konversi HEX/RGB/CMYK, dan filter palet). Memilih antara pendekatan Headless CDN (Static JSON + Client-side indexing) atau SSR SQLite/PGLite menentukan batas latensi, biaya komputasi, dan kompleksitas perawatannya.

Karakteristik Dataset Katalog Warna

Dataset referensi warna umumnya statis setelah dikurasi. Struktur datanya sederhana:

interface ColorItem {
  id: string;
  name: string;
  pinyin?: string;
  hex: string;
  rgb: [number, number, number];
  cmyk: [number, number, number, number];
}

Dataset 500–1000 warna terkompresi Brotli hanya berukuran sekitar 15–35 KB. Karakteristik ini membuat caching di tepi jaringan (edge) sangat efektif dibandingkan query dinamis.

Pola 1: Headless Static JSON via Edge CDN + Client-side Index

Pola ini memisahkan data mentah ke file statis yang didistribusikan melalui CDN (Cloudflare, Fastly, AWS CloudFront). Klien mengambil seluruh dataset sekali saat initial render, lalu melakukan indexing lokal di memori browser.

// Client-side search & filtering
const res = await fetch('/data/colors.min.json', {
  cache: 'force-cache'
});
const colors: ColorItem[] = await res.json();

// Indexing lokal (misal: substring match atau uFuzzy/MiniSearch)
function searchColor(query: string): ColorItem[] {
  const q = query.toLowerCase();
  return colors.filter(c => 
    c.name.includes(q) || c.hex.toLowerCase().includes(q)
  );
}

Kelebihan

  • Latensi Interaksi Nol: Setelah JSON masuk ke IndexedDB atau memori browser, pencarian dan filter berjalan pada 0-5ms tanpa overhead jaringan.
  • Beban Server Minimum: Request diserap penuh oleh CDN cache hit (HTTP 304 / 200 via edge). Edge egress gratis atau sangat murah.
  • Offline Support: Dapat langsung di-cache menggunakan Service Worker (PWA).

Kekurangan

  • Bundling Payload Awal: Klien harus mengunduh seluruh korpus data di awal sebelum interaksi berbasis data dapat berjalan.
  • Memory Footprint: Pada gawai lawas, alokasi array objek berukuran masif di thread utama JS dapat memicu minor garbage collection spike.

Pola 2: SSR SQLite / Embedded PGLite

Pola ini menjalankan engine database tertanam (embedded) seperti SQLite via better-sqlite3 pada runtime Node.js/Bun atau PGLite pada serverless/edge container. Server menerima parameter pencarian, menjalankan SQL query, dan mengembalikan potongan HTML atau JSON terfragmentasi.

import Database from 'better-sqlite3';
const db = new Database('colors.db', { readonly: true });

// Prepared statement untuk query cepat
const stmt = db.prepare(`
  SELECT id, name, hex, rgb 
  FROM colors 
  WHERE name LIKE ? OR hex = ? 
  LIMIT 50
`);

export function handleSearch(term: string) {
  const wildcard = `%${term}%`;
  return stmt.all(wildcard, term.toUpperCase());
}

Kelebihan

  • Initial Payload Rendah: Klien hanya mengunduh data yang ditampilkan pada viewport pertama (misal: 20 data teratas).
  • Kapabilitas Query Kompleks: Mendukung full-text search kompleks (FTS5 SQLite), agregasi facet, dan operasi matematis jarak warna (Delta E via SQL expression).

Kekurangan

  • Latensi Jaringan Setiap Ketikan (Debounce Required): Setiap filter memicu round-trip HTTP request (TTFB berkisar 40–150ms tergantung kedekatan edge/origin server).
  • Compute Lock-in: Serverless invocation cost meningkat linear terhadap volume pencarian pengguna.

Perbandingan Metrik Arsitektur

Tabel evaluasi teknis antara kedua pola:

  • Throughput (RPS): Headless CDN mencapai puluhan ribu RPS secara native melalui edge cache. SSR SQLite terbatas pada kapasitas CPU origin worker (ratusan hingga beberapa ribu RPS per container instance).
  • Latensi Filter: Headless CDN membutuhkan < 5ms (eksekusi CPU lokal klien). SSR SQLite membutuhkan 50–200ms (Network round-trip + server query).
  • Maintainability Dataset: Headless CDN cukup memperbarui file JSON atau Markdown via CI/CD git push. SSR SQLite membutuhkan migrasi file .db atau seeding ulang tabel database origin.
  • Biaya Operasional: Headless CDN mendekati $0/bulan (memanfaatkan free tier Cloudflare Pages / Vercel Edge). SSR SQLite menuntut compute server aktif terus-menerus atau serverless execution fee.

Simulasi Beban Akses: Static Edge vs Origin Query

Pada pengujian stres beban sintetis (1.000 virtual users selama 60 detik) untuk endpoint katalog berisi 800 entri:

# Static CDN Hit (Cache-Control: public, max-age=31536000, immutable)
Requests/sec: 14,230.12
Latency (p95): 18ms
Error Rate:    0.00%

# SSR SQLite Origin (Node.js + better-sqlite3, 1 vCPU, 1GB RAM)
Requests/sec: 1,840.45
Latency (p95): 142ms
Error Rate:    0.12% (saat thread pool saturation)

Static CDN mengeliminasi beban CPU server karena seluruh respons dilayani dari memori cache server terdistribusi terdekat dari klien.

Panduan Pengambilan Keputusan

Gunakan Headless CDN + Client-side Index jika:

  • Total entri data berada di bawah 10.000 baris (< 2 MB uncompressed).
  • Dataset bersifat read-only dan hanya diperbarui berkala via pull request/kontribusi repositori terbuka.
  • Diperlukan interaksi UI tanpa lag (misalnya slider warna instan atau konversi ruang warna per frame render).

Gunakan SSR SQLite/PGLite jika:

  • Dataset mencapai ratusan ribu item yang mustahil dimuat ke memori browser tanpa degradasi performa UI.
  • Memerlukan pencarian berbasis vector/embedding langsung di engine database.
  • Katalog memiliki proteksi hak cipta di mana korpus data mentah tidak boleh diakses utuh via network inspect.