C:\ARDI\NOTES> type offline-first.txt

Offline-first is three layers, not one

Offline-first itu tiga lapisan, bukan satu

Lessons from building a point-of-sale app that keeps selling when the internet drops. "Add a service worker" is the easy third; the other two are where sales get lost.

Pelajaran dari membangun aplikasi kasir yang tetap jualan saat internet putus. "Tambahkan service worker" hanya sepertiga yang mudah; dua sisanya adalah tempat penjualan bisa hilang.

01 The service worker: keep the app openingService worker: supaya aplikasi tetap terbuka

It precaches the JavaScript, CSS, fonts and icons, and caches some API reads. But the pages themselves were rendered on the server, so no HTML was cached: moving between pages worked offline, while pressing refresh on most pages did not. Know exactly what your cache contains before you promise "works offline".

Service worker menyimpan JavaScript, CSS, font, dan ikon, serta menyimpan sebagian hasil baca API. Tapi halamannya dirender di server, jadi tidak ada HTML yang tersimpan: pindah halaman tetap jalan saat offline, tapi menekan refresh di kebanyakan halaman tidak. Pahami persis isi cache sebelum menjanjikan "bisa offline".

02 The queue: never lose a saleAntrean: jangan pernah kehilangan penjualan

• An offline cash sale is written to IndexedDB, and the cart is cleared so the cashier can keep going.
• A queued sale is deleted only after the server confirms it, so a sync that fails halfway loses nothing.
• The sale keeps its original time when it syncs (and the server rejects times in the future), so last night's sale is not reported as today's.

• Penjualan tunai saat offline ditulis ke IndexedDB, lalu keranjang dikosongkan supaya kasir bisa lanjut.
• Penjualan di antrean baru dihapus setelah server mengonfirmasi, jadi sinkronisasi yang gagal di tengah tidak menghilangkan apa pun.
• Penjualan tetap memakai waktu aslinya saat tersinkron (dan server menolak waktu di masa depan), jadi penjualan semalam tidak tercatat sebagai penjualan hari ini.

03 Connection detection: know when to flushDeteksi koneksi: tahu kapan mengirim

The browser's online and offline events show a banner and trigger the queue as soon as the connection returns. It is the simplest layer, and the least reliable alone, which is why the queue must be safe to retry.

Event online dan offline dari browser menampilkan banner dan memicu pengiriman antrean begitu koneksi kembali. Ini lapisan paling sederhana dan paling tidak bisa diandalkan sendirian, karena itu antreannya harus aman untuk dikirim ulang.

! What I would add nextYang akan saya tambahkan berikutnya

• An idempotency key on every queued sale, so a sale whose reply was lost cannot be saved twice.
• One database transaction per sale instead of several writes with manual rollbacks.
• Decide which payments may go offline. Cash can; a bank transfer needs to be verified, so it stays online-only.

• Kunci idempoten di setiap penjualan dalam antrean, supaya penjualan yang balasannya hilang tidak tersimpan dua kali.
• Satu transaksi database per penjualan, bukan beberapa penulisan dengan rollback manual.
• Tentukan pembayaran mana yang boleh offline. Tunai boleh; transfer bank harus diverifikasi, jadi tetap harus online.

Full story in the Aponk Red POS case study.

Cerita lengkapnya ada di case study Aponk Red POS.