Lewati ke konten utama
menjadi.dev
Chapter 40.1 Data & Storage Lanjutan

Arsitektur File Upload: Client ke Server ke Storage

Mendesain pipeline upload file dari browser sampai tersimpan aman di cloud storage

Tujuan Pembelajaran

  • Memahami arsitektur file upload: client → API server → object storage
  • Mengerti kenapa file TIDAK BOLEH disimpan di server application
  • Mampu memilih strategi upload berdasarkan ukuran file (small vs large)

Analogi

Diagram

      File Upload = Gudang vs Meja Kerja:

Menyimpan file di server app (public/ atau /uploads):
= Menaruh semua barang di meja kerja
→ Meja penuh, server lambat, tidak scalable, hilang kalau server restart

Menyimpan file di object storage (S3/R2):
= Menaruh barang di gudang khusus
→ Server app = kurir yang mengantar ke gudang
→ Scalable, durable (99.999999999% durability), murah ($0.023/GB S3)
    

File TIDAK BOLEH disimpan di server application. Object storage (S3/R2) adalah 'gudang' untuk file — scalable, durable, terpisah dari server.

Penjelasan Konsep

File upload terlihat sederhana — user pilih file, klik upload, selesai. Tapi di baliknya ada arsitektur yang perlu mempertimbangkan: ukuran file, concurrency, keamanan, dan durability.

Kenapa file tidak boleh di server app: (1) Ephemeral storage — server restart/scale, file hilang. (2) Tidak scalable — multiple server instances tidak share filesystem. (3) Security risk — uploaded file bisa dieksekusi (shell, script). (4) Backup nightmare.

Arsitektur yang benar: (1) Client upload ke server API (atau langsung ke object storage via presigned URL). (2) Server validasi (size, type, virus scan). (3) Server upload ke object storage (S3, Cloudflare R2, MinIO). (4) Simpan metadata di database (URL, size, uploader, timestamps). (5) CDN serve file ke user (CloudFront, Cloudflare).

Dua strategi upload: (1) Server proxy — client → server → S3. Simple, server bisa validasi sebelum upload. Untuk file kecil (<10MB). (2) Presigned URL — client langsung upload ke S3 tanpa lewat server. Untuk file besar. Server generate signed URL yang expire dalam waktu singkat.

Inti yang Perlu Dipahami

Bagian ini berfokus pada memahami arsitektur file upload: client → API server → object storage., mengerti kenapa file TIDAK BOLEH disimpan di server application., dan mampu memilih strategi upload berdasarkan ukuran file (small vs large). Jangan terburu-buru menghafal istilahnya. Lebih penting untuk memahami peran setiap konsep dan kapan konsep itu muncul dalam pekerjaan web development.

Saat membaca Arsitektur File Upload, gunakan tujuan belajar sebagai penanda arah. Kalau kamu sudah bisa menjelaskan tujuan itu dengan kata-katamu sendiri, berarti fondasinya mulai terbentuk.

Cara Membayangkannya

File TIDAK BOLEH disimpan di server application. Object storage (S3/R2) adalah ‘gudang’ untuk file — scalable, durable, terpisah dari server. Analogi ini dipakai supaya konsep teknis tidak terasa melayang. Hubungkan setiap istilah dengan perannya: siapa yang meminta, siapa yang memproses, data apa yang berpindah, dan hasil apa yang diharapkan.

Kalau analoginya sudah terasa masuk akal, barulah lihat istilah teknisnya. Cara ini membuat materi lebih mudah dipahami daripada langsung menghafal definisi.

Konteks dalam Perjalanan Belajar

Setiap konsep di platform ini dipilih karena dipakai di industri. Fokus pada pemahaman, bukan hafalan.

Kamu sudah di bagian lanjutan. Mulai pikirkan bagaimana konsep ini dipakai di dunia kerja — bukan hanya untuk belajar, tapi untuk membangun produk nyata.

Gunakan pertanyaan reflektif dan prompt AI di akhir chapter sebagai latihan aktif. Membaca saja tidak cukup — kamu perlu menjelaskan ulang dengan kata-katamu sendiri.

Prompt AI

Desain arsitektur file upload untuk aplikasi: user upload foto profil (max 5MB) + video (max 500MB). Berikan diagram arsitektur dan jelaskan kenapa strategi berbeda untuk kedua tipe file.

Pertanyaan Reflektif

Di mana aplikasi-mu menyimpan uploaded files? Apakah di server application? Kalau server-mu direstart, apakah file tetap ada?