Yerel Öncelikli Yazılım: Bulut Çağında da Verilerinizin Sahibi Olmak (2019)

 (inkandswitch.com)
2 puan yazan GN⁺ 2025-07-06 | 1 yorum | WhatsApp'ta paylaş
  • Bulut uygulamaları iş birliğini ve çoklu cihaz erişilebilirliğini büyük ölçüde geliştirdi, ancak verilerin yetkili kopyası sunucuda bulunduğu için kullanıcının sahipliği ve denetimi zayıflıyor
  • Yerel öncelikli yazılım, dizüstü bilgisayar, tablet ve telefonlardaki yerel depolamayı ana veri kopyası olarak tutar; sunucuyu ise senkronizasyon ve yedeklemeye yardımcı olan ikincil bir rolle sınırlar
  • Bu yaklaşım hızlı yanıt, çevrimdışı çalışma, birden çok cihaz arasında senkronizasyon, gerçek zamanlı iş birliği, uzun vadeli koruma, varsayılan güvenlik ve gizliliği aynı anda hedefler
  • Dosyalar, e-posta, web uygulamaları, Dropbox benzeri senkronizasyon, Git, Firebase, CloudKit, Realm ve CouchDB’nin her biri bazı avantajlara sahip olsa da iş birliği ve veri sahipliğini birlikte tam olarak karşılamaz
  • CRDT ve Automerge tabanlı prototipler potansiyel gösterdi, ancak performans, ağ iletişimi, P2P kararlılığı ve dağıtık belge arayüzü gibi zorluklar sürüyor

Bulut İş Birliği ile Veri Sahipliğinin Çatışması

  • Google Docs, Figma, Slack ve Trello gibi bulut uygulamaları tarayıcı ya da mobil uygulama üzerinden erişilir ve verileri sunucuda saklar
  • Bu model gerçek zamanlı iş birliği ve her yerden erişim avantajı sağlar, ancak tüm veri erişiminin sunucudan geçmesi gerekir
    • Yalnızca sunucunun izin verdiği işlemler yapılabilir
    • Hizmet kesintiye uğrarsa yalnızca yazılıma değil, o yazılımla oluşturulan verilere erişim de engellenebilir
    • Veriler dışa aktarılabilse bile, aynı yazılımı sunucu olmadan çalıştırmaya devam etmek zordur
  • Buna karşılık eski yerel uygulamalar yerel diskteki dosyaları okuyup yazdığı için kullanıcı yedekleme, uzun süreli arşivleme, başka programlarla işleme ve silme üzerinde doğrudan denetime sahip olabilir
  • Temel gerilim, bulutun iş birliği, yerel uygulamaların ise sahiplik sunmasıdır; yerel öncelikli yaklaşım ikisini birlikte elde etmeye yönelik bir tasarım yönüdür

Yerel Öncelikli Yazılımın Temel Modeli

  • Yerel öncelikli yazılım, uzak veri merkezlerindeki sunuculardan çok yerel depolamaya ve yerel ağa öncelik verir
  • Bulut uygulamalarında sunucu verisi yetkili kaynak, istemcideki veri ise sunucuya bağlı bir önbelleğe daha yakındır
  • Yerel öncelikli uygulamalarda her cihazdaki yerel veri ana kopyadır; sunucu ise birden fazla cihazdan erişime ve yedeklemeye yardımcı olan ikincil bir kopya tutar
  • Bu bakış açısı değişimi performansı, çevrimdışı kullanımı, uzun vadeli korumayı, gizliliği ve kullanıcı denetimini doğrudan etkiler

Yerel Öncelikli Yaklaşımın 7 İdeali

  • 1. Dönen yükleme göstergesi olmadan anında çalışma

    • Bulut uygulamalarında veri değişiklikleri ve birçok sorgu sunucuyla gidiş-dönüş gerektirdiğinden gecikme oluşur
    • Optimistic UI, isteğin tamamlanmış gibi görünmesini sağlayarak gecikmeyi gizler; ancak ağ hatası olursa gecikme yeniden ortaya çıkar
    • Yerel öncelikli uygulamalarda ana veri yerel cihazda bulunduğu için kullanıcı girdisinin sunucu yanıtını bekleme ihtiyacı azalır
    • Senkronizasyon arka planda yürür ve uygulama girdilere neredeyse anında tepki verebilir

  • 2. Tek bir cihaza hapsolmayan çalışma

    • Kullanıcılar fikirleri akıllı telefonda yakalayıp tablette düzenleyerek ve dizüstü bilgisayarda belgeleyerek birden çok cihaz arasında gidip gelir
    • Yerel öncelikli uygulamalar da verileri her cihazda tutarken tüm çalışma cihazları arasında senkronizasyona ihtiyaç duyar
    • Cihazlar arası senkronizasyon hizmetlerinin çoğu, sunucuda da bir kopya saklayarak tesis dışı yedek işlevi görür
    • Birden fazla kişi aynı dosyayı aynı anda düzenlediğinde çakışmalar oluşabileceğinden iş birliği tasarımı önem kazanır

  • 3. Ağın isteğe bağlı olması

    • Uçaklar, tüneller, asansörler, otoparklar, kararsız WiFi, roaming ücretleri ve gelişmekte olan ülkeler ile kırsal bölgelerdeki eksik internet altyapısı, çevrimdışı çalışma ihtiyacını doğurur
    • Bulut uygulamaları genel olarak çevrimdışında zayıftır; sunucu merkezli bir modele sonradan çevrimdışı destek eklemek de zordur
    • Yerel öncelikli uygulamalar ana veriyi her cihazın yerel dosya sisteminde sakladığı için çevrimdışıyken de okunup yazılabilir
    • Daha sonra ağ kullanılabilir olduğunda diğer cihazlarla senkronize olur; senkronizasyon yalnızca internetle değil Bluetooth veya yerel WiFi ile de yapılabilir
    • İyi bir çevrimdışı deneyim için tarayıcı sekmesinden çok yerelde kurulu bir çalıştırılabilir dosya daha uygundur

  • 4. İş arkadaşlarıyla sorunsuz iş birliği

    • Eski yerel dosya tabanlı yazılımlarda birden fazla kişi aynı dosyayı aynı anda düzenlediğinde kolayca çakışma oluşur
    • Google Docs gibi bulut uygulamaları, birden çok kullanıcının aynı anda belge düzenleyip çakışmaları dert etmediği deneyimi yaygınlaştırdı
    • Yerel öncelikli yaklaşımın ideali, günümüzün en iyi bulut uygulamalarıyla aynı düzeyde veya daha iyi gerçek zamanlı iş birliğini desteklemektir
    • Bir kullanıcının değişiklik önermesi, başka bir kullanıcının da bunu inceleyip seçici biçimde uygulaması akışı da önemlidir
      • Google Docs’un suggesting mode’u
      • GitHub’ın pull request’i

  • 5. Long Now: uzun vadeli erişilebilirlik

    • Veri sahipliğinin önemli bir yönü, gelecekte de uzun süre erişilebilir olması gerektiğidir
    • Eski yerel uygulamalar, veriler ve çalıştırılabilir yazılım kopyası varsa kullanılmaya devam edebilir; eski işletim sistemleri veya bilgisayarlar da sanal makineler ya da emülatörlerle çalıştırılabilir
    • Depolama ortamı değişse bile dosyalar yeni ortama kopyalanabilir
    • Bulut uygulamaları hizmetin sunulmaya devam edeceği varsayımına dayanır; hizmetin kapanmasına, veri kaybına, fiyat ve özellik değişikliklerine, istenmeyen zorunlu yükseltmelere karşı kırılgandır
    • Yerel öncelikli yazılımda veriler ve bu verileri okuyup düzenleyen yazılım yerelde saklandığı için uzun vadeli koruma olasılığı artar
    • plain text, JPEG ve PDF’nin uzun süre okunabilir kalma olasılığı yüksektir; ABD Kongre Kütüphanesi de veri kümelerini koruma biçimleri olarak XML, JSON ve SQLite’ı önerir

  • 6. Varsayılan olarak güvenlik ve gizlilik

    • Bulut uygulamaları tüm kullanıcıların verilerini merkezi bir veritabanında topladığı için saldırganlar açısından cazip bir hedef olur
    • İç çalışanlar veya sunucuya erişen hacker’lar verileri okuyabilir ya da değiştirebilir; veri ihlalleri de yaygın bir risk olmaya devam eder
    • Google Drive şartları, otomatik sistemlerin kişiselleştirilmiş arama sonuçları ile spam ve kötü amaçlı yazılım tespiti için kullanıcı içeriklerini analiz ettiğini belirtir
    • Sağlık çalışanları, araştırmacı gazeteciler ve devlet ya da diplomasiyle ilgili kişiler gibi hassas verilerle çalışan kullanıcılar için bulut uygulaması kullanımı düzenleyici gereklilikler ve gizlilik yükümlülükleriyle çatışabilir
    • Yerel öncelikli uygulamalar her yerel cihazda yalnızca kullanıcının kendi verilerini saklayabilir; sunucuda ise yalnızca uçtan uca şifrelenmiş kopyalar bulundurabilir
    • iMessage, WhatsApp, Signal, Keybase ve Tarsnap; uçtan uca şifreleme ya da şifreli dosya paylaşımı ve yedekleme örnekleri olarak sunulur

  • 7. Nihai sahiplik ve denetim

    • Bulut uygulamalarında hizmet sağlayıcı kullanıcı erişimini kısıtlayabilir
    • Ekim 2017’de bazı Google Docs kullanıcılarının belgelere erişimi, otomatik sistemlerin belgeleri yanlışlıkla kötü amaçlı olarak işaretlemesi nedeniyle engellendi
    • Burada sahiplik, fikri mülkiyet hakkı değil; kullanıcının eyleme geçme yetisi, özerkliği ve verileri üzerindeki denetimi anlamına gelir
    • Yerel öncelikli yazılımda veriyi oluşturan baytlar kullanıcının cihazında bulunduğundan, bunları istediği şekilde işleme özgürlüğü vardır
    • Veri sahipliği; yedekleri sürdürme, veri kaybını önleme, fidye yazılımlarına karşı önlem alma ve dosya arşivlerini yönetme sorumluluğunu da beraberinde getirir
    • Yerel öncelikli yazılımın mutlaka açık kaynak olması gerekmez; ticari ve kapalı kaynak yazılımlar da dosya kullanımını yapay biçimde kısıtlamıyorsa bu ideale yaklaşabilir
    • Yapay kısıtlama örnekleri olarak yazdırmayı engelleyen PDF’ler, kopyala-yapıştırı zorlaştıran eBook okuyucular ve medya dosyası DRM’i gösterilir

