- Senkronizasyon mantığı geliştirme yükü olmadan yüksek performanslı uygulamalar geliştirebilmeyi sağlayacak şekilde tasarlanmış bir durum yönetimi veri katmanı
- Reaktif SQLite ve yerleşik bir senkronizasyon motoru kullanmasıyla öne çıkıyor
- Local-first yapısıyla çevrimdışıyken de yüksek performans sunuyor ve ağ geri geldiğinde otomatik senkronizasyonu destekliyor
- Tüm durum yönetimi işlemleri yerel SQLite veritabanı üzerinde hızlıca gerçekleştiriliyor
- Reaktif veri akışları: Veri değiştiğinde, UI'ya bağlı dinleyicilere anında olay göndererek durum değişikliklerinin gerçek zamanlı yansıtılmasını sağlıyor
- Web, mobil, masaüstü gibi farklı ortamlara uygulanabiliyor
- Mevcut durum yönetimi araçlarına kıyasla yerel performans ve veri tutarlılığı açısından daha üstün sonuçlar sunuyor
2 yorum
Ana sayfadaki demo gerçekten çok iyi hazırlanmış. Demoya biraz tıklayınca, denemek isteyecek kadar ilgimi çekti.
Hacker News görüşleri
Merhaba, ben LiveStore'un kurucu ortaklarından biriyim (daha önce Prisma'yı yapmıştım).
Son 4 yıldır Overtone adlı yerel uygulama düzeyinde yüksek performanslı bir müzik istemcisi geliştirirken, kendi kullanımım için LiveStore'u da geliştirmiş oldum.
LiveStore, SQLite'a reaktif sinyal katmanı ekliyor ve bunu olay kaynaklı senkronizasyonla (Git'e benzer) birleştiriyor
Çeşitli local-first yaklaşımları değerlendirdim ama LiveStore kadar temiz çözen neredeyse hiçbir çözüm görmedim
Benzer olgunlukta bir araç olarak tinyBase var ama onun yapısı farklı (CRDT'ler vs olay kaynaklı yaklaşım)
Merak ettiğim şey, veri boyutunu neden 1 GB ile sınırladığınız ve daha büyük verileri SQLite'ta saklayıp diskte tutmaya izin veren bir seçenek olup olamayacağı
Kalıcılık modunu yalnızca bir ayarla değiştirmek mümkün değil mi?
Çok kiracılı yapı da ilginç bir senaryo olabilir; JIRA gibi her organizasyonun ayrı bir ad alanı istediği durumlarda, her kullanıcının da tüm biletleri değil yalnızca kendi ekip/bölümüne ait olanları alabilmesi iyi olurdu
Temelde yerel veritabanı, tüm verinin bir alt kümesi oluyor; kutudan çıktığı gibi Bun/Node üzerinde çalışabilen bir senkronizasyon sunucusu olsaydı (Cloudflare gerektirmeden) gerçekten harika olurdu
Şu anda değerlendirdiğim bir proje fikrine de çok uygun görünüyor; özellikle çok kiracılı yapı zorunlu olduğu için
Geçen ay LiveStore'u hobi projemde kullanmayı düşünerek baktım ama beta önizleme olduğu için erişmek zordu
Umarım yakında daha derinlemesine inceleyebilirim; local-first tartışmalarına aktif biçimde yön vermeniz etkileyici
Çevrimdışı senkronizasyon yapabilen web uygulamaları geliştirmiş biri, senkronizasyon motorunun faydasını hemen anlar
Bugün Local-First Conf'taki sunumunuzu gerçekten beğendim
Olay kaynaklı yapıyı SQLite ile kurma yaklaşımına dair açıklamanız net ve ikna ediciydi
SQLite'ı, özellikle de OPFS Wasm SQLite'ı web'de aktif biçimde öne çıkardığınız için teşekkürler
PowerSync de SQLite'ı güçlü biçimde destekliyor; bu yüzden LiveStore gibi başarılı örnekleri görmek sevindirici
LiveStore olay kaynaklı modeli küresel ölçekte genişletirken, tüm istemciler genelde merkezi bir senkronizasyon arka ucu üzerinden senkronize oluyor; bunun zorunlu bir gereksinim olup olmadığını merak ediyorum
Acaba federe düğümler veya tamamen P2P modu da mümkün mü? Dağıtık sosyal ağ örneklerine uygulamayı düşünüyorum
React ve WASM ile birlikte LiveStore'un, çoğu müzik uygulamasının kullandığı Juce framework'ünün yerini alıp alamayacağını merak ediyorum
Ben bir beatmaker'ım ve Juce + C++ kombinasyonu bana her zaman zor ve göz korkutucu gelmiştir; müzik uygulaması geliştirmeye girmek isteyen biri için LiveStore iyi bir alternatif olabilir mi, bilmek isterim
Local-first Conf'taki sunumu izledim; son dönemde gerçekten çok çeşitli senkronizasyon motorları ortaya çıkıyor
LiveStore, olay kaynaklı yaklaşım ile senkronizasyon motorunu birleştiren ilginç bir alanı derinlemesine araştırıyor
Şimdiden bu kadar sağlam bir sistem haline gelmiş olması beni şaşırttı
Son birkaç haftadır yeni bir projede bizzat kullandım ve gerçekten çok akıcı çalışıyor
Lansman için tebrikler! Bu sistemin burada anlatılan "1. Serialization" stratejisine uyup uymadığını merak ediyorum
ProseMirror-collab'da bahsedildiği gibi, sık güncelleme yapan düşük gecikmeli istemcilerin, yüksek gecikmeli istemcilerin güncellemelerini engellemesi sorunu LiveStore'da da ortaya çıkar mı diye sormak istiyorum
LiveStore'un wa-sqlite kullandığı anlaşılıyor
Çevrimdışı veri kalıcılığı stratejisini daha ayrıntılı duymak isterim; özellikle OPFS (AccessHandlePoolVFS gibi varyantlar), IndexedDB ya da her ikisinden hangisini kullandığınızı merak ediyorum
Ayrıca OPFS'nin tarayıcılar arası istikrarsızlığına ve Safari IndexedDB'nin 7 günlük saklama politikasına nasıl yaklaştığınızı da merak ediyorum
SQLite resmi WASM derlemesi sunarken neden wa-sqlite kullandığınızı da bilmek isterim
Kısa süre önce LocalFirst.fm podcast'inde LiveStore'dan kısaca bahsettim (https://www.localfirst.fm/24 bağlantısına bakabilirsiniz)
Oldukça heyecan verici bir proje gibi görünüyor ama aşırı beklenti tuzağına düşme konusunda biraz temkinliyim
Benzer şekilde, özel geliştirilmiş bir local-first uygulama üzerinde çoklu cihaz desteğini deniyorum
Uçtan uca şifrelemeyi isteğe bağlı olarak eklemek mümkün olur mu diye merak ediyorum; belgelere bakınca olay yükü düzeyinde şifreleme ekleyerek, sunucu log sıkıştırmasını zorlaştırması dışında neredeyse mümkün gibi görünüyor
Ben LiveStore'u, Overtone üzerinde çalışırken ortaya çıkan ihtiyaçlardan yola çıkarak kendim geliştiriyorum
Hem LiveStore hem Overtone, uzun vadeli sürdürülebilirlik hedefiyle geliştiriliyor; E2E şifreleme ise zaten mümkün bir yapıda
Bunu bizzat denemedim ama bir sorun çıkarsa her zaman yardımcı olabilirim
Log sıkıştırmasını yalnızca istemci tarafında denemek de bir yöntem olabilir; bu kullanım senaryosunu mühendislik sürecinde mutlaka akılda tutacağım
Çapraz platform desteği iddiasına şüpheyle yaklaşıyorum; gösterilen ilk şeylerden biri Android web desteğinin olmamasıydı
Gelişmeyi resmi GitHub'da görebilirsiniz (https://github.com/livestorejs/livestore/issues/321)
Web API desteği platformdan platforma değiştiği için, böyle iddialı bir sistemi kurmanın çok fazla emek ve zaman gerektirdiğini anlayışla karşılamanızı umuyorum
Demo videosunda ilginç bir ayrıntı fark ettim! 1 dakika 7 saniyede ses sola kayıyor gibi geldi; küçük bir şey ama bilginiz olsun istedim
Geliştirici araçlarını da birlikte sunmanız etkileyici; belli ki bunu uzun süredir kendi projelerinizde test ediyorsunuz
Merak ettiğim şey, uzun süre çalışan uygulama/sayfalarda compaction işini nasıl ele almayı düşündüğünüz ve olay kaynaklı yaklaşım harika olsa da, uygulama katmanı geliştikçe kod yönetiminin (eski istemciler, şema geçişleri vb.) zorlaşabilmesi
Overtone'un birden fazla kaynağı desteklediği anlaşılıyor; çevrimdışı oynatma da sunacak mı diye merak ediyorum, özellikle Spotify arayüzünü kullanışsız bulduğum için bir alternatife gerçekten ihtiyaç var
Temel fikir, olaylar arasındaki örtüşmeyi tanımlayabilmek için her olaya daha fazla anlamsal bilgi kazandırmak
Örneğin bir todo uygulamasında, aynı görev kimliğine ait bir "todoCompleted" olayı, o görevin "todoCompleted"/"todoUncompleted" olaylarını sıkıştırabilir
İlerlemeyi GitHub'da takip edebilirsiniz (https://github.com/livestorejs/livestore/issues/254)
Olay kaynaklı yaklaşımda gerçekten disiplin ve tasarım önemli; veride "bedava öğle yemeği" yok, asıl mesele trade-off'lar
Overtone gibi temel kullanım alanlarımda, olay kaynaklı yaklaşımın trade-off'ları bana daha uygun geliyor
Eski sürüm desteği gibi konular için basit yöntemler var; sonuçta her şey uygulamanın özelliklerine ve trade-off'larına bağlı
Overtone'a ilgi gösterdiğiniz için teşekkürler. Ben de bu projeye Spotify'dan memnun kalmadığım için başladım; çevrimdışı oynatma konusu ise müzik sağlayıcısına göre değişir
Örneğin Dropbox gibi kendi sahip olduğunuz albümler desteklenebilir ama Spotify gibi akış servislerinde durum politikalara bağlı olabilir
Bu mimari hoşuma gitti, özellikle olay kaynaklı yaklaşım çok iyi
Ama olay kaynaklı yapıda dikkatli olmak gerekir; istenen görünüme bağlı olarak materialize etme (view materialization) yavaş olabilir ve veri büyüdükçe daha da yavaşlar
Bunun çözümü, tetikleyiciler gibi araçlarla transaction içinde materialized view güncellemelerini doğrudan yönetmek olabilir
Çoğaltma veya senkronizasyon sırasında da bunu düşünmek gerekir; ayrıca çatışma çözümü konusunda da CRDT kavramlarını mutlaka öğrenmekte fayda var
Postgres dil özelliklerine sahip SQLite3 benzeri bir veritabanı olsa, local-first ve remote-first yaklaşımlar arasında yalnızca ayar değiştirerek geçiş yapmak gerçekten harika olurdu
Materialize etme maliyeti konusundaki asıl noktaya gelirsek, compaction'ı ileride daha da iyileştireceğiz ve LiveStore'un tamamı performans optimizasyonu hedefiyle dikkatle tasarlanmış bir framework