DEV Community: Jidan Fatahillah

File yang Sudah Dihapus Beneran Hilang?

Jidan Fatahillah — Thu, 08 May 2025 16:41:56 +0000

Gue Kira File Gue Udah Hilang, Ternyata Masih Bisa Balik? Lah Kok?

Jadi gini, ceritanya minggu lalu gue lagi bersih-bersih laptop.
Maklum, udah semester akhir, storage mulai megap-megap. Banyak file gak jelas dari awal semester. Mulai dari file tugas, proposal PKL, sampe folder berlabel "fix_banget_final_edited_baru.zip" yang isinya gue pun udah lupa.

Akhirnya gw ambil keputusan berat: hapus-hapusin semua file yang kayaknya udah nggak penting.
Dan gue beneran niat:

Hapus manual
Kosongin Recycle Bin
Bahkan shift+delete buat langsung gone dari muka bumi

Udah puas dong? Gww mikir,

"Oke, storage lega, file udah hilang, hidup gw lebih tenang."

Tapi... besoknya gw baru nyadar.
ADA SATU FILE PENTING YANG IKUT KEHAPUS!
Itu file buat bahan revisi tugas akhir — dan gak ada backup-nya. Panik? IYA LAH.

Mulai Googling, Ketemu EaseUS

Gue cari-cari di Google:
“Cara balikin file yang udah dihapus permanen.”
Dan muncullah nama-nama kayak EaseUS, Recuva, Disk Drill.

Akhirnya gw coba EaseUS. Pas di-scan...

Tiba-tiba muncul file gue yang udah gue anggap ilang.

Jujur gw terheran-heran. Lah kok bisa?(nada pak Irwan)?

Baru Gw Ngerti: Delete Itu Nggak Bikin File Hilang Total

Ternyata, pas lu hapus file (bahkan yang permanen), itu tuh nggak langsung ngilangin isi file dari storage.
Komputer cuma bilang:

“Oke, slot ini sekarang kosong ya. Bisa dipake buat file baru nanti.”

Padahal, isi data masih ngendap di dalam storage. Dan selama belum ketiban sama data baru, ya dia masih bisa dibalikin.

Aplikasi kayak EaseUS itu kerjanya nyari sisa-sisa file lama yang belum ditimpa.
Makanya, file gw bisa diselamatin. Nggak pake cingcong.

Jadi Pelajaran Penting Buat Gw

Hapus file nggak sama dengan ilang beneran.
Kalau nggak pengen file bisa dibalikin, lu harus overwrite atau pake secure delete.
Dan paling penting: BACKUP ITU WAJIB, BRO. Jangan males backup.

Sekarang gue ngerti, di dunia digital, yang lu buang belum tentu bener-bener pergi.
Jadi hati-hati sebelum nyesel.

Idempotency untuk Apa?

Jidan Fatahillah — Wed, 07 May 2025 16:54:06 +0000

Kamu lagi bikin backend API, trus tiba-tiba ada bug: user klik tombol "Bayar" dua kali dan... 😱 mereka ditagih dua kali!

Tenang, kamu cuma butuh satu jurus: idempotency.

📖 Apa Itu Idempotency?

Idempotency adalah sifat dari suatu operasi yang tidak berubah hasil akhirnya walaupun dilakukan berkali-kali dengan input yang sama.

🎓 Sekarang lo adalah Mahasiswa...

Bayangin dehh lu ngisi KRS (Kartu Rencana Studi). terus klik tombol “Ambil Mata Kuliah A” satu kali:

✅ Data masuk ke sistem.

Eh, lo panik, koneksi jelek, lo klik lagi...

✅ Sistem bilang: “Mata kuliah A sudah diambil.”

Hasil akhirnya? Sama. lo tetap ambil 1 kelas.
Inilah idempotent operation.

Sekarang bandingkan dengan contoh yang tidak idempotent.

😬 Operasi yang Tidak Idempotent

Lo transfer uang lewat aplikasi:

Tekan tombol "Transfer" sekali: 💸 uang terkirim.
Tapi karena loading terus, lo pencet lagi...
💸 uang terkirim dua kali!

⚠️ Ini operasi tidak idempotent, karena hasil akhirnya berubah setiap kali dijalankan.

🧪 HTTP dan Idempotency

