Tujuan Pembelajaran

Memahami strategi sinkronisasi: last-write-wins, CRDT, version-based
Mampu mengimplementasikan sync dengan WatermelonDB
Mengerti cara resolusi konflik saat data berubah di dua tempat

Analogi

Diagram


      Sync = Dua Orang Edit Dokumen yang Sama:
- Kamu edit paragraf 1 offline → device punya versi A
- Teman edit paragraf yang sama online → server punya versi B
- Pas sync → KONFLIK! Mana yang benar?

Last-write-wins: yang terakhir edit, menang (simple, data bisa hilang)
Version-based: bandingkan version number, merge manual (kompleks, data aman)

Sync seperti dua orang edit dokumen yang sama — harus ada strategi siapa yang menang saat konflik. Simple vs safe.

Penjelasan Konsep

Offline-first apps butuh strategi sync. Saat user edit data di dua device atau saat offline lalu server juga berubah — bagaimana menyatukannya?

Strategi: (1) Last-write-wins (LWW) — data dengan timestamp terbaru yang menang. Simple tapi data bisa hilang. Cocok untuk: preferensi user, profile settings. (2) Version-based — setiap record punya version number. Saat sync, bandingkan version. Kalau berbeda → konflik → merge manual atau keep both. (3) CRDT (Conflict-free Replicated Data Types) — struktur data matematis yang auto-merge tanpa konflik. Kompleks implementasi. (4) Event sourcing — semua perubahan adalah event. Replay events untuk rekonstruksi state.

WatermelonDB sync: (1) Pull: server kirim perubahan sejak last sync timestamp. (2) Push: client kirim local changes (created, updated, deleted records). (3) Conflict detection: server bandingkan updatedAt. (4) Resolution: return server version ke client.

Offline-first sync checklist: (1) Track sync status per record (syncing, synced, error). (2) Progress UI — user harus tahu berapa data yang belum sync. (3) Retry exponential backoff. (4) Handle large initial sync — pagination. (5) Conflict UI — kalau ada konflik yang tidak bisa auto-resolve, libatkan user.

Inti yang Perlu Dipahami

Bagian ini berfokus pada memahami strategi sinkronisasi: last-write-wins, CRDT, version-based., mampu mengimplementasikan sync dengan WatermelonDB., dan mengerti cara resolusi konflik saat data berubah di dua tempat. Jangan terburu-buru menghafal istilahnya. Lebih penting untuk memahami peran setiap konsep dan kapan konsep itu muncul dalam pekerjaan web development.

Saat membaca Sync Strategy & Conflict Resolution, gunakan tujuan belajar sebagai penanda arah. Kalau kamu sudah bisa menjelaskan tujuan itu dengan kata-katamu sendiri, berarti fondasinya mulai terbentuk.

Cara Membayangkannya

Sync seperti dua orang edit dokumen yang sama — harus ada strategi siapa yang menang saat konflik. Simple vs safe. 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.

Saat Melihat Contoh Kode

Contoh kode pada chapter ini memakai bahasa tsx. Bacalah contoh kode sebagai ilustrasi alur, bukan sebagai bagian yang harus langsung dihafal. Pull dulu (dapatkan perubahan server), baru push local changes. Timestamp-based sync — hanya kirim data yang berubah sejak sync terakhir.

Perhatikan nama fungsi, urutan langkah, dan data yang berpindah. Biasanya tiga hal itu sudah cukup untuk memahami hubungan antara teori dan praktik.

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.

Contoh Kode

tsx

async function syncData(lastSyncTimestamp: number) {
  const changes = await pullChanges(lastSyncTimestamp);
  await applyRemoteChanges(changes);
  const localChanges = await getLocalChanges(lastSyncTimestamp);
  await pushChanges(localChanges);
  const newTimestamp = Date.now();
  storage.set("lastSync", newTimestamp);
  return { pulled: changes.length, pushed: localChanges.length };
}

Penjelasan Kode

Pull dulu (dapatkan perubahan server), baru push local changes. Timestamp-based sync — hanya kirim data yang berubah sejak sync terakhir.

Prompt AI

Desain sync strategy untuk aplikasi notes: user bisa edit note di device A (offline) dan device B (online). Bagaimana mendeteksi dan resolve konflik kalau note yang sama diedit berbeda di dua device?

Pertanyaan Reflektif

Apa skenario terburuk dari data loss di aplikasimu? Apakah last-write-wins cukup, atau butuh strategi resolusi yang lebih kompleks?