Firebase & Realtime Itu Apa? (Sama Kenapa Banyak Dev yang Pindah)

Gue inget pertama kali cobain Firebase. Saat itu lagi bikin chat app kecil-kecilan buat project kampus. Awalnya pake MySQL + Express + polling 5 detik tiap refresh. Jalan, tapi nanggung - pesan baru munculnya delay, dan bandwidth boros. Terus temen recommand Firebase Realtime Database. Dalam 1 jam gue hapus semua code polling, dan pesan langsung muncul di layar lawan tanpa refresh. Itu magic pertama gue sama "realtime."

Tapi setelah pake buat 2 project beneran, gue sadar: Firebase itu powerful, tapi "realtime" bukan berarti cocok buat semua hal. Dan blog ini justru pake Supabase, bukan Firebase. Kenapa? Itu yang mau gue jelasin.

---

Firebase Itu Sebenernya Apa?

Firebase itu backend-as-a-service bikinan Google (aslinya Firebase Inc., diakuisisi 2014). Intinya: lo gak perlu nulis backend sendiri. Install SDK, langsung punya:

• Database (Realtime Database atau Firestore)
• Auth (login Google/email/phone)
• Storage (file/foto)
• Hosting
• Cloud Functions (mirip Edge Functions Supabase)
• Analytics, Push Notification, Crashlytics, dll

Satu platform, semua kebutuhan backend jadi tinggal klik-klik di dashboard. Buat MVP kecil atau project pribadi, ini bener-bener ngehemat waktu. Gue pernah shippin app polling internal dalam 2 hari pake Firebase - hal yang kalau pake Express + Postgres butuh 2 minggu.

---

"Realtime" Itu Apa Sih?

Ini kuncinya. Banyak yang salah ngerti.

Realtime bukan "cepat." Realtime itu: perubahan data langsung tersinkron ke semua client yang lagi buka, tanpa lo harus request ulang.

Cara kerjanya pake WebSocket (atau long-polling buat fallback). Lo subscribe ke path di database, misal messages/chat-room-1. Tiap kali path itu berubah - entah tambah, edit, hapus - Firebase langsung push data baru ke semua subscriber.

Bandingin sama REST API tradisional:

• REST: client nanya "ada pesan baru?" tiap 5 detik → namanya polling. Boros bandwidth, ada delay 5 detik.
• Realtime: server bilang "ini pesan baru" begitu ada → namanya push. Hemat, instant.

Pseudocode simpelnya:

import { getDatabase, ref, onValue, push } from "firebase/database"

const db = getDatabase()
const roomRef = ref(db, "messages/chat-room-1")

// Langganan: tiap ada perubahan, callback kepanggil
onValue(roomRef, (snapshot) => {
console.log("data berubah:", snapshot.val())
})

// Di client lain, tulis data:
push(roomRef, { text: "halo", user: "gue" })
// → semua subscriber langsung dapet event

onValue itu langganan. Tiap ada perubahan, callback kepanggil. Itu yang bikin chat app jadi gampang - gak perlu nyetup server WebSocket sendiri.

---

Kapan Firebase Realtime Bikin Hidup Lo Gampang

1. Chat & messaging.

Klasik. Lo subscribe room, lawan ngirim pesan, langsung muncul. Gak perlu socket.io, gak perlu nyetup WebSocket server sendiri.

2. Collaborative app.

Google Docs-style, kanban board realtime, Figma-lite. Multiple orang edit hal yang sama, perubahan langsung sinkron.

3. Live dashboard & presence.

"Siapa yang online sekarang?" - Firebase punya onDisconnect yang otomatis bersihin status pas user tutup tab. Buat indicator "user lagi ngetik..." juga gampang.

4. Game multiplayer ringan.

Posisi pemain sinkron. Tapi buat game competitive yang butuh latency < 50ms, Firebase kebanyakan overhead - pake custom WebSocket server (Go/Elixir) lebih cocok.

5. MVP kilat.

Waktu ngerjain side project, kadang lo cuma butuh "data masuk, data muncul di layar lain" tanpa mikir infrastruktur. Firebase pas banget.

---

Tapi Ada Sisi Gelap yang Gak Diceritain Landing Page

1. Cost meledak di scale.