HTTP method juga punya karakter idempotency:

Method	Idempotent?	Penjelasan
GET	✅ Ya	Ambil data, tidak ubah apapun.
PUT	✅ Ya	Overwrite data, hasil akhirnya sama.
DELETE	✅ Ya	Hapus data, kalau dihapus lagi tidak berubah.
POST	❌ Tidak	Buat data baru, ulangi = data baru lagi.
PATCH	⚠️ Kadang	Bergantung implementasinya.

💡 Kenapa Kita Butuh Idempotency?

Koneksi Jelek
Server bisa lambat. User sering tekan tombol berkali-kali.
Retry Otomatis
Banyak client (termasuk frontend dan load balancer) akan otomatis ulangi request kalau gagal.
Keamanan & Kepercayaan
Gak lucu kalau transaksi keuangan malah dua kali keluar uang cuma karena user panik ngeklik lagi.

🛡️ Cara Bikin POST Idempotent: Gunakan `Idempotency-Key`

Untuk method yang secara default tidak idempotent, kayak POST, kita bisa kasih akal-akalan dengan header unik.

Contoh:

POST /api/payment
Idempotency-Key: 123e4567-e89b-12d3-a456-426614174000

Server akan:

Mengecek apakah Idempotency-Key itu sudah pernah dipakai.
Kalau sudah → balikin response yang sama seperti sebelumnya.
Kalau belum → proses dan simpan hasilnya berdasarkan key-nya.

🎯 Jadi walaupun user klik “Bayar” berkali-kali, uang hanya keluar sekali.

Implementasi Dasar Idempotency di Backend

Di sisi server:

Simpan idempotency_key, payload, dan response di database.
Saat request datang:
- Cari key → kalau ada, balikin response lama.
- Kalau tidak → proses dan simpan.

Contoh tabel:

idempotency_key	user_id	endpoint	response	created_at
abc123	101	`/payment`	{ status: "paid" }	2025-05-07 10:10:10

🧰 Studi Kasus Nyata

Stripe (pembayaran online)

Stripe adalah contoh emas. Mereka mewajibkan penggunaan Idempotency-Key untuk semua request penting seperti:

Membuat pembayaran
Membuat pelanggan
Melakukan refund

Baca di sini: Stripe Docs - Idempotency

Gojek / Grab

Kalau lo pencet "Order GoRide" dua kali, aplikasi tetap kirim 1 driver. Mereka pasti pakai idempotency untuk menjaga supaya lo gak disamperin 2 motor.

🧠 Kesimpulan
Idempotency penting buat API yang aman dan tidak bikin user panik atau rugi.

Gunakan Idempotency-Key untuk method seperti POST supaya aman dari dobel klik dan retry otomatis.

Pahami sifat HTTP method, jangan asal pilih POST buat semua hal.

🚀 Intinya, bikin API lu kayak orang yang sabar — meski diminta berkali-kali, tetap konsisten, tenang, dan gak panik.
Kalau user lagi ngambek pencet tombol terus, lu tetap bisa jawab: “Tenang, ini udah aku proses kok.” 😉

Buat sistem kamu lebih bisa di-retry, robust, dan gak bikin drama.

📚 Referensi

Kalau lu suka artikel ini, jangan lupa share, kasih ❤️, dan kalau ada pengalaman menarik seputar API atau idempotency, yuk sharing di komentar!

Commit Git Lo Kayak Skripsi Setengah Jadi? Yuk Rapihin, Biar Tim Lo Gak Kena Mental 😵‍💫

Jidan Fatahillah — Tue, 06 May 2025 15:54:20 +0000

🧠 Intro: Cerita Lo, Cerita Kita

Gue yakin lo pernah di fase ini: tengah malam, ngerjain project bareng tim, otak udah ngebul, dan tinggal satu hal yang harus lo lakuin...

git commit -m "fix lagi, entahlah"
git push origin main

Done. Close laptop. Tidur.

Fast forward seminggu kemudian, tim lo panik: ada bug. Lo disuruh telusurin siapa yang ngubah logic di file authController.js. Lo buka Git history... dan isinya cuma commit kayak "update", "fix", "ga tau kenapa error".

Udah deh, kaya baca jurnal tapi semua referensinya ditutupin.

