Offline-first uygulama: önce yerel veri, sonra senkronizasyon
Offline-first, uygulamanın önce cihazdaki yerel veriyle çalıştığı, ağı ise senkronizasyon için kullandığı mimaridir. Çalışma mantığı ve çakışma çözümü burada.
Offline-first mimari nedir?
Offline-first (çevrimdışı öncelikli) mimari, bir uygulamanın internet bağlantısını istisna değil, kesintili bir durum olarak ele alan tasarım yaklaşımıdır. Uygulama okuma ve yazma işlemlerini önce cihazdaki yerel veritabanına yapar; sunucuyla konuşmak ise arka planda, bağlantı uygun olduğunda gerçekleşen ayrı bir iştir.
Bu yüzden kullanıcı asansörde, sahada, uçakta ya da zayıf kapsama alanında olsa bile ekran donmaz, form kaybolmaz. Bağlantı geri geldiğinde yapılan değişiklikler sunucuya iletilir, sunucudaki yenilikler de cihaza iner.
Klasik çevrimiçi uygulamadan farkı
Klasik bir mobil uygulama her ekranda sunucuya istek atar ve cevap gelene kadar bekler. Bağlantı kesilirse hata mesajı görürsünüz. Önbellek kullanan uygulamada ise yalnızca daha önce açılmış ekranlar okunabilir; yazma yine bağlantıya bağlıdır.
Offline-first yaklaşımda yerel veritabanı geçici bir kopya değil, uygulamanın asıl çalışma alanıdır. Ekran her zaman yerel veriyi gösterir, sunucu ise ortak gerçeğin tutulduğu ve cihazlar arasında dağıtım yapan merkezdir. Aynı fikir, web tarafında servis çalışanı (service worker) ve yerel depolama ile kurulan çevrimdışı çalışan web uygulamalarında da geçerlidir.
Temel bileşenler
Bir offline-first uygulama genellikle şu parçalardan oluşur:
- Yerel depo: SQLite benzeri bir veritabanı ya da nesne deposu. Sorgulanabilir, indekslenebilir ve uygulama kapanınca da duran veri tutar.
- Giden işlem kuyruğu (outbox): Kullanıcının çevrimdışıyken yaptığı her değişiklik, sunucuya gönderilmek üzere sırayla bu kuyruğa yazılır.
- Senkronizasyon katmanı: Bağlantı gelince kuyruğu boşaltır, sunucudaki değişiklikleri çeker ve yerel depoyu günceller.
- Çakışma çözümü: Aynı kayıt hem cihazda hem sunucuda değiştiyse hangisinin geçerli olacağını belirleyen kural.
- Durum göstergesi: Kullanıcıya verinin eşitlenip eşitlenmediğini gösteren arayüz ögesi.
Senkronizasyon ve çakışma nasıl çözülür?
Her seferinde tüm veriyi indirmek pahalıdır; bu yüzden senkronizasyon protokolleri genellikle son eşitlemeden bu yana değişenleri taşır. Sunucu bir sürüm numarası ya da imleç (cursor) verir, cihaz bir sonraki istekte bunu geri gönderir ve yalnızca farkı alır.
Çakışma ise farklı kullanıcılar ya da cihazlar aynı kaydı çevrimdışıyken değiştirdiğinde ortaya çıkar. En yaygın stratejiler şunlardır: son yazan kazanır, alan bazında birleştirme, sunucunun kararı geçerli sayması ve çakışmayı kullanıcıya soran manuel çözüm. Eşzamanlı düzenlemeyi matematiksel olarak birleştirmeye dayanan CRDT gibi veri yapıları da ortak notlar ve belgeler için kullanılır.
Kuyruktaki bir işlem ağ hatası yüzünden birden fazla kez gönderilebileceği için sunucu uçlarının tekrar gelen isteği yok sayabilmesi, yani idempotent olması gerekir.
Örnek senaryo
Örneğin bir saha servis ekibi, bodrum katında ya da kırsalda arıza kaydı dolduruyor. Teknisyen formu, fotoğrafları ve kullanılan parçaları cihaza kaydeder; uygulama bunları kuyruğa alır ve ekranda bekleyen işlem simgesi gösterir. Teknisyen ofise döndüğünde telefon ağa bağlanır, kayıtlar sırayla sunucuya gider ve simge kaybolur.
Aynı iş emrini ofisteki bir yönetici de düzenlediyse çakışma kuralı devreye girer: örneğin yönetici adres alanını, teknisyen ise iş notunu değiştirdiyse alan bazında birleştirme ikisini de korur.
Sık yapılan hatalar
En sık hata, çevrimdışı desteği sonradan eklemeye çalışmaktır. Veri modeli ve ekran akışları sunucu cevabı varsayımıyla kurulduysa sonradan uyarlamak neredeyse baştan yazmak kadar zordur.
Diğer tipik hatalar: çakışma kuralını hiç tanımlamamak, kayıt zamanını cihaz saatine güvenerek belirlemek, kuyruktaki işlemlere kimlik vermeyip tekrar gönderimde çift kayıt üretmek, kullanıcıya eşitleme durumunu göstermemek ve uygulama sürümü değişince yerel veritabanı şemasını taşımayı unutmak. Test aşamasında uçak modu, kesintili bağlantı ve yavaş ağ senaryolarını bilinçli denemek gerekir.
Mindset programlarında nerede işlenir?
Mindset'in Mobil Uygulamada Çevrimdışı (Offline-First) Mimari eğitimi bu konuyu çevrimdışı öncelikli mimari temelleri, yerel depolama ve veri modeli, giden işlem kuyruğu, senkronizasyon protokolü, çakışma tespiti ve çözümü, kullanıcı deneyimi ile test ve izleme başlıklarıyla ele alır.
İlgili Mindset programı
Mobil Uygulamada Çevrimdışı (Offline-First) Mimari
Sık sorulan sorular
Offline-first ile çevrimdışı mod aynı şey mi?
Tam olarak değil. Çevrimdışı mod, bağlantı yokken bazı işlevleri sınırlı biçimde sunan bir ek özelliktir. Offline-first ise tasarımın merkezidir: yerel veri asıl çalışma alanı olur, sunucu ise sonradan eşitlenen taraftır. Bu fark, veri modelinden çakışma kurallarına kadar mimarinin tamamını etkiler.
Her uygulamanın offline-first olması gerekir mi?
Hayır. Anlık fiyat teklifi, canlı borsa ekranı ya da ödeme onayı gibi sonucu yalnızca sunucunun bildiği işlemlerde çevrimdışı çalışmak anlamsızdır. Offline-first; saha işleri, not ve görev uygulamaları, form toplama gibi bağlantının güvenilmez olduğu ve kullanıcının işini kesmemesi gereken senaryolarda değer üretir.
Çakışmalar tamamen önlenebilir mi?
Önlenemez, yalnızca yönetilebilir. Aynı kaydı farklı taraflar bağımsız değiştirebildiği sürece çakışma doğar. Yapılacak şey, kayıtları alan düzeyinde bölmek, çakışmayı hızlı tespit etmek ve iş kuralına uygun bir çözüm stratejisi seçmektir. Önemli kayıtlarda kararı kullanıcıya bırakmak da geçerli bir tasarımdır.
Offline-first kullanıcı deneyimini nasıl değiştirir?
Ekranlar bekleme göstergesi olmadan açılır, işlemler anında tamamlanmış görünür ve bağlantı koptuğunda kullanıcı işini yarıda bırakmaz. Karşılığında uygulama, verinin henüz sunucuya ulaşmadığını belirten açık bir durum göstermeli ve başarısız eşitlemeleri kullanıcıyı yormadan yeniden denemelidir.