Fase 3 · Jalur API

"API menghemat koneksi database" — meluruskan argumennya

Menaruh API di antara Astro dan MySQL tidak mengurangi jumlah koneksi. Ia memindahkan pool-nya. Yang menentukan benar atau tidaknya adalah di mana Astro berjalan, bukan bahwa API itu ada.

Sumber asli docs.aws.amazon.com Resmi Rangkuman ~10 menit baca

Intisari

API tidak mengurangi koneksi database — ia memusatkan pool-nya di satu proses.
Kalau Astro berjalan sebagai proses panjang (ECS/EC2), pool-nya sudah terpusat. API menambah satu hop tanpa menyelesaikan apa pun.
Kalau Astro berjalan di Lambda, kekhawatirannya nyata — dan jawaban AWS-nya adalah RDS Proxy, bukan API buatan sendiri.
Alasan yang benar untuk memakai API: klien lain (aplikasi mobile), batas tim, dan menjaga kredensial DB jauh dari lapisan penyaji.
Untuk portalmu di ECS Fargate: baca publik langsung lewat Kysely, membership dan pembayaran lewat API.

Membongkar argumennya

Klaimnya: "kalau semua koneksi database dihandle API, kita hemat koneksi." Mari hitung.

TANPA API — Astro langsung ke MySQL
  12 task Astro × pool 10  =  120 koneksi

DENGAN API — Astro → API → MySQL
  12 task Astro × pool HTTP (bukan koneksi DB)  =  0 koneksi DB
   4 instance API × pool 10                     =  40 koneksi DB

Hemat 80 koneksi?

Bukan penghematan — pemindahan. Angkanya turun karena instance API-nya lebih sedikit, bukan karena ada API. Kalau kamu menjalankan 12 task Astro dengan pool 4 alih-alih 10, kamu mendapat angka yang sama tanpa membangun apa pun.

Dan API itu sendiri butuh kapasitas. 500 ribu request per jam yang tadinya langsung ke database sekarang jadi 500 ribu request HTTP ke API, ditambah 500 ribu kueri database dari API. Kamu menambah satu lapisan yang harus di-deploy, dipantau, di-scale, dan bisa mati sendiri — untuk beban yang sama.

Yang menyelesaikan masalah koneksi bukan API, tapi connection pooling. Dan pooling sudah kamu punya begitu Astro berjalan sebagai proses panjang. Yang tidak punya pooling efektif adalah runtime tanpa proses panjang — dan di sana ada solusi khusus yang jauh lebih murah daripada membangun API sendiri.

Kapan kekhawatiran itu benar-benar nyata

Astro berjalan di	Masalah koneksi?	Jawaban yang benar
ECS Fargate / EC2	Tidak — pool hidup selama proses hidup	Koneksi langsung, hitung `connectionLimit` dengan benar
Lambda	Ya, serius — tiap eksekusi bisa membuka pool sendiri	RDS Proxy
Cloudflare Workers	Ya — tidak ada koneksi TCP persisten	Hyperdrive
Vercel / Netlify serverless	Ya	RDS Proxy atau pooler pihak ketiga

RDS Proxy adalah layanan AWS yang duduk di depan RDS dan memelihara pool koneksi bersama. Ratusan eksekusi Lambda berbagi puluhan koneksi database sungguhan. Ia juga menangani failover lebih cepat dan bisa mengambil kredensial dari Secrets Manager, sehingga aplikasimu tidak pernah memegang sandi database.

Untuk portalmu di ECS Fargate, RDS Proxy tidak diperlukan — tapi ketahui bahwa ia ada, karena kalau suatu saat sebagian bebanmu pindah ke Lambda, inilah jawabannya. Bukan API.

Alasan yang benar untuk membangun API

Alasan	Berlaku untukmu?
Ada klien selain website. Aplikasi mobile, mitra, ekspor data pelanggan.	Kemungkinan besar ya — portal data biasanya punya konsumen lain
Logika bisnis tidak boleh digandakan. Aturan siapa yang boleh melihat apa harus hidup di satu tempat.	Ya — aturan paywall dan langganan
Batas tim. Tim data memiliki data perusahaan; tim web memiliki tampilannya.	Tergantung struktur timmu
Kredensial DB tidak boleh ada di lapisan penyaji.	Relevan kalau lapisan penyajimu suatu saat pindah ke edge
Sumber datanya memang bukan MySQL-mu. Data pasar dari vendor, kurs, cuaca.	Ya — dan di sini tidak ada pilihan lain
"Menghemat koneksi database"	Tidak. Itu bukan alasan yang berdiri sendiri

Biaya yang jarang dihitung

Tiap hop menambah latensi, dan latensi itu berlipat di halaman yang butuh beberapa data.

Astro → MySQL (satu VPC)              ~1–3 ms per kueri
Astro → API → MySQL (satu VPC)        ~6–15 ms per kueri
Astro → API lintas region             ~50–150 ms per kueri

Halaman beranda dengan 6 kueri:
  langsung        ~12 ms
  lewat API       ~60 ms
  lintas region   ~500 ms  ← ini terasa oleh pembaca

Ditambah: satu layanan lagi yang bisa mati, satu deploy lagi yang bisa gagal, satu tempat lagi untuk mencari saat ada yang salah, dan kontrak tipe yang harus dijaga manual di antara keduanya.

Ini bukan argumen menentang API. Ini argumen menentang membangun API untuk alasan yang salah. Kalau kamu punya aplikasi mobile, bangun API-nya — dan itu keputusan yang benar meski latensinya bertambah. Yang tidak benar adalah menambah lapisan untuk menyelesaikan masalah koneksi yang tidak kamu miliki.

Rekomendasi untuk portalmu: hibrida

Data	Jalur	Alasan
Artikel, kategori, tag, penulis	Kysely langsung	Volume terbesar, latensi paling terasa, hanya website yang memakainya
Data perusahaan (tampilan)	Kysely langsung	Sama — dan bisa di-cache di edge
Status langganan & hak akses	API	Aturannya harus satu, dipakai web dan mobile
Pembayaran & tagihan	API	Menyentuh uang; dipisahkan supaya bisa diaudit sendiri
Data pasar dari vendor	API luar	Bukan datamu
Pencarian	API (OpenSearch)	Bukan MySQL

Pembagiannya mengikuti satu pertanyaan: apakah data ini punya konsumen selain halaman yang sedang dirender? Kalau ya, API. Kalau tidak, langsung.

Kalau ternyata jawabannya API untuk semuanya

Kalau timmu memutuskan sebaliknya — misalnya karena aplikasi mobile sudah ada dan API-nya sudah dibangun — itu keputusan yang sah, dan sisa fase ini tetap berlaku sepenuhnya. Yang perlu kamu bawa:

Anggaran latensi jadi jauh lebih ketat. Satu halaman tidak boleh menunggu enam panggilan berurutan.
Cache jadi wajib, bukan optimasi. Materi cache di fase ini jadi yang terpenting.
API-mu harus punya timeout dan fallback yang jelas, karena sekarang ia bisa menjatuhkan situsmu.

Latihan: daftarkan sepuluh potong data yang muncul di beranda portalmu. Untuk tiap satu, jawab: apakah ada konsumen lain selain halaman ini? Berapa sering berubah? Boleh basi berapa lama? Tiga jawaban itu menentukan jalurnya dan strategi cache-nya. Simpan tabelnya — ia jadi rancangan arsitektur datamu untuk sisa roadmap ini.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.