Mevcut depolama ve paylaşım modellerinin sınırları

  • Dosyalar ve e-posta ekleri

    • Geleneksel dosyalar çevrimdışı görüntüleme ve düzenleme, kullanıcı denetimi, yedekleme, uzun vadeli saklama ve hızlı erişim açısından güçlüdür
    • Birden fazla cihazdan erişim için e-posta, USB, NAS/NFS/FTP/rsync, Dropbox türü dosya eşitleme ya da Git gibi yöntemler gerekir
    • E-posta ekleri anlaşılması kolay ve güvenilirdir; 6 ay sonra bile ek dosya ilk hâliyle durur
    • Zayıf noktası iş birliğidir
      • Genellikle bir dosyayı aynı anda yalnızca bir kişi düzenleyebilir
      • Birden fazla kişi düzenlerse elle birleştirme gerekir
      • Budget draft 2 (Jane's version) final final 3.xls gibi dosya adı karmaşası ortaya çıkar
    • Yerel öncelikli fikri uygulamak isteyen uygulamalar, işe plain text, PDF, PNG, JPEG gibi yaygın desteklenen biçimlere dışa aktarma sunarak başlayabilir

  • Web uygulamaları

    • Google Docs, Trello, Figma, Pinterest gibi web uygulamalarında tarayıcı ya da mobil uygulama ince istemcidir ve veri deposu sunucudadır
    • Web uygulamaları gerçek zamanlı iş birliğinin standardını belirledi; ekip çalışmasında en güncel sürümü her yerden görebilmek büyük bir avantajdır
    • Buna karşılık sahiplik ve denetim büyük ölçüde azalır
      • Esas alınan veri sunucudaki veridir; istemcideki veri daha çok önbelleğe yakındır
      • Ağ kısa süreliğine kesilse bile çalışmanın ortasında erişim engellenebilir
      • Google Docs offline plugin gibi sınırlı çevrimdışı destekler, sunucu merkezli mimariye sonradan eklenmiş çözümlere daha yakındır
    • Milanote ve Figma gibi kurulumlu masaüstü istemcileri de özünde yeniden paketlenmiş tarayıcılardır; ağ arızası, sunucu kesintisi ya da hizmetin kapanması durumlarında sınırları ortaya çıkar

  • Dropbox, Google Drive, Box, OneDrive

    • Dropbox, Google Drive, Box, OneDrive masaüstünde belirlenen klasörü izler ve değişen dosyaları başka bilgisayarlara kopyalar
    • Yerel dosya sistemi kullanıldığı için hızlıdır, çevrimdışı çalışmaya olanak tanır; eşitleme hizmeti sona erse bile yerel diskteki dosyalar kalır
    • Sabit disk arızası yaşanırsa uygulamayı kurup eşitlemenin tamamlanmasını bekleyerek geri yükleme yapılabilir; bu da uzun ömürlülük ve denetim açısından avantaj sağlar
    • Mobil iOS ve Android’de ise tüm klasörü eşitlemek yerine dosyaları sunucudan tek tek getiren ince istemci modeline daha yakındır
    • “Make available offline” seçeneğinin önceden belirlenmesi gerekir, zahmetlidir ve yalnızca uygulama açıkken çalışır
    • En zayıf noktası gerçek zamanlı iş birliğidir
      • Aynı dosya iki cihazda düzenlenirse elle birleştirme gerektiren çakışmalar oluşur
      • Keyfî dosya biçimlerini eşitleyebilmek uyumluluk açısından avantajdır, ancak biçime özel birleştirme yapılamaması da bir zayıflık hâline gelir

  • Git ve GitHub

    • Git ve GitHub çoğunlukla kaynak kodu iş birliğinde kullanılır ve bugün yerel öncelikli yaklaşıma en yakın yazılım paketi olarak değerlendirilir
    • Git deposu, yerel dosya sistemindeki ana veri kopyasıdır ve sunucuya bağımlı değildir
    • Tam çevrimdışı çalışma, hızlı işleyiş, kullanıcı denetimi ve uzun vadeli saklamaya uygunluk sunar
    • GitHub iş birliği, birden çok cihazdan erişim, yedekleme ve arşiv konumu sağlar; ancak depoları şifrelemez
    • Git’in iki büyük zayıflığı vardır
      • Google Docs, Trello, Figma’daki gibi ince taneli, gerçek zamanlı otomatik birleştirmeye dayalı iş birliği yoktur
      • Kod ve satır tabanlı metin için optimize edilmiştir; diğer dosya biçimleri anlamlı biçimde düzenlenip birleştirilmesi zor olan ikili blob’lar olarak ele alınır
    • Birçok yazılım mühendisinin Cloud9, Repl.it, Colaboratory gibi bulut tabanlı editör ve çalıştırma ortamlarından kaçınma nedeni olarak “yavaş”, “güvenmiyorum”, “kodumu yerel sistemimde tutmak istiyorum” demesi, yerel öncelikli motivasyonla örtüşür

Geliştirici altyapısı açısından seçenekler

  • İnce istemcili web uygulamaları

    • Rails, Django, PHP, Node.js sunucularının verileri SQL veya NoSQL veritabanında saklayıp web sayfalarını HTTPS üzerinden sunduğu modeldir
    • Kurulum gerektirmez; kullanıcıların yalnızca URL’yi ziyaret etmesi yeterlidir ve veri yönetimi sorumluluğu dağıtımı yapan mühendislik ve DevOps ekibindedir
    • Meteor, ShareDB, Pusher, Ably, WebSocket web uygulamalarına gerçek zamanlı iş birliği özellikleri eklemeyi kolaylaştırır
    • Her kullanıcı eylemi için sunucu isteği gerekiyorsa sistem yavaşlar; istemci JavaScript’iyle gidiş-dönüş süresi gizlense bile kararsız internette kolayca bozulur
    • manifest, localStorage, service worker, Progressive Web Apps gibi çabalara rağmen web uygulaması mimarisi temelde sunucu merkezlidir
    • Tarayıcıda çerezler silindiğinde yerel depolama verilerinin de birlikte silinmesi sık görülen bir durumdur; bu da uzun vadede önemli verileri saklamak için uygun değildir
    • Açık kaynaklı web uygulamasını kullanıcının kendi barındırması bazı özellikleri iyileştirebilir; ancak kullanıcıların çoğu sistem yöneticisi olmak istemediğinden, kendi kendine barındırma büyük çoğunluk için gerçekçi bir seçenek değildir

  • Yerel depolama kullanan mobil uygulamalar

    • iOS ve Android uygulamaları ikili dosyayı indirip yerelde kurar; ancak Twitter, Yelp, Facebook gibi birçok uygulama sunucu olmadan çalışmayan ince istemcilerdir
    • SQLite, Core Data, normal dosyalar gibi kalıcılık katmanlarıyla veriyi önce yerel cihaza kaydeden uygulamalar, yerel öncelikli ideale daha yakındır
    • Clue ve Things, tek kullanıcılı uygulama olarak başlayıp cihazlar arası eşitleme veya paylaşım için bulut arka ucu ekleyen örneklerdir
    • Bu tür kalın istemcili uygulamalarda sunucu eşitlemesi arka planda gerçekleştiğinden hızlıdır ve çevrimdışı da çalışır
    • Birden çok cihaz ya da iş birliği yapan birden çok kullanıcı verileri değiştirdiğinde zorluk artar
    • Mobil uygulama geliştiricileri genellikle son kullanıcı uygulaması geliştirme uzmanıdır; dağıtık sistem uzmanı değildir
    • Geçici diff, merge ve çakışma çözme algoritmaları çoğu zaman düşük güvenilirlikte ve kırılgandır

  • Firebase, CloudKit, Realm

    • Firebase, yerel cihaz veritabanını, bulut veritabanı hizmetini ve ikisi arasındaki eşitlemeyi birleştiren bir mobil BaaS’tir
    • Firebase birden çok cihaz arasında paylaşımı ve çevrimdışı kullanımı destekler; ancak tescilli bir barındırma hizmeti olduğu için gizlilik ve uzun ömürlülük puanı düşüktür
    • Parse, Facebook tarafından satın alındıktan sonra 2017’de kapatıldı; ona bağımlı uygulamalar başka arka uçlara taşınmak zorunda kaldı
    • Firebase konsolu geliştiricilere verileri görme, değiştirme ve silme konusunda iyi bir deneyim sunar; ancak kullanıcılar buna denk veri erişimi, işleme ve yönetim araçlarına sahip değildir
    • Apple CloudKit iOS ve Mac ile sınırlanabilen uygulamalara Firebase’e benzer bir deneyim sunar
      • Anahtar-değer deposu ve eşitleme
      • İyi çevrimdışı özellikler
      • Platforma yerleşik olması sayesinde hesap oluşturma ve oturum açma zahmetinin azalması
    • Realm, iOS için yerel kalıcılık kütüphanesi olarak popülerlik kazandı; Realm Object Server ise açık kaynaklı ve kendi kendine barındırılabilir olduğundan hizmete bağımlılık riskini azaltır

  • CouchDB

    • CouchDB, birden fazla makinenin veritabanının eksiksiz kopyalarına sahip olduğu ve her kopyanın bağımsız olarak değişiklik oluşturabildiği multi-master replication yaklaşımıyla dikkat çekti
    • Cloudant barındırılan sürümüdür; PouchDB ve Hoodie ise aynı eşitleme protokolünü kullanırken son kullanıcı cihazlarında çalışacak şekilde tasarlanmıştır
    • Felsefi olarak CouchDB yerel öncelikli ilkelere yakındır; ancak aynı anda değiştirilen verilerde çakışma çözümünü uygulama kodunun açıkça yapması gerekir
    • Google Docs gibi her tuş vuruşunun ayrı bir değişiklik olabildiği ince taneli iş birliği uygulamalarında doğru çakışma çözme kodu yazmak zordur
    • Yaygın benimsenememesinin nedenleri arasında kullanıcı başına ayrı DB ölçeklenebilirliği, iOS ve Android yerel uygulamalarına JavaScript istemcisi gömme, çakışma çözümü ve MapReduce sorgu modelinin yabancılığı gösterilir

CRDT ve daha iyi temel teknolojiler

  • Mevcut uygulama geliştirme veri katmanları, yerel öncelikli idealin tüm gereklerini karşılamıyor
  • Ink & Switch, bir çözüm bulmak için üç yıl önce araştırmaya başladı ve umut vadeden bir temel olarak Conflict-free Replicated Data Types ya da CRDT’leri ortaya koydu
  • CRDT, 2011’de akademik bilgisayar bilimi araştırmalarında ortaya çıkan genel amaçlı bir veri yapısıdır
  • Hashmap ve liste gibi veri yapıları gibi belge durumunu saklar, ancak en başından çok kullanıcılı ortamlar düşünülerek tasarlanmıştır
  • Metin düzenleyiciler, elektronik tablolar ve vektör grafik uygulamaları, kendi belge durumlarını veri yapısı olarak tutar; işbirliğine dayalı çok kullanıcılı uygulamalarda bunlar CRDT ile değiştirilebilir

  • CRDT’nin birleştirme biçimi

    • Kullanıcılar çevrimdışıyken bile yerel cihazlarında uygulama durumunu görebilir ve değiştirebilir
    • CRDT değişiklikleri izler ve ağ kullanılabilir olduğunda arka planda diğer cihazlarla eşitler
    • Farklı cihazlarda aynı anda yeni yapılacak işler eklendiğinde, birleştirilmiş durum eklenen tüm öğeleri tutarlı bir sırayla içerir
    • Farklı nesnelere yapılan eşzamanlı değişiklikler kolayca birleştirilebilir
    • Otomatik çözümün zor olduğu durum, birden fazla kullanıcının aynı nesnenin aynı özelliğini aynı anda güncellemesidir; CRDT çakışan değerleri izler ve çözümü uygulamaya ya da kullanıcıya bırakır
    • CRDT, Git’e benzer; ancak metin dosyalarından daha zengin veri tipleri üzerinde çalışır
    • Eşitleme kanalı sunucu, P2P bağlantısı, Bluetooth, USB bellek gibi herhangi bir şey olabilir
    • Değişiklik birimi tek bir tuşa basma kadar küçük olabilir; bu da Google Docs tarzı gerçek zamanlı işbirliğini mümkün kılar. İstenirse Git pull request’leri gibi büyük paketler halinde de gönderilebilir

  • Automerge ve Hypermerge

    • Ink & Switch, açık kaynaklı JavaScript CRDT uygulaması Automerge’i geliştirdi
    • Automerge, JSON CRDT araştırmasına dayanır
    • Automerge ile Dat networking stack’i birleştirerek Hypermerge’i oluşturdu
    • Bu kütüphanelerin yerel öncelikli ideali tamamen hayata geçirdiğini söylemek zor; hâlâ daha çok çalışmaya ihtiyaç var
    • CRDT, internetin packet switching’i ya da akıllı telefonların capacitive touchscreen’i gibi, kullanıcıların veri sahipliğine sahip olduğu işbirliğine dayalı yazılımlar için temel teknoloji olma potansiyeline sahip

Ink & Switch prototipleri

  • CRDT algoritmaları ve teorisinin doğrulanması akademide ilerleme kaydetmiş olsa da, endüstriyel kullanım hâlâ sınırlı ve çoğunlukla sunucu merkezli bilişimde kullanılıyor
  • CRDT kullanan sunucu merkezli sistemlere örnek olarak Azure Cosmos DB, Redis, Riak, Weave Mesh, SoundCloud Roshi ve Facebook OpenR gösteriliyor
  • Ink & Switch, son kullanıcı cihazlarında CRDT kullanan yaratıcı işler için yerel öncelikli işbirliği uygulama prototipleri geliştirdi
  • Deneyler üç soruyu ele alıyor
    • Teknik uygulanabilirlik: CRDT gerçek yazılıma ne kadar yakın?
    • Kullanıcı deneyimi: Merkezi otorite sunucusu olmadan Google Docs benzeri gerçek zamanlı işbirliği ve Git benzeri çevrimdışı dostu asenkron işbirliği mümkün mü?
    • Geliştirici deneyimi: CRDT veri katmanı SQL DB, dosya sistemi ve Core Data’dan nasıl farklı?
  • Üç prototip Electron, JavaScript ve React ile geliştirildi; indirilebilir ve kurulabilir yazılım olmasının sahiplik hissi açısından önemli olduğu değerlendirildi

  • Trellis

    • Trellis, Trello’yu model alan bir Kanban board’dur
    • Ağ iletişim katmanı olarak WebRTC denendi
    • Git ve Google Docs’un “See New Changes” özelliğinden ilham alan bir değişiklik geçmişi tasarlandı
    • Kullanıcılar Kanban board’daki işleri görebilir ve belgenin önceki durumlarına geri dönüp bakabilir

  • Pixelpusher

    • Pixelpusher, Javier Valencia’nın Pixel Art to CSS’ine Figma benzeri gerçek zamanlı işbirliği deneyimi ekleyen işbirliğine dayalı bir çizim programıdır
    • Ağ iletişimi için Dat projesinin P2P kütüphanesi denendi
    • Belge paylaşım URL’si, Git’ten ilham alan görsel branch/merge, çakışan pikselleri kırmızıyla vurgulayan çakışma çözümü ve kullanıcıların çizdiği avatarlar temelinde basit kullanıcı tanımlama denendi

  • PushPin

    • PushPin, Miro veya Milanote’a benzeyen bir mixed media canvas workspace’tir
    • Automerge tabanlı üçüncü proje olarak, üç prototip içinde en olgun olanıydı
    • Ekip ve harici test kullanıcılarının gerçek kullanımı, underlying data layer üzerinde daha büyük yük oluşturdu
    • İç içe geçmiş ve bağlantılı paylaşılan belgeler, CRDT belgeleri için çeşitli renderer’lar, outbox modelini içeren daha gelişmiş bir kimlik sistemi ve seçim vurgusu gibi geçici veri paylaşımı denendi

Prototiplerden Elde Edilen Sonuçlar

  • Üç prototipin amacı, yerel öncelikli yazılımın ve CRDT’nin teknik fizibilitesini, kullanıcı deneyimini ve geliştirici deneyimini değerlendirmekti
  • Geliştirme ekibinden 5 kişi düzenli olarak kullandı; yaklaşık 10 harici kullanıcıyla bire bir kullanılabilirlik testleri yapıldı
    • Harici kullanıcılar arasında profesyonel tasarımcılar, ürün yöneticileri ve yazılım mühendisleri vardı
    • Resmî bir değerlendirme metodolojisi yerine keşif odaklı bir yaklaşım kullanıldı

  • CRDT teknolojisi çalışıyor

    • Automerge’ün güvenilirliği beklenenden daha iyiydi
    • Ekibin uygulama geliştiricileri kütüphaneyi nispeten kolay entegre edebildi; verilerin otomatik birleştirilmesi neredeyse her zaman sezgisel ve sorunsuzdu

  • Çevrimdışı kullanıcı deneyimi iyiydi

    • Çevrimdışına geçip istenildiği kadar çalışmak, tekrar bağlandıktan sonra iş arkadaşlarının değişiklikleriyle birleştirmek iyi işledi
    • Diğer uygulamalar “offline” uyarıları ve hataları gösterip çalışmayı engellerken bile yerel öncelikli prototipler ağ durumundan bağımsız olarak normal çalıştı
    • Tarayıcı tabanlı sistemlerin aksine, uygulamanın çalışıp çalışmayacağı veya verilerin mevcut olup olmayacağı konusunda endişe etme ihtiyacı azaldı; araçlar ve çalışmalar üzerinde sahiplik hissi verdi

  • React’in FRP modeliyle iyi uyum sağlıyor

    • React’in Functional Reactive Programming modeli CRDT ile iyi uyum sağlıyor
    • CRDT tabanlı veri katmanında belge, yerel kullanıcı girdisini ve ağdan gelen diğer kullanıcı/cihaz değişikliklerini aynı anda alır
    • FRP modeli, görünen uygulama durumunu paylaşılan belgenin underlying state’iyle güvenilir biçimde senkronize eder
    • Geliştirici, diğer kullanıcılardan gelen değişiklikleri izleme ve bunları mevcut ekranla uzlaştırma zahmetinden kurtulur
    • Tüm durum değişikliklerini tek bir reducer fonksiyonundan geçirmek, ilgili yerel değişiklikleri diğer kullanıcılara göndermeyi de kolaylaştırır

  • Çakışmalar beklenenden daha az ciddiydi

    • Kullanıcılar iş birliği sırasında çakışmalarla nadiren karşılaştı ve genel çözüm mekanizmaları iyi çalıştı
    • Automerge değişiklikleri ince ayrıntı düzeyinde izler ve veri tipi semantiğini dikkate alır
    • İki kullanıcı bir dizinin aynı konumuna aynı anda öğe eklerse, iki öğeyi deterministik bir sırayla birleştirir
    • Git gibi metin sürüm kontrol sistemleri bunu manuel çözüm gerektiren bir çakışma olarak görebilir
    • Kullanıcıların iş birliği konusunda sezgileri olduğundan, aynı bölümü aynı anda düzenlememek için çalışma alanını örtük biçimde paylaştıkları durumlar olur
    • Kanban uygulamasında bir kullanıcı karta yorum eklerken başka bir kullanıcı kartı başka bir sütuna taşıdığında iki değişiklik de yansıtılır
    • Çakışma yalnızca aynı nesnenin aynı özelliği aynı anda düzenlendiğinde ortaya çıkar; örnek olarak iki kullanıcının aynı görüntü nesnesinin konumunu aynı anda değiştirmesi verildi
    • Prototiplerde Automerge’ün varsayılan birleştirme semantiği yeterliydi; özel semantik gerektiren bir durum bulunmadı

  • Belge geçmişinin görselleştirilmesi önemli

    • Dağıtık iş birliği sistemlerinde diğer kullanıcıların çok sayıda değişikliği herhangi bir anda gelebilir
    • Değişikliklere aracılık eden merkezi bir sunucu olmadığından, belgenin mevcut durumuna hangi yoldan geldiğini, hangi sürümlerin bulunduğunu ve katkıların kaynağını anlamaya yarayan araçlara ihtiyaç vardır
    • Trellis, kullanıcıların birleştirilmiş belgenin geçmiş durumlarına gidip bakabildiği bir “time travel” arayüzünü denedi
    • Yeni alınan değişiklik öğelerini otomatik vurgulama yöntemi de denendi

  • URL ile paylaşım doğal geliyor

    • Çeşitli belge paylaşım mekanizmaları arasında, web’den ilham alan URL modeli kullanıcılar ve geliştiriciler için en doğal olanıydı
    • URL kopyalanıp yapıştırılabilir; e-posta veya sohbet gibi iletişim kanalları üzerinden paylaşılabilir
    • Gizli URL’nin ötesindeki belge erişim izinleri hâlâ açık bir araştırma sorusu olarak duruyor

  • P2P sistemler basitçe çevrimiçi/çevrimdışı diye ayrılmaz

    • Merkezi sistemler genellikle sunucuyla kararlı bağlantı olup olmamasına göre “up” veya “down” durumunu tanımlar
    • Dağıtık sistemlerde her kullanıcı, hangi verilere sahip olduğuna, neleri paylaştığına ve neleri kabul ettiğine bağlı olarak farklı bakış açılarına sahip olabilir
    • Uçaktaki dizüstü bilgisayarda yapılan düzenlemeler, inişten sonra bağlantı kurulunca diğer kullanıcılara dağıtılabilir
    • Diğer kullanıcılar bu değişikliklerin tamamını, bir kısmını veya hiçbirini kendi belge sürümlerine kabul etmeyebilir
    • Git depolarında olduğu gibi, belirli bir kullanıcının “master”ı, diğer kullanıcılarla en son iletişim kurduğu anın bir fonksiyonu hâline gelir
    • Dağıtık belgeler veri kontrolünü kullanıcıya verir, ancak bunun gerçek UI açısından ne anlama geldiği daha fazla araştırma gerektirir

  • Uzun değişiklik geçmişi performans sorunları yaratır

    • PushPin sprint planlama gibi gerçek belgelerde kullanılınca performans ile bellek/disk kullanımı hızla sorun hâline geldi
    • CRDT, karakter düzeyinde metin düzenleme de dahil olmak üzere tüm geçmişi saklar
    • 6 ay sonra birisi belgeye yeniden bağlanıp o noktadan itibaren değişiklikleri birleştirmek zorunda kalabileceği için geçmiş kolayca kesilip atılamaz
    • Automerge optimizasyonu sürüyor ve başlıca devam eden çalışma alanlarından biri olmaya devam ediyor

  • Ağ iletişimi hâlâ çözülmedi

    • CRDT algoritmaları yalnızca veri birleştirmeyi ele alır; diğer kullanıcıların düzenlemelerinin fiziksel olarak aynı bilgisayara nasıl ulaşacağını ele almaz
    • Deneylerde WebRTC, Dropbox ve USB bellekle dosya kopyalamaya dayalı bir sneakernet uygulaması, IPFS protokolü olasılığı ve Dat’in Hypercore P2P kütüphanesi denendi
    • CRDT mutlaka P2P ağ katmanı gerektirmez; sunucu üzerinden iletişim de mümkündür
    • Yerel öncelikli yaklaşımın uzun ömürlülük hedefini tam olarak gerçekleştirmek için, tedarikçinin backend hizmetlerinden daha uzun yaşayacak merkeziyetsiz bir çözüm mantıksal nihai hedeftir
    • P2P teknolojisi production’a hazır olmaktan uzaktı; özellikle NAT traversal, router’a veya ağ topolojisine bağlı olarak düşük güvenilirlik gösterdi
    • İnternet erişimi olmadan bilgisayarların doğrudan gerçek zamanlı iş birliği yapması deneyimi, merkezi API’lere bağımlı bir dünyada büyük bir potansiyel gösteriyor

  • Bulut sunucuları yardımcı rolünde kalır

    • PushPin gibi gerçek zamanlı iş birliği prototipleri, aracı sunucu olmadan belge paylaşabildiği için gizlilik ve sahiplik açısından iyidir
    • Ancak kullanıcı bir belgeyi paylaştıktan sonra karşı taraf bağlanmadan dizüstü bilgisayarını kapatırsa, iki kullanıcı aynı anda çevrimiçi olmadığından bağlantı kurulamaz
    • Sunucu, yerel öncelikli dünyada merkezi otorite değil, cloud peer rolünü üstlenebilir
      • Belge kopyasını saklayıp başka bir peer çevrimiçi olduğunda iletmek
      • Arşiv ve yedekleme konumu sağlamak
      • Hava tahmini veya hisse fiyatları gibi geleneksel sunucu API’lerine köprü olmak
      • Güçlü GPU ile video render etme gibi burst computing sağlamak
    • Geleneksel sistemler ile yerel öncelikli sistemler arasındaki fark, sunucunun var olup olmaması değil; sunucunun gerçeğin kaynağı olmak yerine destekleyici rol üstlenmesidir

Bundan Sonra Yapılması Gerekenler

  • Dağıtık sistemler ve programlama dili araştırmacıları

    • CRDT ve P2P teknolojileri üzerine araştırmalar, yerel öncelikli yazılıma büyük katkı sağlayabilir
    • Mevcut CRDT araştırmaları genellikle tüm işbirlikçilerin tek bir belge sürümüne düzenlemeleri anında uyguladığı bir modeli varsayar
    • Gerçek yerel öncelikli uygulamalar, başka işbirlikçilerin düzenlemelerini reddedebilmeli veya paylaşılmayan belge sürümlerinde özel değişiklikler oluşturabilmelidir
    • branch, fork, rebase gibi dağıtık kaynak kontrolü kavramlarını, birden çok belge sürümünün ve branch'in yan yana var olduğu işbirliği modellerine genişleten araştırmalar yetersizdir
    • Tipler, şema migrasyonları ve uyumluluk da önemli sorunlardır
      • Her işbirlikçi farklı uygulama sürümleri ve özellikleri kullanabilir
      • Merkezi bir DB sunucusu olmadığı için verinin otoriter “güncel” şeması yoktur
      • Veri biçimi evrilirken birden fazla uygulama sürümü güvenli biçimde birlikte çalışabilmelidir

  • HCI araştırmacıları

    • Merkezi sistemlerde sunucuyla senkronizasyon durumunu gösteren çok sayıda örnek vardır, ancak merkeziyetsiz sistemler yeni UI sorunları doğurur
    • Tüm kullanıcıların verinin farklı kopyalarına sahip olabildiği bir sistemde çevrimiçi/çevrimdışı, kullanılabilir/kullanılamaz durumlarının nasıl aktarılacağı üzerine araştırma gerekir
    • Geniş internet olmadan diğer düğümlerle doğrudan işbirliği yapılabildiğinde “çevrimiçi”nin ne anlama geldiği de değişir
    • Her belge yalnızca gündelik kullanımla karmaşık bir sürüm geçmişine sahip olabileceğinden, kullanıcının sürümleri, değişiklik kabulünü ve belgenin oluşum sürecini anlamasını sağlayan UI'lara ihtiyaç vardır
    • Günümüzde değişiklik yönetiminde kaynak kodu tarzı diff/patch modeli ile Google Docs tarzı suggestion/comment modeli baskındır
    • Bu fikirlerin metin dışı veri biçimlerine nasıl genelleştirileceği açık bir problemdir
    • Yerel öncelikli yaklaşımda veriye sahip kullanıcının yerelde değişiklik yapması engellenemez; yetki kavramı, diğer kullanıcıların bu değişikliği takip edip etmeyeceğini seçmesi şeklinde değişir

  • Uygulayıcılar

    • Prodüksiyon yazılımı geliştiren mühendisler, tasarımcılar, ürün yöneticileri ve bağımsız geliştiriciler, yerel öncelikli geleceğe doğru kademeli adımlar atabilir
    • Hızlı uygulamalar için agresif önbellekleme ve önceden indirme ile belge açılırken görülen spinner'lar azaltılabilir; varsayılan olarak yerel önbelleğe güvenilebilir
    • Çoklu cihaz desteği Firebase ve iCloud gibi senkronizasyon altyapılarıyla nispeten kolay sağlanabilir, ancak uzun ömürlülük ve gizlilik konusunda endişeler vardır
    • Çevrimdışı kullanım için web tarafında Progressive Web Apps, Service Workers ve app manifest yardımcı olabilir
    • Uygulama testleri WiFi kapatılarak ya da Chrome DevTools network condition simulator, iOS network link conditioner gibi araçlarla ağ koşulları değiştirilerek yapılabilir
    • İşbirliği için CRDT dışında ShareDB vb. içinde uygulanan Operational Transformation daha yerleşik bir teknolojidir
    • Uzun vadeli koruma için JSON, PDF gibi kararlı biçimlere kolayca dışa aktarım yapılabilmelidir
      • Google Takeout gibi toplu dışa aktarma
      • GoodNotes'un kararlı dosya biçimine sürekli yedekleme
      • Trello'nun JSON belge indirmesi
    • Gizlilik açısından, verinin yalnızca cihazda mı saklandığı yoksa backend'e mi gönderildiği kullanıcıya açıkça bildirilmelidir
    • Kullanıcı kontrolü için uygulama içinde belge yedekleme, çoğaltma ve silme kolay olmalıdır; Google Docs'un Google Drive üzerinden temel dosya sistemi işlemlerini yeniden uygulaması buna örnek olarak sunulur

Startup Fırsatları ve Sonuç

  • Geliştirici altyapısı kurmak isteyen kurucular için “Firebase for CRDTs” ilginç bir pazar fırsatı olarak sunulur
  • Böyle bir startup iyi bir geliştirici deneyimi ve SQLite ya da Realm gibi yerel kalıcılık kütüphaneleri sağlamalıdır
  • iOS, Android, Windows, Mac, Linux, Electron ve Progressive Web Apps desteklenmelidir
  • Kullanıcı kontrolü, gizlilik, çoklu cihaz desteği ve işbirliği varsayılan olarak dahil edilmelidir
  • Başarının turnusol testi, tüm sunucular kapatılsa bile müşteri uygulamalarının kalıcı olarak çalışmaya devam edip etmediğidir
  • Bulut yazılımı işbirliği ve her yerden erişilebilen güncel uygulamalar sağladı, ancak veri sahipliğini sunuculara bırakarak kullanıcıları kendi verilerinin kiracısı hâline getirdi
  • Yerel öncelikli yaklaşım, kullanıcıların veri sahipliğini ve kontrolünü korurken bulut tarzı işbirliği ve erişilebilirlik elde edebileceğini gösterir
  • Gerçek uygulama için çevrimdışı destek, cihaz üstü depolamanın kullanımı, algoritma/programlama modeli/kullanıcı arayüzü iyileştirmeleri ve CRDT ile P2P ağlarının ürünleştirilmesi daha da gereklidir

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-06
Hacker News yorumları

  • Tamamen katılıyorum. Her servisin verilerimi kendi bulutuna taşımasından ve düzgün kullanmak için bana abonelik ücreti ödeten bu gidişattan bıktım
    Şu anda geliştirdiğim fitness takip uygulamasında “bir kez satın al, X yıl boyunca güncelleme al, tüm cihazlarınla eşitle ve sonrasında da kalıcı olarak kullan” modeline gitmeye çalışıyorum. X yıl sonra güncellemeye ihtiyaç duyarsan yeni sürümü tekrar satın alırsın; mevcut özellikler yeterliyse kullanmaya devam edersin
    Çoğu yazılımın bu şekilde makul bir fiyata satın alınabilir olmasını, ürünün kendisinin iyi olmasını ve bulut olmadan kullanılamayacak şekilde kilitlenmemesini isterim. Yerel öncelikli yazılımın en iyi yanı; reklam, izleme ve etkileşimi maksimize etmek yerine ürün kalitesinden para kazanmayı sağlayan sağlıklı teşviki geri getirmesi

    • Obsidian da iyi referans alınabilecek bir model. İstemci tamamen ücretsiz; yalnızca isteğe bağlı eşitleme servisini satıyor
      Notların hepsi Markdown dosyaları olduğu için istemcinin kendisi bile opsiyonel hale geliyor
    • Bulut altyapısı olmadan eşitlemeyi nasıl planladığını merak ediyorum
    • “X yıl güncelleme + cihaz eşitleme + kalıcı kullanım” kulağa iyi geliyor ama bu yöntemle 1-2 yıllık abonelik toplam maliyetini tek seferde alman gerekir
      Eşitleme sunucularını da sürekli çalıştırman gerekiyor; kullanıcının 1 yıllık veriyi bir günde topluca eşitlediği durumları da hesaba katmalısın. Gelecekteki geliştirmeyi üstlenecek personele de sürekli maaş ödemek gerektiğinden, yalnızca geliştirici perspektifinden bakınca gözden kaçan noktalar var
    • Birkaç yıl önce yerel bir fabrikanın, IT tedarikçisinin sunucu arızası yüzünden üretimi iki gün durdurmasının ardından en kötü senaryoyu düşünerek benzer şeyler aklımdan geçmişti
      https://rodyne.com/?p=1439
    • Backend, gerçek zamanlı işbirliği veya eşitleme gibi işlevlerin bir parçası olabilir. Ancak buluttan çıkarılabilir (ejectable) olup her an self-hosting’e geçirilebiliyor ya da geri döndürülebiliyorsa, hem veri hem de servis üzerindeki sahipliği ve uzun ömürlülüğü güvenceye alabilir
      Bizim geliştirdiğimiz not/görev IDE’si de bu şekilde: https://thymer.com/local-first-ejectable

  • Berlin’de Ink and Switch’in düzenlediği yıllık Local-first Software Conference var; bu yıl kasımda SF’de Sync Conf adlı bir yan etkinlik de düzenleniyor
    https://www.localfirstconf.com/
    https://syncconf.dev/
    Bu yıl, orijinal makalenin ortak yazarlarının geliştirici araçları bağlamında yerel öncelikli yazılımın ne olduğunu ve orijinal makaleden bu yana neler öğrendiklerini ele aldığı panel iyiydi: https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf
    Topluluk, “eşitleme”yi yerel öncelikli yaklaşımın bir bileşeni ama çok daha geniş uygulanabilirliğe sahip bir teknoloji olarak konumlandırma yönünde netleşiyor. Yerel öncelikli olmak, son kullanıcı yazılımının bir özelliği; eşitleme motoru gibi geliştirici araçları bunu mümkün kılan araçlar, kendi başlarına mutlaka yerel öncelikli olmak zorunda değiller
    Son birkaç yılın tüm konuşmaları burada: https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ
    Yerel öncelikli/eşitleme motoru topluluğu için ilginç bir dönem. Gerçek zamanlı işbirliği ve asenkron işbirliği deneyimlerini mümkün kılan araçlar geliştirildi ve yapay zekanın ortaya çıkmasıyla bu pazar büyüyor. Tüm yapay zeka uygulamaları, özünde ajanların aktör olarak katıldığı çok kullanıcılı işbirliği sistemleri olduğundan, eşitleme motoru topluluğunun üzerinde çalıştığı teknolojilere ihtiyaç duyuyor

    • Yerel öncelikli uygulamalar ve altyapı geliştiren mühendislerle röportajlar yapan harika bir Local First podcast’i de var
      https://www.localfirst.fm/

  • Okumaya değer; geçmişte de birkaç kez canlı tartışmalar olmuştu
    https://news.ycombinator.com/item?id=19804478 - Mayıs 2019, 191 yorum
    https://news.ycombinator.com/item?id=21581444 - Kasım 2019, 241 yorum
    https://news.ycombinator.com/item?id=23985816 - Temmuz 2020, 9 yorum
    https://news.ycombinator.com/item?id=24027663 - Ağustos 2020, 134 yorum
    https://news.ycombinator.com/item?id=26266881 - Şubat 2021, 90 yorum
    https://news.ycombinator.com/item?id=31594613 - Haziran 2022, 30 yorum
    https://news.ycombinator.com/item?id=37743517 - Ekim 2023, 50 yorum

  • Çevrimiçi bağımlılığı olan her şey kaçınılmaz olarak sürekli bakım ve maliyet gerektirir. Bir sistem yerel öncelikli, mümkünse yalnızca yerel değilse, uzun vadeli güvenilirlik için tasarlanmış değildir.
    Bağlantılı ev aletleri ve otomobiller, pratik açıdan en aptalca mühendislik örneklerine yakındır.

    • Bunların hepsi abonelik geliri yüzünden.
      Abonelik geliri elde eden şirketlerin geliri de daha yüksek olur, değerlemeleri de; ek finansman bulmaları kolaylaşır ve bu modeli izlemeyen şirketleri yenerler. Bu kendini güçlendiren yapı yüzünden yerel öncelikli yazılımın öldüğünü düşünüyorum.
    • Dropbox veya Apple gibi yerlerdeki ücretsiz/ücretli depolamaya bakınca gerçek maliyet görülüyor. Kabaca 2 TB için ayda 10 dolar düzeyinde.
      Cloudflare statik dosya barındırmayı neredeyse ücretsiz sunuyor; maliyet yuvarlama hatası denecek kadar düşük. Yerel öncelikli 1000 uygulama Dropbox’a senkronize olsa bile ayda 10 dolarlık depolamayla çalışabilir. Bu depolama, S3 gibi düşük seviyeli ham bir araç değil; kimlik doğrulama, destek ve senkronizasyon programı da olan tüketiciye yönelik bir hizmet. Bulut maliyetlerinin çoğu aslında gerekli değil.
    • Stop Killing Games girişimine karşı olan biriyseniz bu yorumu okumalısınız.
      Kimse oyunları yalnızca çevrimiçi hizmetlere bağımlı olmaya zorlamıyor. Bu ne yasal bir gereklilik ne de düzenleyici bir zorunluluk. Yazılımdaki pek çok şey gibi bu da sadece bir tercih. Çevrimiçi hizmetlere bağımlı olmayı seçip daha sonra “bunu geri almak para tutar” demek kısa görüşlü ve acınasıdır; kabul edilmemelidir.

  • Daha fazla uygulama yerel öncelikli olmalı. Kullanıcı verilerini buluta senkronize etmek istemiyorsa bu seçeneğe sahip olmalı.
    Bir süredir çevrimdışı öncelikli veya yerel öncelikli bir uygulama olan Brisqi’yi geliştiriyorum ve en başından çevrimdışı öncelikli felsefeyle tasarladım.
    https://brisqi.com
    Yerel öncelikli uygulamalar süresiz olarak tamamen çevrimdışı çalışacak şekilde tasarlanmalı. Yerel deneyim temel olmalı, yedek bir yol değil; bulut senkronizasyonu da gereksinim değil, yardımcı bir özellik olmalı.
    Geçici önbelleğe dayanan uygulamaları çevrimdışı öncelikli saymıyorum. Gerçek bir çevrimdışı öncelikli uygulama, verileri yerel bir veritabanında kalıcı hale getirmeli. “Çevrimdışı öncelikli” diye adlandırılan pek çok uygulama aslında yalnızca sınırlı çevrimdışı işlevler sunuyor ve sonuçta internete yeniden bağlanmaya bağımlı olan çevrimdışına izin veren uygulamalara daha yakın.
    Çevrimdışı öncelikli uygulamalar, yalnızca çevrimiçi web uygulamalarına kıyasla kesinlikle daha zor geliştiriliyor; çevrimdışı/çevrimiçi geçişleri sırasında da verilerin tutarlı biçimde buluta senkronize edilmesini ve kaybolmamasını sağlayacak senkronizasyon mekanizmasının yeterince güvenilir olması gerekiyor. Yaklaşımımı blogda daha ayrıntılı yazdım: https://blog.brisqi.com/posts/how-i-designed-an-offline-first-app-an-outline

    • Bu modelin bir iş olarak sürdürülebilir olmasının daha zor olmayacağından endişeleniyorum; pratikte nasıl ilerlediğini merak ediyorum.

  • Bu ilkenin tüketici alanına uyarlanarak açıklanması ilginç, ancak biz şu anda endüstriyel varlıklar/endüstriyel veri tarafında aynı şeyi yapıyoruz.
    www.sentineldevices.com adresinde öğrenme, analiz ve karar verme süreçlerinin tamamı müşterinin ekipmanı üzerinde gerçekleşiyor. Verinin gönderileceği bir sunucu bile yok; açıkça her şeyin cihazın içinde çalıştığı bir model.
    SCADA/endüstriyel otomasyonda verinin dışarı çıkarılamadığı çok sayıda kullanım senaryosu var. Veri/yapay zeka şirketleri, müşterinin bulunduğu yerde hizmet vermenin zor olduğu gerekçesiyle devasa bir müşteri kitlesini ve kullanım senaryolarını görmezden geliyor; bunun yerine veriyi kendilerine getirmeye ve tedarikçi bağımlılığını sürdürmeye çalışıyorlar.
    Müşterilerle konuşurken tam tersine “Hayır, bu yerel ve dış bağlantısı yok” kısmını özellikle vurgulamamız gerekiyor. Böyle bir şeyi neredeyse hiç duymadıkları için her şeyin yerelde gerçekleştiğini anlamaları adına çoğu zaman adım adım açıklamak gerekiyor; yazılım tedarikçileri de bu kavramı pek benimseyemiyor. Tüketici alanında yerel öncelikli yazılımın daha fazla yerleşmesini ve böylece endüstriyel alanda da daha tanıdık hale gelmesini isterim.

    • Tüm SCADA tedarikçilerinin bulut modasına kapılıp bu yönde bastırması da yardımcı olmuyor.
      “Fabrikanızı akıllı telefonunuzdan yönetin!” derken artık tek bir sıfır gün açığı çıksa bir script kiddie pompalarımla oynayabilir hale geliyor.
    • İlginç bir alan; bu işi yapıyor olmanıza sevindim.
      Kariyer sayfanıza baktığımda tüm pozisyonların uzaktan çalışmaya kapalı olduğunu gördüm; yerel öncelikli yazılım geliştirmek için yüz yüze olmanın getirdiği bir sınırlama mı, yoksa daha çok yönetimsel nedenlerden mi, merak ediyorum.

  • Şahsen bu yaklaşıma katılmıyorum. “Bulut sağlayıcısına güvenilemez” şeklindeki iş sorununu, “merkezî mimariden kaçınmak” gibi teknik bir ödünle çözmeye çalışıyor gibi görünüyor
    Kapalı kaynak yazılımlardaki kontrol eksikliği ve güvenilirlik eksikliği; açık kaynak geliştirme gibi yeni bir iş modeliyle, yeni lisanslarla ve lisans ücreti yerine bakım sözleşmeleri gibi gelir yöntemleriyle çözüldü
    Benzer şekilde, bulut sağlayıcılarıyla ilgili sorunlar için de iş modeli düzeyinde çözümler gerekiyor. Örneğin kullanıcıların bulut sağlayıcısıyla ilişkilerine güvenebilmesi için hakları tanımlayan standart sözleşmeler/lisanslar oluşturulabilir. Zamanla kullanıcılar yalnızca bu tür lisanslara sahip sağlayıcılarla çalışabilir
    Bunlara kullanım ömrü sonu sözleşmeleri, veri taşınabilirliği garantileri, veri erişimini denetleyen ve kimin/neyin/ne zaman okuduğunu bildiren veri gizliliği şeffaflığı gibi hükümler eklenebilir. Sorun benimsenme. Asıl mesele, bulut sağlayıcılarının bunu neden kabul edeceği; müşteri kaybından korkuyorlarsa bu tür sözleşmeleri yalnızca yıllık aboneliklerde sunabilir ya da daha yüksek fiyat isteyebilirler

    • Bir iş sorununu ya da siyasi sorunu teknik bir çözümle çözebiliyorsanız, bu genellikle güçlü bir yaklaşımdır. Çünkü bu tür sorunları hasım aktörler çıkarır ve teknik çözüm o aktörlerin ihanet etme kabiliyetini ortadan kaldırır
      Bulut hizmetleri kullanırken şifreleme buna iyi bir örnektir. Veriyi gizlilik politikaları ve bürokratik kurallarla korumaya çalışmak neredeyse boşa kürek çekmektir. Veri değerlidir; müşterilerin ya da devletlerin şirketin onu gizlice satıp satmadığını anlaması zordur, güvenlikten tasarruf edilip edilmediğini de çok geç olmadan anlamak zordur
      Ancak veri istemci cihazında şifreleniyorsa ve sunucunun düz metne erişemediği matematiksel olarak kanıtlanabiliyorsa, bu kaygılara gerek kalmaz. Sorun, sunucunun veriyi yalnızca depolamakla kalmayıp işlemesi gerektiğinde ortaya çıkar; o durumda teknik çözüm kendi sunucunuzu kullanmak olur
    • Böyle bir sözleşmenin sorunu gerçekten çözüp çözmediği şüpheli. Bir bulut hizmeti, kapanmadan X ay önce bildirim yapacağını ve veri dışa aktarmaya izin vereceğini belgelemiş olsa bile, gerçekten kapandıktan sonra elinizde fiilen işe yaramaz devasa bir JSON dosyası kalabilir
      Kendi uygulamanızı yapmadıkça ya da yardımsever biri sizin için yapmadıkça bunu kullanmak zordur. Hiç yoktan iyidir, ama şirket kapandıktan ya da desteği kestikten sonra bile yıllarca, hatta on yıllarca çalışabilecek bir yerel uygulama kadar iyi değildir
    • Bu model, bulut sağlayıcılarını bankalara benzetebilir. Bulut sağlayıcısı kullanıcı hesabının içinde bir tür mülk saklar; kullanıcı da bu mülk üzerinde açık haklara ve onu hesaptan geri alma konusunda hukuki yetkiye sahip olur
      Geri alma, finansta para ya da malın teslim alınmasına karşılık gelir; bulutta ise hesabın tüm içeriğini barındıran büyük bir Zip dosyası almak olabilir
      Ancak teslim almak her zaman pratik ya da arzu edilir değildir. Finansta hesap başka bir kuruma aktarılabilir; bulut hizmetlerinde de birçok durumda hesap aktarımının çok daha faydalı olma ihtimali yüksektir
      Buradaki zor nokta taşınabilirliktir. Kullanıcının bulut hesabı üzerindeki mülkiyet ve hakları iyi tanımlansa bile, Facebook arkadaşlarını teslim almak ne demektir, Facebook hesabını başka bir yere taşımak ne anlama gelir, bunlar belirsizdir
    • Bence bu yorum isabetli değil. Yazarlar, local-first için iş gerekçesinin tamamen çözülmediğini ve bunun yakından ilişkili bir sorun olduğunu yeterince kabul ediyor
      Bu sorun hem iş hem de teknik çözümler gerektiriyor; makale de çözümün hangi özelliklere sahip olması gerektiğini öneriyor
      Local-first’ün merkeziyetsizliği savunduğu da doğru değil. Martin Kleppmann, merkeziyetsiz teknolojinin bu sorunu kitlesel pazara gidebilecek bir şekilde çözdüğünü düşünmediğini açıkça belirtti. O, local-first ideallerini mümkün kılan merkezî bir standart eşitleme motorunu destekliyor
      Geçen yılki Local-first conf sunumuna bakın: https://youtu.be/NMq0vncHJvU?si=ilsQqIAncq0sBW95
    • Veri taşınabilirliği garantisi, belli bir ölçeğe sahip veriler için pek pratik değildir. Üretim ortamındaki bir veritabanını yeni bir veritabanına taşımak, sorunsuz yapılacaksa aylar ila yıllar sürebilir
      Kriz durumunda birkaç hafta içinde de yapılabilir, ama çok dağınık hale gelebilir. Aynı sürümdeki açık kaynak veritabanları arasında geçiş yaparken bile bulut hizmetleri arasında çok fark olduğundan durum benzerdir
      En iyi çözüm, veriyi en baştan kendi ortamınızda tutup gerektiğinde bağlantıyı kesmektir. BYOC yönetimini açık kaynakla birleştirince bu mümkün. Bizim şirketimiz de BYOC veri ürünleri işlettiği için bu yaklaşımda ekonomik çıkarımız var; ama gerçekten çalıştığını gördüğüm için mümkün olduğunu biliyorum

  • Kendi projelerim https://github.com/ibizaman/selfhostblocks ve https://github.com/ibizaman/skarabox ile tam da bunu yaygın şekilde mümkün kılmaya çalışıyorum
    Ortak hedef, self-hostingi kitleler için daha erişilebilir hâle getirmek
    NixOS tabanlı olarak https, SSO, LDAP, yedekleme, anlık görüntülü ZFS vb. şeyleri mümkün olduğunca bildirimsel biçimde varsayılan olarak sunmaya çalışıyor
    Vaultwarden ve Nextcloud’u paketleyerek verilerin çoğunu saklayabildiği için bulut hosting’e bir rakip; Home Assistant gibi servisler de sunuyor
    YUNoHost’un da rakibi, ama SelfHostBlocks’un sunduğu bileşenlerle istediğiniz paketi kendiniz self-host edebildiğiniz için daha iyi ya da öyle olmaya çalışıyor. Bir framework’ten çok bir kütüphaneye daha yakın
    NAS’larla da rekabet ediyor, ama her şeyin açık kaynak olması bakımından daha iyi olduğunu düşünüyorum. Şimdilik kullanıcının teknik olması gerekiyor, fakat bu kısıtı kaldırma sürecindeyiz; hedeflerden biri de Nix bilmeden veya komut satırına dokunmadan kendi donanımına kurabilmesini sağlamak

    • Gerçekten iyi. Son zamanlarda bunu çok düşünüyorum. Bu kadar çok harika özgür açık kaynak alternatifi varken, teknik kişiler için “docker compose up” kadar görece kolay olsa da teknik olmayan kişiler için hâlâ ulaşılması zor olması tuhaf
      Self-host edilebilen uygulamaların önemli bir kısmı veritabanı, sunucu ve frontend’i olan web uygulamaları, ancak birçok kullanım senaryosunda yalnızca tek bir bilgisayarda kullanmak yeterli; barındırılan bir sürüme ya da başka cihazlarla senkronizasyona gerek olmayabiliyor. Örneğin kişisel muhasebe ayda bir bilgisayarda yapılabilir; bir yerde 7/24 çalışan bir web uygulaması gerekmiyor. Programı açar, işinizi yapar, sonra kapatırsınız
      Yüksek kaliteli, self-host edilebilir özgür açık kaynak alternatiflerin sayısı ile bunları fiilen kullanabilecek kişi sayısı arasında büyük bir uyumsuzluk var. Bu açığı kapatacak daha fazla projeye ihtiyaç var. selfhostblocks’u birkaç şeyde denemek ve katkıda bulunmak istiyorum
    • hledger’ın dahil edilmesi hoşuma gitti. Düz metin muhasebeye alışık olmayanlar için biraz yabancı gelebilir, ama gerçekten harika bir yazılım

  • Her uygulamanın kendine ait bir senkronizasyon platformu olması için bir neden yok. Bu çerçeveleme, programlar arası bileşebilirlik ya da modülerlik olmayan mobil uygulamalardan çıkmış gibi görünüyor
    “Local-first”ü ciddiye alıyorsanız dosya sistemini kullanmanız yeterli; kullanıcı git, Box vb. çeşitli çözümler arasından seçim yapabilir
    Kendi senkronizasyon aboneliğini istemesi diğer SaaS’ler kadar itici, hatta daha opak ve kırılgan

    • Her uygulamanın kendi senkronizasyon motoruna ihtiyaç duymadığına katılıyorum, ancak dosya sisteminin local-first’ü benimsemenin evrensel yolu olduğu çerçevelemesine katılmıyorum
      Birincisi, local-first istiyorum ama eşzamanlılık da istiyorum. Basit local-first söz konusuysa herhangi bir senkronizasyon yeterli olabilir, ama ben daha fazlasını istiyorum. Dropbox gibi, düşünmeme gerek kalmadan sorunsuz çalışmasını; iletişimin olmadığı bölgelerde de eşimle benim telefonlarımızda ayrı ayrı düzenleme yapabilmemizi istiyorum
      İkincisi, senkronizasyon veri yapısını ve anlamını derinden bildiğinde çok daha iyi çalışır. git ve Box’ın ikisinin de ciddi sınırlamaları var; eşzamanlılık gereksinimi olduğunda bu sınırlamalar daha da büyüyor
    • Genel olarak katılıyorum ama pratikte her zaman bu kadar basit olmuyor. Tam olarak böyle çalışan bir uygulama yaptım; hangi istemcinin ne zaman dosyayı düzenleme izni alacağını koordine edemediğim için sonunda dosya çakışmaları kaçınılmaz hâle geldi

  • Teoride yerel öncelikli geliştirme yaklaşımını seviyorum. Gizliliği ve veri sahipliğini temel alan small tech felsefesiyle iyi örtüşüyor
    Ama pratikte zor. Fiilen bir senkronizasyon motoru oluşturmanız, çakışma çözümünü ele almanız ve şema migrasyonlarını yönetmeniz gerekiyor
    Yine de son birkaç yılda yerel öncelikli yazılım geliştirme araçları iyileşmiş gibi. jazz.tools, electric-sql ve Rocicorp’un Zero’sunu takip ediyorum; başka neler var merak ediyorum

    • Sunucuda CouchDB ve istemcide PouchDB, böyle bir ortam yaratma girişimiydi
      https://couchdb.apache.org/
      https://pouchdb.com/
      Yaklaşık 10 yıl önce yerel öncelikli uygulama geliştirme üzerine daha fazla düşünceyi burada da görebilirsiniz: https://unhosted.org/
    • Son bir ay kadar kişisel bütçe uygulaması yan projemde instantdb’yi oldukça ciddi biçimde kullandım
      Bir blog yazısı yazmam gerekiyor ama daha önce PowerSync, electricSQL, LiveStore ve PowerSync’i araştırmıştım; jazz.tools’a da kısaca bakmıştım ama daha yapılandırılmış bir şey istiyordum
      Şimdiye kadar oldukça etkileyici. Vue ve bir topluluk kütüphanesiyle geliştiriyorum; izinler biraz uğraştırdı ama anlayınca basitti. Sihirli e-posta girişini de seviyorum; pano/yanıt özellikleri de iyi, ancak daha az zahmetli hale getirmek için birkaç büyük değişiklik gerekiyor gibi görünüyor
      Açık kaynak olması ve isterseniz self-host edebilmeniz hoşuma gidiyor. jazz’da yapı eksikti; LiveStore’da olay deposu çok zahmetli görünüyordu ama çekiciliği de vardı. Geliştirici araçlarının ücretli duvarın arkasında olması üzücüydü ama anlaşılır. electricSQL çözümün yarısını, yani yalnızca okumayı sunuyordu; yazma modeli eksikti. CouchDB/PouchDB’de de bana göre yapı eksikti ve belgeler arası desteğin daha net biçimde yerleşik olmasını isterdim. Zero’yu düzgünce araştırmadım
    • Bu siteyi biliyor musunuz merak ediyorum: https://www.localfirst.fm
      Aslında üst menüdeki “landscape” bağlantısını işaret etmek istemiştim ama URL’si epey kullanışsız
    • Bir süre önce birinin Automerge’den bahsettiğini gördüm
      https://automerge.org/
      Rust ve JavaScript implementasyonları var; birkaç ağ stratejisi de sunuyor. jazz.tools gibi ücretsiz/ücretli ürün paketiyle gelmiyor ama oldukça iyi
    • Ditto da bakmaya değer
      https://www.ditto.com
      CRDT’yi merkezine alan, gerçek zamanlı senkronizasyonu destekleyen yerel öncelikli bir platform olduğu için çakışma çözümünü yönetmek çok daha kolay hale geliyor. Çevrimdışı öncelikli kullanım senaryolarını ve peer-to-peer senkronizasyonu varsayılan olarak ele almak üzere tasarlanmış; bu yüzden senkronizasyon motorunu baştan kendiniz yazmanız gerekmiyor
      Swift, Kotlin(Android), Flutter/Dart, React Native, JavaScript(Web/Node), .NET(C#), C++, Java, Rust gibi çeşitli platformları destekliyor. Belgeleri burada daha fazla görebilirsiniz: https://docs.ditto.live/home/about-ditto