Gue pernah di posisi itu. Dan lo (mungkin) juga. Makanya gue nulis ini: biar lo gak mengulang dosa commit yang sama.

📦 Commit Message Itu Bukan Formalitas. Itu Logbook Perjuangan.

Anggep aja commit message itu kayak catatan lapangan skripsi lo yang pastinya harus rapi, jelas, dan bisa dipahami orang lain (termasuk lo sendiri di masa depan waktu buka proyek lama pas disuruh revisi portofolio).

Nah, untungnya udah ada aturan Conventional Commit yang ngebantu lo nulis commit yang cakep tanpa mikir terlalu lama. Formatnya simple, bro:

<tipe>(opsional scope): deskripsi singkat

Contoh paling basic:

feat(auth): Tambahin fitur login pake OTP

🧩 Jenis-Jenis Commit: Anggep Aja Ini Karakter di Party Game

Tipe Commit	Fungsi	Analogi
`feat`	Nambah fitur baru	Tank: maju duluan buka jalan
`fix`	Benerin bug	Support: backup tim pas ada yang jatoh
`docs`	Update dokumentasi	NPC: diem-diem penting, bro
`style`	Perubahan tampilan code (tanpa ngubah logic)	Make-up Artist: biar rapi, enak diliat
`refactor`	Ngubah struktur code tanpa ubah hasilnya	Arsitek: ngerombak rumah biar lebih kuat fondasinya
`test`	Tambahin atau edit test	QA: biar bug gak kabur pas release
`chore`	Segala hal non-kode utama (update deps, config)	OB kantor: kerjaannya gak keliatan, tapi chaos kalau gak ada

🛠 Contoh Real-Life Commit yang Mendingan Dibaca Daripada Skripsi

fix(auth): Benerin bug login gara-gara email case-sensitive

Sebelumnya user gagal login kalau input email pakai huruf kapital.
Sekarang semua email di-normalisasi ke lowercase.

Closes #42

Commit di atas gak cuma ngasih tau apa yang berubah, tapi juga kenapa.

🚀 Kenapa Lo Harus Peduli?

"Kan yang penting bisa jalan, bro."

Iya, sampe lo kerja tim. Atau open-source. Atau buka project lama 3 bulan lagi.
Commit message yang jelas bisa:

Bikin code review gak bikin ngelus dada
Memudahkan generate changelog otomatis
Ngebantu tracing bug dari commit sebelumnya
Kasih gambaran apa yang dikerjain siapa, kapan, dan kenapa

Pokoknya lo kayak nyiapin surat cinta buat pembaca codebase lo. 🥲

📚 Referensi Buat Lo Yang Mau Dalemin

📜 Conventional Commits – Ini panduan utamanya
✍️ Chris Beams - How to Write a Git Commit Message – Gaya klasik, tapi solid
📖 Git Docs - Git Commit – Buat yang mau ngebaca versi “resmi” dari Git

💬 Penutup: Commit Message Lo, Warisan Lo

Kalau lo anggap coding itu seni, commit message itu caption-nya.
Dan percayalah, caption yang bagus bisa bikin orang ngerti dan jatuh cinta.

So, next time lo commit, pikirin:
“Kalau ini dibaca doi gue, malu gak?”

Gimana, bro? Kalau lo punya pengalaman lucu atau pahit soal commit message, atau tim lo punya gaya commit sendiri, drop di kolom komentar ya. Kita bahas bareng!

👊 Keep coding, keep pushing. Kasih pesan, bukan misteri.

Validasi di Frontend dan Backend: Kenapa Harus Dua-duanya?

Jidan Fatahillah — Mon, 05 May 2025 16:57:49 +0000

Yo, Guys! mari mabar.

Jadi gini, pas kita lagi ngoding aplikasi, mau itu web app, mobile, atau bikin API pasti bakal ada momen kita nerima input dari user, kan? Entah itu form registrasi, data login, upload file, atau apa pun lah.

Nah, data yang masuk ini nggak bisa langsung kita percaya gitu aja. Sebelum diproses atau dilempar ke database, kita wajib pastiin dulu datanya itu valid, lengkap, dan formatnya sesuai sama yang kita harapkan.

Proses ini, ya kalian udah tau lah, namanya Validasi Data.

