Local-first uygulamalar neden yaygınlaşmadı?

• Local-first uygulamalar, hızlı tepki süresi ve varsayılan gizlilik vaat eder; ancak pratikte çevrimdışı desteği uygulamak son derece zordur.
• Bunun en büyük nedeni senkronizasyonun karmaşıklığıdır; birden fazla cihazda veri aynı anda değiştirildiğinde sonuçta tam olarak aynı duruma yakınsaması gerekir.
• Burada iki büyük teknik zorluk vardır:
  • zaman sırasının belirsizliği
  • çakışmalar
• Bu sorunu çözmek için Hybrid Logical Clocks(HLCs) ve CRDTs gibi dağıtık sistem tasarımlarının uygulanması gerekir.
• SQLite tabanlı genişletmeler kullanılarak güvenilir ve basit bir senkronizasyon mimarisi sunulabilir ve bu mimari tüm platformlarda kullanılabilir.

---

Çevrimdışı-first uygulamaların vaadi ve gerçeği

• Çevrimdışı-first uygulamalar; anında tepki, varsayılan gizlilik ve istikrarsız ağ koşullarında bile yükleme beklemeden kullanım vaat eder.
• Gerçekte ise çoğu uygulama çevrimdışı desteğini düzgün biçimde uygulayamaz; büyük kısmı yalnızca değişiklikleri yerelde geçici olarak saklayıp ağ bağlantısı geldiğinde göndermeyi tercih eder.
• Bu tür uygulamalar güvenilir değildir ve sonunda "değişiklikler kaydedilmeyebilir" gibi uyarı mesajlarına yol açar.

Senkronizasyonun temel zorluğu

• Bir local-first uygulama geliştirirken kaçınılmaz olarak bir dağıtık sistem kurmuş olursunuz.
• Birden fazla cihaz çevrimdışıyken birbirinden bağımsız olarak veriyi değiştirebilir ve daha sonra yeniden bağlandıklarında aynı duruma doğru biçimde yakınsamaları gerekir.
• Bunun için iki büyük zorluk vardır:
  • olayların sırasındaki belirsizlik
  • aynı veri üzerindeki çakışmalar

1. Olay sırasının belirsizliği

• Birden fazla cihazda olaylar farklı zamanlarda gerçekleşir ve sıraya bağlı olarak durum değişebilir.
  • Örnek: A cihazı x=3 olarak ayarlar, B cihazı x=5 olarak ayarlar → her biri çevrimdışıyken değişiklik yaparsa, senkronizasyon sırasında farklı sonuçlar ortaya çıkabilir.
• Geleneksel merkezi veritabanları bunu güçlü tutarlılık ile çözer; ancak bu, küresel senkronizasyon gerektirdiği için local-first sistemlere uygun değildir.
• Sonuç olarak her olay için uygun sıranın, dinamik ve dağıtık bir ortamda da kesinleştirilmesi gerekir; bunu merkezi bir saat olmadan yapmanın bir yolu gereklidir.

Hybrid Logical Clocks(HLCs) kullanımı

• Hybrid Logical Clocks(HLCs), ayrı cihazlar arasında olay sırası üzerinde fiilen uzlaşmayı sağlayan basit ama etkili bir algoritmadır.
• HLC, fiziksel zaman bilgisi ile mantıksal sayacı birleştirerek çalışır.
• Örneğin:
  • A cihazı bir olayı 10:00:00.100 anında kaydederse HLC değeri (10:00:00.100, 0) olur.
  • Mesajı alan B cihazının saati geri kalsa bile HLC değerini (10:00:00.100, 1) seviyesine çıkarır.
  • Böylece iki cihazın fiziksel saatleri arasındaki farktan bağımsız olarak olayların doğru sırası belirlenebilir.

2. Çakışma sorunu

• Doğru sırayı uygulamak tek başına yeterli değildir; farklı cihazlar aynı veriyi bağımsız biçimde değiştirdiğinde çakışmalar kaçınılmaz olarak ortaya çıkar.
• Çoğu sistem geliştiricinin çakışma çözüm kodunu elle yazmasını ister; bu da hata riskini ve bakım yükünü artırır.