Firebase nawarin free tier lumayan. Tapi begitu app rame, bill bisa naik gak terduga. Kenapa? Lo dibebanin per operasi baca/tulis, bukan per storage. Satu user buka list 1000 item = 1000 read. Realtime listener tiap reconnect = baca ulang. Gue pernah liat startup kena bill $2000/bulan padahal baru 5000 user - karena desain database-nya gak efisien.

2. NoSQL-nya bikin sakit kepala pas query kompleks.

Firestore & Realtime Database dua-duanya NoSQL. Lo harus model data untuk query, bukan model data yang natural. Mau query "artikel kategori X, bulan Y, urut view"? Sering harus duplikasi data atau bikin index manual. Kalau lo terbiasa SQL, ini mental model yang beda.

3. Vendor lock-in keras.

Business logic lo nempel di SDK Firebase. Mau pindah ke Postgres + WebSocket sendiri? Rewrite hampir semua data layer. Auth pake Firebase? Migrasi akun user ribet - gak bisa export hash password langsung.

4. Query limit.

Firestore: max 50 composite index (gratis), query IN max 30 value. Realtime Database: filter cuma 1 level, gak bisa WHERE a = X AND b = Y secara native. Buat aplikasi yang datanya relational, ini nyangkut terus.

5. Cloud Functions cold start.

Banyak yang complain Cloud Functions Firebase cold start 3-5 detik buat function yang jarang dipanggil. Kalau lo pake buat webhook payment, user nunggu 5 detik = bad UX.

---

Kenapa Blog Ini Pakai Supabase, Bukan Firebase?

Ini pertanyaan jujur. Gue ngebandingin dua-duanya pas mulai project ini.

| | Firebase | Supabase |
|---|---|---|
| Database | NoSQL (Firestore / RTDB) | PostgreSQL (relational, SQL penuh) |
| Realtime | Built-in, mature | Realtime via Logical Replication |
| Auth | Google, phone, dll | Email, Google OAuth, magic link |
| Self-host | ❌ Gak bisa | ✅ Bisa (open source) |
| Vendor lock-in | Tinggi | Rendah (Postgres standard) |
| Pricing | Per read/write | Per resource (RAM/bandwidth) |
| Free tier | Lumayan | Lumayan juga |

Alasan gue milih Supabase buat blog ini:

• Data blog itu relational (artikel punya author, kategori, komentar, affiliate link). SQL jauh lebih natural buat query ini.
• Gue pengen bisa pindah kalau suatu hari Supabase naikin harga atau gak fit. Pake Postgres, gue bisa pg_dump dan pindah server lain.
• Blog gak butuh realtime sync (kecuali comment, dan itu gue solve pake polling 30 detik sederhana).

Tapi kalau gue bikin chat app atau collab editor besok, Firebase tetep opsi kuat. Tools yang beda buat masalah yang beda.

---

Kapan Lo Harus Pakai Firebase

• Lo bikin chat / messaging app dan gak mau nyetup WebSocket server sendiri
• Lo butuh presence (siapa online) cepet
• Lo bikin MVP yang harus jadi dalam 1 minggu
• Tim lo gak punya backend engineer, dan frontend dev harus handle semua
• App lo NoSQL-friendly (data hierarchical, document-oriented)

Kapan Lo JANGAN Pakai Firebase

• Data lo relational banyak (multi-join, transaksi, constraint)
• Lo butuh query kompleks dengan filter gabungan
• Lo bisa kena bill gede karena traffic read tinggi (dashboard analytics, news feed)
• Lo mikir "mungkin pindah server sendiri nanti" - vendor lock-in Firebase keras banget
• Lo butuh full control atas database (Postgres extension, custom function, dll)

---

Penutup yang Jujur

Firebase itu alat yang powerful buat kategori tertentu (chat, collab, MVP kilat). Tapi bukan silver bullet. Realtime-nya keren, tapi NoSQL-nya bikin susah pas data lo relational. Pricing model-nya bisa ngejut, dan vendor lock-in-nya keras.

Gue pake Firebase buat 2 project (1 chat app, 1 collab tool kecil) - dua-duanya cocok. Gue gak pake buat blog ini karena datanya relational dan gue butuh SQL.

Pilih tool sesuai masalah, bukan karena yang lagi hype di Twitter. Kalau lo butuh realtime + NoSQL + deploy cepet → Firebase. Kalau lo butuh SQL + kontrol + portable → Supabase. Kalau lo butuh dua-duanya → pake Postgres + library realtime sendiri, dan terima kompleksitasnya.