Tantangan Volume Konten Masif

Membangun platform pendidikan kelas dunia berarti berhadapan dengan jumlah konten yang sangat masif. Platform kami, rhidayat.work, mengintegrasikan lebih dari 5000+ file markdown interaktif dari sumber seperti Exercism dan freeCodeCamp ke dalam satu aplikasi Astro edge-native yang mulus.

Meskipun sistem konten Astro sangat tangguh, mendorong volume data sebesar ini melalui pipeline build memunculkan beberapa tantangan infrastruktur unik yang tidak akan Anda temukan di tutorial standar.

Masalah 1: Overflow Vite Watcher

Masalah pertama muncul selama pengembangan lokal. Menjalankan bun run dev menghasilkan MaxListenersExceededWarning yang parah dan akhirnya menyebabkan socket crash. Vite mencoba memasang file watcher ke setiap 5000+ file konten tersebut, ditambah dengan direktori tersembunyi .agents dan node_modules. Batas file watcher OS langsung kewalahan.

Solusi: Kami menstabilkan lingkungan lokal dengan meninggalkan runtime Bun yang ketat (bun x --bun astro dev) dan beralih menggunakan eksekusi Node standar (astro dev). Yang lebih penting, kami menyesuaikan konfigurasi di astro.config.mjs secara agresif untuk mengabaikan direktori yang berat:

server: {
  watch: {
    ignored: [
      '**/node_modules/**',
      '**/.agents/**',
      '**/.wrangler/**'
    ]
  }
}

Masalah 2: Konflik Binding “ASSETS”

Selama build produksi, adapter @astrojs/cloudflare secara otomatis menghasilkan file wrangler.json. Namun, ia menyisipkan binding ASSETS generik yang secara ketat dicadangkan oleh Cloudflare Pages. Hal ini menyebabkan CLI deployment langsung menolak build dengan pesan error konfigurasi.

Solusi: Kami menulis plugin Vite closeBundle secara inline (patchWranglerPlugin) yang terhubung ke akhir siklus hidup build Astro. Plugin ini secara aktif memindai folder dist/server yang dihasilkan, mem-parsing file wrangler.json, dan menghapus kunci ASSETS yang konflik sebelum CLI Wrangler membacanya.

Masalah 3: Esbuild Deadlock

Tantangan tersulit adalah kegagalan build yang hening (silent failure). Pipeline produksi berhasil membangun server entrypoints, menyinkronkan semua 5000 file, dan kemudian sepenuhnya macet (hang) selama langkah Rearranging server assets..., menghasilkan Go routine deadlock di dalam esbuild.

Hal ini terjadi karena adapter Cloudflare mencoba untuk membundel server entrypoint yang sangat besar dan padat konten menjadi satu file _worker.js/index.js, yang akhirnya menghabiskan batas konkurensi (concurrency limits) esbuild.

Solusi: Alih-alih memaksa pembuatan SSR worker monolitik untuk situs yang 99% statis, kami memanfaatkan kemampuan prerendering Astro. Build kami menghasilkan keseluruhan 5000 halaman secara statis ke dalam direktori dist/client.

Kami memperbarui skrip deployment kustom kami (cloudflare-deploy.sh) untuk mendeteksi status crash ini. Jika Astro gagal membuat worker akhir tetapi berhasil menghasilkan file klien statis, skrip akan mencegat deployment dan langsung mengunggah direktori dist/client ke Cloudflare Pages.

Untuk memastikan domain root tidak menghasilkan error 404 tanpa SSR router, kami menyuntikkan file _redirects statis langsung ke direktori output sebelum proses upload.

Hasil

Kini kami memiliki pipeline deployment otomatis yang sangat kokoh. Situs telah live di edge, sangat cepat, dan mampu menangani ribuan modul pendidikan terlokalisasi tanpa hambatan sama sekali.

Keunggulan rekayasa (engineering excellence) bukan hanya tentang menulis kode; ini tentang membangun sistem yang tangguh yang mampu menangani skala ekstrem dengan elegan.