CRDTs kullanımı

• En iyi yaklaşım Conflict-Free Replicated Data Types(CRDTs) kullanmaktır.
• CRDTs, senkronizasyon hangi sırayla yapılırsa yapılsın ya da aynı işlem tekrar uygulanırsa uygulansın, her cihazın durumunun sonunda aynı olmasını garanti eder.
• En basit CRDT stratejisi Last-Write-Wins(LWW) yaklaşımıdır.
  • Her güncellemeye bir zaman damgası verilir.
  • Senkronizasyon sırasında daha yeni zaman damgasına sahip değer seçilir.

SQLite'ın avantajları

• Bir local-first uygulama kurarken güvenilir ve hafif bir yerel veritabanı zorunludur ve SQLite en iyi seçimdir.
• SQLite tabanlı framework genişletmeleriyle senkronizasyon işlevi uygulanırsa şu avantajlar elde edilir:
  • Mesaj uygulama süreci basittir: mevcut değeri oku → yeni zaman damgası daha yeniyse üzerine yaz → değilse yok say.
  • Bu yöntem, senkronizasyon sırasından bağımsız olarak tüm cihazlarda durumun yakınsamasını garanti eder.

Mimarinin önemi

• Bu yapı basit ve güvenilir senkronizasyonu mümkün kılar.
  • Haftalar boyunca çevrimdışı kalınsa bile veri kaybı olmadan güvenilirlik
  • Her zaman nihai duruma yakınsayan deterministik yapı
  • Ağır bağımlılıklar olmadan yalnızca hafif bir SQLite genişletmesi ile çözüm
  • iOS, Android, macOS, Windows, Linux, WASM gibi tüm büyük platformların desteği

Geliştiricilere öneri

• Basit bir istek kuyruğuyla çevrimdışı modu sadece 'taklit eden' yaklaşımdan kaçınmak gerekir.
• Eventual consistency kavramını benimseyip HLC ve CRDT gibi kanıtlanmış dağıtık sistem tekniklerinden yararlanmak gerekir.
• Büyük ve karmaşık framework'ler yerine küçük ve bağımlılıksız yapılar tercih edilmelidir.
• Sonuçta uygulamalar anında çalışma, çevrimdışı kullanım, varsayılan gizlilik gibi avantajlardan yararlanabilir.

Açık kaynak SQLite-Sync notu

• Üretimde hemen kullanılabilecek, çapraz platform bir çevrimdışı-first motorla ilgileniyorsanız açık kaynak SQLite-Sync genişletmesine göz atabilirsiniz.

[GN⁺]

Hacker News görüşleri

