Memahami Presigned URL: Solusi Upload File Skala Besar Tanpa Bikin Server Lemot

Pendahuluan

Pernah nggak sih ngerasa aplikasi yang kita bangun tiba-tiba lemot banget? Apalagi pas ada user yang upload file gambar atau video dengan ukuran jumbo. Masalah ini lumayan bikin stres saat kita mendevelop fitur manajemen aset media.

Masalah yang Ingin Diselesaikan

Seringkali, insting pertama kita adalah melempar file dari client langsung ke backend. Secara tradisional, file dikirim ke backend, disimpan sebentar di memori server. Setelah itu, barulah file tersebut dilempar lagi ke layanan cloud storage.

Proses ini sangat memakan RAM dan CPU server aplikasi kita. Apalagi kalau ukuran filenya bergiga-giga atau ada banyak request secara bersamaan. Cara ini justru sering menjadi sumber bottleneck yang mematikan performa server.

Kenapa Presigned URL Lebih Efisien?

Solusi elegan untuk masalah bottleneck ini adalah menggunakan Presigned URL. Metode ini sangat berbeda dengan cara upload konvensional melalui backend. Keuntungannya sangat terasa pada performa keseluruhan sistem.

Berikut beberapa alasan kenapa metode ini jauh lebih baik:

Mengurangi beban memori dan CPU pada server secara drastis.
Proses upload menjadi jauh lebih cepat karena langsung menuju storage.
Sistem lebih scalable karena backend tidak perlu memproses file berat.
Backend tidak lagi menjadi bottleneck saat traffic upload sedang tinggi.

Konsep Dasar

Biar gampang paham, mari gunakan analogi satpam di sebuah gedung logistik. Backend kita itu ibarat satpam, dan cloud storage adalah gudang utamanya. Daripada satpam yang harus manggul barang gede-gede dan bikin antrean panjang.

Satpam cukup mengecek identitas kurir (client) yang datang membawa barang. Lalu satpam memberikan "kunci loker sementara" yang kita sebut Presigned URL. Kurir lalu menaruh barangnya sendiri ke gudang utama tanpa merepotkan satpam.

Gambaran Arsitektur

Alur sistem Presigned URL ini sebenarnya cukup sederhana dan terarah. Client hanya meminta izin kepada backend, lalu berinteraksi langsung dengan Cloud Storage. Berikut adalah gambaran arsitektur kasarnya:

CODE

+--------+       1. Request Presigned URL        +---------+
|        | ------------------------------------> |         |
| Client | <------------------------------------ | Backend |
|        |       2. Return Presigned URL         |         |
+--------+                                       +---------+
     |                                                ^
     | 3. Upload File Directly                        | 4. Webhook /
     |    (Using Presigned URL)                       |    Confirm
     v                                                |
+-------------------+                                 |
|   Cloud Storage   | --------------------------------+
| (AWS S3 / GCS)    |
+-------------------+

Implementasi

Berikut adalah langkah teknis implementasi sistem upload direct ini:

Request Izin: Client mengirim API request ke backend untuk meminta izin upload.
Generate URL: Backend memvalidasi dan membuat Presigned URL dengan batas waktu.
Direct Upload: Client mengunggah file langsung ke storage menggunakan URL tersebut.
Konfirmasi: Client atau Storage memberi tahu backend bahwa file sudah tersimpan.

Berikut contoh backend men-generate Presigned URL menggunakan AWS S3:

CODE

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";

// Inisialisasi S3 Client
const s3Client = new S3Client({ region: "ap-southeast-1" });

export async function generateUploadUrl(fileName, fileType) {
  const command = new PutObjectCommand({
    Bucket: process.env.AWS_BUCKET_NAME,
    Key: `uploads/${Date.now()}-${fileName}`,
    ContentType: fileType,
  });

  // Generate URL yang valid dan bisa digunakan upload selama 3600 detik (1 jam)
  const uploadUrl = await getSignedUrl(s3Client, command, { expiresIn: 3600 });
  return uploadUrl;
}

Kesalahan Umum

Masalah klasik sering muncul setelah proses upload file berhasil diselesaikan. Biasanya kita perlu memproses file tersebut, misal kompresi video pakai FFmpeg.

Banyak developer melakukan kesalahan dengan menjalankan kompresi secara real-time di endpoint konfirmasi. Akibatnya, client harus menunggu loading sangat lama sampai koneksi akhirnya timeout. Solusinya adalah selalu delegasikan tugas berat ini ke sistem Asynchronous Background Job atau message queue.

Refleksi Developer

Jujur, awalnya saya lumayan bingung kenapa fitur upload file selalu jadi momok buat performa aplikasi. Mindset bawaan saya selama ini adalah membiarkan semua request termasuk file besar ditangani langsung oleh backend. Ternyata itu kesalahan pemahaman yang justru bikin antrean proses di server menumpuk dan rawan timeout.

Mempelajari konsep Presigned URL ini benar-benar memberikan insight baru soal efisiensi arsitektur. Saya jadi paham bahwa mendelegasikan tugas transfer data langsung ke cloud storage adalah kunci sistem yang scalable. Backend cukup bertugas sebagai "pengatur lalu lintas" tanpa harus ikut memikul beban file yang berat.

Ke depannya, saya jadi makin penasaran untuk mendalami implementasi background job atau sistem queue. Terutama untuk menangani proses pasca-upload seperti kompresi media agar user tidak perlu menunggu lama. Kombinasi Presigned URL dan proses asynchronous sepertinya memang standar wajib untuk aplikasi modern.

Kesimpulan

Menangani file besar bukan berarti kita harus menyewa server dengan spek dewa yang mahal. Intinya adalah melakukan bypass beban unggahan langsung ke layanan pihak ketiga.

Gunakan Presigned URL untuk upload, dan kerjakan proses berat di background. Dengan pola ini, aplikasi tetap responsif dan pengguna tidak perlu menatap layar loading panjang.