Analisis Arsitektur & Panduan Menulis Ulang Platform E-Commerce: Perbandingan Kustom SPA vs WooCommerce

Banyak orang berpikir bahwa membangun toko online dengan teknologi paling modern seperti React dan API kustom otomatis lebih baik daripada WordPress atau WooCommerce. Namun, setelah menganalisis secara teknis sebuah platform e-commerce kustom yang berjalan di atas React/Vite SPA dengan backend REST API sendiri, ditemukan bahwa kebenarannya jauh lebih kompleks. Analisis ini akan mengupas tuntas arsitektur yang ada, membandingkannya dengan WooCommerce, dan memberikan panduan untuk menulis ulang platform tersebut dengan lebih baik tanpa kehilangan esensi kustomnya.

Arsitektur yang Ada: Tiga Lapisan & Nuansa Teknis

Platform ini jelas bukan WooCommerce, Shopify, atau WordPress headless. Struktur API, skema produk, dan alur kerjanya (seperti kupon dan PayPal) adalah hasil desain domain sendiri. Arsitekturnya terdiri dari tiga lapisan utama:

1. Cloudflare/CDN: Bertindak sebagai proxy terbalik yang menyajikan aset statis (yang sudah di-hash) dan meneruskan permintaan dinamis ke server asal.
2. React SPA (Single-Page Application): Dibangun dengan Vite, SPA ini menangani semua rendering antarmuka dan navigasi di sisi klien (browser).
3. Backend REST Kustom: Menyediakan semua data dan logika bisnis, mulai dari katalog produk, CMS, konfigurasi toko, hingga kupon, pembayaran PayPal, kontak, dan newsletter.

Alur Muatan Halaman Pertama & Nuansa SEO

Saat pengguna mengakses URL mana pun (misal /shop atau /product/sepatu-baru), server mengembalikan "app-shell" HTML yang sama dengan elemen

<div id="root">

Ini adalah poin kritis. Keberadaan variabel window.__... bukan bukti bahwa situs menggunakan Server-Side Rendering (SSR). Jika HTML awal hanya berisi JSON dan div kosong, itu adalah preloading untuk Client-Side Rendering (CSR), bukan SSR sungguhan. Konten produk (judul, harga, gambar) baru muncul setelah JavaScript berjalan.

Hal ini menimbulkan risiko SEO yang signifikan. Google mungkin kesulitan mengindeks konten jika JavaScript tidak di-render dengan sempurna. Lebih buruk lagi, rute yang salah (misal /produk/yang-tidak-ada) juga mengembalikan app-shell dengan status HTTP 200, yang oleh Google dianggap sebagai "soft 404" .

Kekuatan & Kelemahan Arsitektur Kustom

Kekuatan:

• Kontrol UI Penuh: Tim pengembang memiliki kendali absolut atas pengalaman merek, mulai dari animasi hingga tata letak editorial.
• Aset Statis yang Sangat Cepat: Nama file yang di-hash oleh Vite memungkinkan cache jangka panjang (

  Cache-Control: immutable

  ).
• CMS Kustom yang Tepat Sasaran: Homepage dan layout builder dirancang khusus untuk kebutuhan toko, menghindari kerumitan plugin page-builder umum.
• Navigasi Cepat: Setelah muatan pertama, navigasi antar halaman terasa instan karena hanya data yang diambil ulang, bukan seluruh halaman.

Kelemahan & Risiko:

• First Load Bergantung pada JavaScript: Pengguna dengan koneksi lambat atau perangkat rendah akan melihat layar kosong yang lama.
• Waterfall API: Permintaan ke pengaturan, tata letak, beranda, dan produk sering dilakukan berurutan, memperlambat Largest Contentful Paint (LCP).
• Risiko SEO: Soft 404, metadata yang tidak konsisten, dan kesulitan crawler dalam mengindeks konten [1, 3, 4].
• Model Data Belum Standar: Sistem inventaris dan varian produk bermasalah. Stok disimpan di level produk, bukan varian. Nilai atribut tidak konsisten (ada XXL dan 2XL,

  ink navy

  dan

  Ink Navy

  ), yang menyulitkan filter dan analitik.
• Risiko Keamanan: Setiap endpoint publik (kontak, ulasan, newsletter) membutuhkan validasi, rate-limiting, dan idempotensi yang ketat. Endpoint pelacakan tidak boleh menerima data sembarangan.

Perbandingan Langsung: Kustom SPA vs. WooCommerce

Kesimpulan: Kustom memberikan kontrol lebih besar, tetapi WooCommerce memiliki keunggulan bawaan dalam SEO, back-office, dan biaya perawatan untuk toko kecil. TIDAK ADA yang secara otomatis lebih "keren" atau lebih cepat.

Rekomendasi: Strategi Penulisan Ulang yang Tepat

Alih-alih mengganti ke WooCommerce atau mempertahankan SPA murni, rekomendasi terbaik adalah menulis ulang storefront dengan pendekatan hibrida. Jangan buang investasi di CMS kustom dan UI merek yang sudah ada, tetapi perbaiki fondasi teknisnya.

Stack yang Direkomendasikan

• Storefront: Next.js App Router + React + TypeScript. Ini memungkinkan Server Components untuk rendering statis (SSG/ISR) pada halaman produk, sementara komponen interaktif (seperti keranjang) tetap bersifat client-side. Hasilnya: HTML berisi konten lengkap yang ramah SEO dan cepat untuk first load.
• Backend: NestJS/Fastify dengan TypeScript. Gunakan PostgreSQL sebagai database utama dengan Drizzle ORM atau Prisma untuk type safety. Redis hanya jika benar-benar diperlukan untuk caching atau distributed lock. Gunakan S3-compatible storage untuk media.
• Deployment: Pisahkan storefront dan API. Gunakan CDN/edge caching untuk storefront untuk mengurangi beban server. Manajemen rahasia (secrets) harus melalui secret manager, bukan di repositori.

Pendekatan ini mempertahankan fleksibilitas UI yang sudah ada, secara dramatis meningkatkan performa dan SEO, serta memberikan fondasi yang lebih kokoh untuk pengembangan di masa depan. Jangan pilih teknologi berdasarkan hype, tetapi berdasarkan bukti dan kebutuhan.