• CRDT’ler (Conflict-Free Replicated Data Types) çözüm gibi sunuluyor ama pratikte sezgisel kullanıcı beklentileriyle tutarlı iş mantığını aynı anda karşılayan bir CRDT modeli kurmak gerçekten çok zor; ayrıca veri modelini mesaj demetlerine çevirip bunu sürekli gerçek duruma yeniden kurmak gerektiği için büyük bir baş ağrısı
  • BRAID adında yeni bir web standardı girişimi var. Bu girişim, web durum senkronizasyonu standardını hedefliyor; operational transform (OT) ve CRDT tekniklerini HTTP’ye uygulayarak özünde hem insanlar hem makineler için daha dostane bir senkronizasyon web’i oluşturmayı amaçlıyor. Braid, ağ performansını artırıyor ve yerel öncelikli web uygulamaları, doğal P2P ve ortak düzenleme geliştirmesini destekliyor. İlgili bağlantılar: BRAID toplantısı, Braid HN tartışması, RESTful API tartışması, Braid HTTP açıklaması
  • CRDT konuşması sanki her derde deva bir çözüm gibi yapılıyor ama gerçekte otomatik birleştirme o kadar kolay değil. Teknik olarak son yazanın kazandığı algoritmalar da bir CRDT sayılabilir, ancak karmaşık metin birleştirmelerinde hem kullanıcı niyetine hem de beklentilere saygı göstermek neredeyse imkânsıza yakın bir problem. Hatta bazı durumlarda CRDT ile birleştirmeye çalışmak baştan yanlış yaklaşım bile olabilir. Örneğin toplantı odası rezervasyonunda iki kişi aynı anda aynı odayı ayırıyorsa, bunu bir algoritmanın değil kullanıcının fark edip çözmesi gerekir
  • Bunun çekingenlerin kolay giremeyeceği bir alan olduğuna katılıyorum. Cesareti olmayanlar için “CRDT’siz” alternatifler de var; ilgili içerik için buraya bakılabilir
  • Ekibimiz yerel öncelikli uygulamalar geliştirirken çatışma durumlarını basitçe görmezden geliyor. Son değişiklik kazanıyor. Çatışmaların çoğu ya önemsiz oluyor ya da (örneğin denetim kayıtlarıyla) kolayca çözülebiliyor; ayrıca çoğu zaten otomatik olarak çözülebilecek türden değil. Örneğin çevrimdışı destekli bir görev takip uygulamasında iki kişinin aynı anda aynı işe başlaması, iş süreciyle ayrıca ele alınmalı
• Eskiden neredeyse tüm yazılımlar yerel öncelikliydi ve bu gayet normaldi. Ama bugün dünya tamamen kontrol ve kâr optimizasyonuyla işliyor; bunun sonucu olarak da insanların daha sık zarar gördüğü bir yapıya dönüştü. Memnun kalmasalar bile gerçek bir alternatif yok
  • Eskiden şirket içi kurulum ve self-hosting ürünleri yaptığımız dönemde, müşterilerden aldığımız en büyük şikâyet bulut seçeneğinin olmamasıydı. Çoğu şirket kendi başına barındırmak istemiyor; aylık ücret ödeyip bunu başkasına bırakmayı tercih ediyor. HN’nin bulut hizmetlerine yönelik gerçek talebi küçümsediğini düşünüyorum
  • “İnsanlar daha az sömürülen hizmetler isterse bundan para kazanılabilir” iddiası ekonomik açıdan pek doğru değil. Sorun şu ki insanlar gerçekte belirli ölçüde bu zararı kabulleniyor. Eğitim ya da risk farkındalığı artsa tablo değişebilir ama bunun çözülmesi çok zor bir mesele olduğunu düşünüyorum
  • Alternatif olarak FOSS (özgür ve açık kaynak yazılım) düşünülebilir
• Uygulamaların tüm içeriği sadece çevrimiçi duruma bağlamamasını isterdim. Tesla GPS bile önceden indirilmiş karo verilerini önbelleğe almıyor; bu yüzden çevrimdışıyken haritada hiçbir şey görünmüyor. Peacock ve Kanopy gibi uygulamalar da medya listesini ya da işlenmiş nesneleri cihazda tutmuyor. Cihazda zaten içeriğin %95’i mevcut; bunun daha etkin kullanılmasını isterdim. Arayüzü dirty olarak işaretleyip eşzamansız kaydetme işleminin başarıyla tamamlanmasını beklemek yeterli. Çevrimdışı uygulama tasarımında büyük değişiklikler gerekmiyor; sadece daha iyi alışkanlıklar olsa sorunların çoğu kolayca çözülebilir
  • API yanıtlarında Cache-Control doğru kullanılıp ağ katmanında buna uyulunca pek çok sorun çözülüyor. Böylece sunucuda önbellek süresi değişse bile uygulamayı güncellemeden bu hemen uygulanabiliyor
  • Google Maps’te çevrimdışı haritalar için alanı elle seçip indirebiliyorsunuz, ayrıca aynı anda birden fazla bölgeyi de önbelleğe alabiliyorsunuz. Milli park ziyaretlerinde bunu çevrimdışı gayet iyi kullandım
  • “Uygulama tasarımını değiştirmeye gerek yok” görüşüne karşı, şirketlerin asıl amacının daha fazla veri toplamak olduğunu düşünüyorum. Örneğin Apple da çevrimdışı haritalar sundu ama verileri bilerek süresi dolacak şekilde ayarlayıp kullanıcıyı kendine bağımlı kılmaya çalışıyor. Tesla’nın (veya Google’ın) harita karolarında da benzer gizli niyetler olduğunu tahmin ediyorum