Tapi sering banget muncul pertanyaan klasik nih di kalangan developer, termasuk kita-kita:

"Bro, validasi di frontend aja cukup nggak sih? Kan udah dicek di browser user. Atau mending di backend aja biar lebih secure?" 🤔

Simple answer: Nggak cukup satu, Guys. Harus dua-duanya. Validasi itu kudu jalan di frontend DAN backend.

Kenapa gitu? Oke, let's cekidot. 👇

📌 Definisi Validasi Data

Intinya, validasi itu proses nge-filter dan ngecek data input dari user biar sesuai sama rules yang udah kita tentuin. Contoh rules-nya:

Email harus pake format nama@domain.com.
Password minimal 8 karakter, ada kombinasi huruf besar-kecil, angka, simbol (biar nggak gampang kena brute force).
Nomor HP harus angka semua, panjangnya sekian digit.
Field nama nggak boleh kosong (required).
Tipe data harus bener (misal, umur ya harus integer, bukan string).

Tujuannya? Jelas, biar data di database kita bersih (data integrity), aplikasi nggak gampang crash gara-gara data aneh, dan yang paling krusial: nutup celah keamanan dari malicious input.

🖥️ Validasi di Frontend (Sisi Klien/Browser)

Ini validasi yang kita implementasiin pake HTML5 attributes (required, minlength, pattern, dll) atau pake JavaScript yang jalan di browser user.

Fungsi utamanya lebih ke User Experience (UX):

Kasih feedback instan ke user kalo ada yang salah input.
Mencegah submit form kalo datanya belum bener.
Bikin interaksi user lebih mulus dan nggak bikin frustrasi.

Contoh simpel pake JS:

// Ambil value dari input email
const emailInput = document.getElementById('email');
// Cek simpel pake regex atau string method
if (!emailInput.value.includes('@') || !emailInput.value.includes('.')) {
    // Kasih warning langsung di UI, jangan cuma alert() hehe
    showError(emailInput, 'Format emailnya belum bener, Bro!');
}

Validasi frontend ini penting banget buat kenyamanan *user. Mereka jadi tau kesalahannya di mana *sebelum data dikirim ke server.

✅ Plus-nya Validasi Frontend:

Responsif: Feedback cepet, nggak perlu nunggu round trip ke server.
UX Mantap: User nggak perlu nunggu lama buat tau ada yang salah.
Ngeringanin Beban Server: Request yang udah pasti salah nggak perlu dikirim.

⚠️ Minus-nya Validasi Frontend:

Gampang Banget Di-Bypass! Siapa pun yang ngerti dikit soal web dev bisa matiin JS di browser, pake DevTools, atau langsung hit API pake Postman/curl. Validasi frontend jadi nggak ada gunanya.
Nggak Bisa Jadi Andalan Keamanan: Karena bisa dilewatin, ini bukan benteng keamanan.

Main rule: Never trust client-side code for security. Semua yang jalan di client itu bisa dimanipulasi.

🔐 Validasi di Backend (Sisi Server)

Ini dia benteng pertahanan utama. Validasi yang kita implementasiin di sisi server pake bahasa backend kita (Node.js, PHP, Python, Go, Java, dll). Semua data yang diterima dari request (mau itu dari browser, Postman, atau aplikasi lain) wajib hukumnya divalidasi ulang di sini.

Contoh di Node.js pake library kayak Joi atau Express-validator:

// Pake Joi buat define schema validasi
const userSchema = Joi.object({
    email: Joi.string().email().required(),
    password: Joi.string().min(8).pattern(new RegExp('^[a-zA-Z0-9]{3,30}$')).required(), // Contoh pake pattern regex
    age: Joi.number().integer().min(17).required() // Umur minimal 17
});

// Di dalam route handler (misal Express)
const { error, value } = userSchema.validate(req.body); // Validasi req.body

if (error) {
    // Kalo validasi gagal, kirim response error 400 (Bad Request)
    return res.status(400).json({ message: 'Input tidak valid', details: error.details });
}
// Kalo lolos, baru `value` (data yg udah divalidasi & mungkin di-sanitize) diproses lanjut
// Misal: simpan ke database...

✅ Plus-nya Validasi Backend:

Secure: Nggak bisa di-bypass sama user. Ini single source of truth buat aturan data.
Melindungi Integritas Data: Mastiin data yang masuk ke database atau diproses logic bisnis itu beneran valid.
Menjaga Konsistensi Business Logic.
Wajib Ada untuk semua API endpoint, terutama yang public.

⚠️ Minus-nya Validasi Backend:

Feedback ke User Lebih Lambat: Perlu request dikirim dulu, diproses server, baru response balik.
Butuh Network Round Trip.

🤝 Jadi, Kenapa Harus Dua-duanya?

Karena frontend dan backend punya peran dan tujuan yang beda tapi saling melengkapi. Bukan pilihan either/or, tapi both. Kek aku dan kamu aokwoakwoa.

Lokasi Validasi	Fokus Utama	Bisa Di-Bypass?	Feedback Cepat?	Security?
Frontend	UX, Kenyamanan User	Yoi (Mudah)	Yoi (Instan)	Tidak Aman
Backend	Keamanan, Integritas Data, Rules	TIDAK	Tidak Instan	Wajib Aman

Gampangnya gini:

Frontend itu buat kenyamanan (convenience), Backend itu buat keamanan (security).

Contoh skenario ideal:

User salah ketik format email di form.
Frontend (JS): Langsung ngasih warning di bawah input field, "Format email salah nih." -> UX bagus.
User iseng bypass validasi frontend pake Postman, kirim email ngasal.
Backend (Server): Nerima request, jalanin validasi backend. "Wah, email nggak valid!" -> Request ditolak (400 Bad Request), data sampah nggak masuk sistem. -> Security terjaga.

⚠️ Risiko Kalo Cuma Validasi di Satu Sisi?

Frontend Aja (Tanpa Backend)
- ⛔ Fatal! Sistem lo gampang banget dieksploitasi. SQL Injection, XSS, data korup di DB, semua bisa terjadi.
- ✅ UX mungkin oke, tapi keamanannya nol besar. Nggak sustainable.
Backend Aja (Tanpa Frontend)
- ✅ Aman? Iya. Data dijamin valid sesuai rules server.
- ⛔ UX Jelek. User harus submit dulu, nunggu loading, baru dikasih tau ada error di field A, B, C. Bolak-balik gitu terus bisa bikin user emosi jiwa. 😤

Jadi, jelas ya? Kalo frontend doang, aplikasi lo rapuh. Kalo backend doang, user nggak nyaman pakenya.

✅ Best Practice Validasi

Biar implementasi validasi lo bener:

💡 Gunakan *Library/Framework Validation:* Jangan reinvent the wheel. Manfaatin library kayak Joi, Yup, Zod, class-validator (Node.js/TS), atau fitur validasi bawaan framework (Laravel, Django, Spring Boot, dll). Ini lebih efisien dan less error-prone.
🧪 Validasi Semua Entry Point Data: Termasuk request body, query parameters, path parameters (URL), headers, cookies, dan file uploads. Jangan ada yang lolos!
🔁 Re-validate di Backend: Ini mantra wajib. Selalu validasi ulang di backend, jangan pernah percaya 100% sama data yang udah "lolos" validasi frontend.
🔐 Treat All User Input as Untrusted: Punya mindset zero-trust ke input dari luar.
✨ Shared Validation Schema (Opsional tapi Keren): Kalo memungkinkan (misal pake fullstack TypeScript), coba pake library kayak Zod yang bisa bikin schema validasi yang sama buat dipake di frontend dan backend. Biar DRY (Don't Repeat Yourself).

🧠 Kesimpulan Akhir

Validasi data itu fundamental banget dalam software development. Nggak bisa dianggap remeh. Jangan pilih satu sisi aja.

Validasi frontend itu kayak asisten dosen yang ngecek kelengkapan laporan sebelum dikumpul biar rapi dan enak dilihat.
Validasi backend itu kayak dosen killer yang meriksa isi laporannya beneran sesuai kaidah atau nggak ini penentu utama lulus atau nggaknya.

Jadi, WAJIB pake dua-duanya. Bikin aplikasi yang user-friendly di depan, tapi juga robust dan secure di belakang. Oke, Guys? 😉

Semoga penjelasan ini bermanfaat ya! Kalo ada pengalaman atau tips lain soal validasi, sharing aja di bawah! 👇