• Uygulamaların yerel öncelikli ya da dağıtık olması gibi “politik olarak sıcak” konulara odaklanılırken, insanların gerçekten istediği temel değer önerisinin kaçırıldığı çok oluyor
  • Immich’e geçerken self-hosting yüzünden bir şeylerden vazgeçeceğimi sanmıştım ama Apple ya da Google’dan çok daha iyi olduğuna şaşırdım. Tek boynuzlu at gibi nadir görülen bir ürün
• Yerel öncelikli uygulamaların popüler olmamasının nihayetinde ekonomik bir mesele olduğunu düşünüyorum. SaaS ya da reklam tabanlı modeller sağlam şekilde yerleşmiş durumda ama yerel öncelikli uygulamalar belirgin biçimde daha az kârlı. Bu modeli tercih eden insanlar veri egemenliği, uçtan uca şifreleme ve çevrimdışı kullanım gibi mevcut gelir modelleriyle çelişen özelliklere önem veriyor. Sonunda geriye açık kaynak topluluğunun tutkusuna dayanmak kalıyor
  • Artık ya “para + veri” veriyorsunuz ya da “reklam izliyorsunuz”; sadece gerçek para ödeyip verinizi koruyabildiğiniz model dışlanmış durumda
  • Ben de Relay adında yerel öncelikli bir uygulama geliştiriyorum; Obsidian’a Google Docs tarzı ortak çalışmayı ekliyor. İş modelinin ilginç olduğunu düşünüyorum. Hizmet “küresel kimlik katmanı” ve “Relay Server” (açık kaynak/self-hosting) olarak ayrılıyor; böylece kullanıcılar belge içeriği üzerinde tam denetime sahip oluyor. Basit bir tek oturum açma ve yetki yönetimi sağlıyor; özellikle yapay zeka ve AI Safety alanındaki şirketler ile uyumluluğun önemli olduğu firmalardan ilgi görüyor. Bağlantı: Relay.md
  • Çevremde sık gördüğüm bir şey de şu: satın alma anında yalnızca abonelik sunulunca insanlar sonunda hiç satın almıyor. İnsanlar önce satın alıp sonra istedikleri zaman kullanmak istiyor ama süreli indirim ya da geri dönünce fiyatın artması gibi koşullar yüzünden satın alma isteği tamamen kırılıyor. Bunun en iyi iş modeli olduğunu düşünmüyorum
  • Sorunun kopyalanmış veri yapıları olduğunu sanmıyorum. Tek oyunculu oyunlar gibi tamamen yerel öncelikli yazılımlarda bile çoğu zaman launcher üzerinden internet bağlantısı isteniyor
  • Yerel öncelikli uygulamalarda karmaşıklık sorunu da ciddi. Her türlü cihazda ve ortamda çalışması gerekiyor; bulut öncelikli uygulamalarda ise tek bir sunucu ortamına odaklanmak yettiği için iş görece daha kolay ve bakım maliyeti daha düşük
• Geçmişte masaüstü ve mobil yazılımlar sanki tuhaf bir istisnaymış gibi görülüyordu ama bunlar hâlâ çok yaygın yazılım dağıtım biçimleri. Buna karşılık tarayıcıda yerel öncelikli özellikler uygulamaya çalışınca, ana sistemle entegrasyon gibi tarayıcının tüm dezavantajlarını da üstlenmiş oluyorsunuz
• Bir şeyi kaçırıyor olabilirim ama genel olarak “yerel öncelikli” uygulamaların zaten sıradan olduğunu düşünüyorum. Çoğu kullanıcı da çok sayıda çevrimdışı temelli uygulama kullanıyor. Eğer kastedilen “yerel öncelikli web uygulaması” ise o zaman ifade daha doğru olabilir. Aslında “yerel öncelikli web uygulaması” kendi içinde çelişkili bir kavram
  • Çoğu uygulamanın gerçekten (doğrudan para ödenerek kullanılan) yerel öncelikli biçimde olup olmadığını sormak isterim. Oyunlar hariç artık böyle şirket neredeyse kalmadı; hatta tek oyunculu oyunlar bile DRM, hile önleme ya da güncelleme gibi gerekçelerle internet istiyor
  • Burada “yerel öncelikli” denirken kastedilen, bulut depolamayı temel almak yerine veriyi baştan yerelde tutan ve bulutla senkronizasyonu destekleyen uygulamalar
• Çevrimdışı öncelikli uygulamalar da kopuk ya da kararsız ağ bağlantılarında yükleme göstergesinin dönmesi bakımından çok farklı değil. Örneğin Google Docs, belgenin güncel olup olmadığını kontrol etmeye çalışırken takılıp kalıyor; ancak Uçak Modu’na alırsanız hemen açılıyor. Spotify da kaydedilmiş çalma listelerinde bile çevrimiçi ek bilgiler çekmeye çalışırken duraklıyor. Sonuçta kararsız bağlantılar çevrimdışı uygulama geliştirmedeki en büyük baş ağrısı; çünkü uygulamalar her zaman bir kez daha buluttaki veriye erişmeye çalışıyor
• Makaledeki çözüm de kapalı bulut tekliflerine kilitlenmiş durumda. Firebase gibi kendi başına iyi olabilir ama bunun açıkça belirtilmemesi ve “sadece bir sqlite uzantısı” gibi bir ifadeyle ticari bulut desteğinin gizlenmesi üzücü. PowerSync ya da ElectricSQL gibi sağlayıcılar en azından bu gerçeği şeffaf biçimde söylüyor; PowerSync ayrıca self-hosting imkânı da veriyor
  • Yerel öncelikli kavramın geliştirici araçlarına uygulanıp uygulanamayacağından emin değilim. SQLite-sync benzeri araçlarla yerel depolama modeli temelli yazılım geliştirmenin ne kadar mümkün olduğunu değerlendirmek gerekiyor gibi. ElectricSQL self-hosting destekliyor ve benim “sqlite sync” araç listemi de güncel tutmam gerekecek gibi duruyor. İlgili bağlantılar: local-first özgün yazı, SQLSync, SQLiteSync, SQLite-Sync
• Bence daha fazla yalnızca yerelde çalışan, self-hosted uygulamaya ihtiyaç var. Ya da federated yapı da iyi olabilir. Şimdiye kadar ağ altyapısının engel olduğunu düşünüyordum ama Tailscale gibi çözümler ortaya çıktıkça bu tür uygulamalar çok daha kolay hâle gelecek
  • Bir sunum yazılımı geliştiriyorum; yerelde kusursuz çalışması gerekiyor ama aynı zamanda her yerden erişilebilir de olmalı. Bu ikisini aynı anda sağlamak düşündüğümden daha zor. Yine de teknoloji geliştikçe direct connection ya da WebRTC gibi P2P uygulamaları kolaylaşıyor. Bunları gerçek ürüne entegre edip test etmek hâlâ zorlayıcı. Buna rağmen gelecekte hem yerel öncelikli hem de ağ yetenekleri güçlü daha fazla yazılım göreceğimizi düşünüyorum. Açık kaynak. Daha fazla bilgi için profile bakabilirsiniz
  • Ben de bu alanı son zamanlarda eğlenceli biçimde keşfediyorum. Ayrıntılar burada. Uygulama inşa etmenin yeni yolu oldukça keyifli geliyor bana