LiveView, Svelte ile en iyi uyumu yakalayan teknoloji

LiveView ve Svelte kombinasyonu

• LiveView, web uygulamaları geliştirmek için benzersiz bir yaklaşım sunuyor.
• Sunucu durumu elinde tutuyor, frontend davranışlarını backend tarafında işliyor ve DOM'u kademeli olarak güncelliyor.
• SPA'lerin karmaşıklığı dağıtık sistemlerin karmaşıklığından kaynaklanıyor; LiveView ise frontend mikroservisleri olmadan zengin bir istemci deneyimi sunuyor.

LiveView'un zorlayıcı yönleri

• İstemci tarafı durumu kaçınılmaz ve sunucu ile kullanıcı arasındaki gecikme önlenemez.
• LiveView, çok sayıda DOM değişikliğini sunucu tarafında üstlense de her şeyi kontrol edemez.
• LiveView'un üç bileşen türü var: LiveViews, LiveComponents ve Components.
• LiveView ile LiveComponents arasında refaktör yapmak beklenenden daha zahmetli.

LiveView'un muğlak yönelimi

• LiveView çoğu zaman bir şeylerin eksik olduğu hissini veriyor.
• LiveView, modern frontend framework'leriyle birçok ortak noktaya sahip; ancak farklarını anlamak ve problemlere farklı yaklaşmak gerekiyor.

LiveView + Svelte

• LiveSvelte, LiveView içinde Svelte bileşenlerinin render edilmesini sağlıyor.
• Backend, frontend bileşenlerinin props'larını kontrol ediyor ve hem frontend hem backend tarafında durum bulunuyor.
• Frontend ile backend arasında özel ve çift yönlü bir iletişim kanalı var.

LiveSvelte'in yenilikçi özellikleri

• Backend ile frontend arasındaki sorumluluk paylaşımı net ve karmaşıklık sunucu tarafında yoğunlaşıyor.
• LiveView, backend için bir frontend olarak en güçlü halini gösteriyor; frontend bileşenlerini render eden ve durumu koruyan backend süreçleri sağlıyor.

GN⁺ görüşü

• LiveView ile Svelte'in birleşimi, sunucu ve istemci arasındaki durum yönetimini verimli biçimde ayırarak geliştiricilerin uygulamaları daha hızlı ve daha sezgisel şekilde kurmasını sağlıyor.
• Bu teknoloji özellikle gerçek zamanlı etkileşimin kritik olduğu web uygulamalarında faydalı olabilir ve kullanıcı deneyimini iyileştirmeye katkı sunabilir.
• Ancak sunucuyla olan gecikme kullanıcı deneyimini etkileyebileceği için performans optimizasyonu ve bölgesel sunucu konumlandırması önemli değerlendirme noktaları olabilir.
• LiveView ile Svelte'in birleşimi, mevcut SPA geliştirme yaklaşımına alışkın geliştiricilere yeni bir paradigma sunuyor; bu da öğrenme eğrisini düşürme ve geliştirme verimliliğini artırma potansiyeli taşıyor.
• Bu teknolojinin sunduğu gerçek zamanlı durum senkronizasyonu ve çift yönlü iletişim, özellikle iş birliği araçları, dashboard'lar veya gerçek zamanlı veriyle çalışan uygulamalar için cazip bir tercih olabilir.

[GN⁺]

Hacker News yorumu

• Çok oyunculu video oyunlarında kullanılan kalıplardan biri, hem istemcide hem de sunucuda temelde çalışan kodun bulunmasıdır.

  • İstemci kodu, sunucu durumunun bir tahmini olarak çalışır.
  • Sunucu durumu alındığında istemci durumuna zorla uygulanır.
  • Oyunlarda "tahmin" uygun bir ifadedir; istemci girdinin sonucunu iyi tahmin edebilir, ancak diğer oyuncuların girdilerini bilemediği için bundan emin olamaz.
  • Bu paradigma, resmi sunucu durumunu beklerken istemci girdisine anında tepki vermek için de kullanılabilir (ör. dropdown etkinleştirme/devre dışı bırakma, yükleme spinner'ı gösterme).
  • Sunucuda çalışmayan çok sayıda istemci durumu da vardır (ör. particle system, ragdoll - tüm istemcilerde birebir aynı olması gerekmeyen ve diğer oyuncu girdileri/fizikle etkileşmeyen şeyler).

• LiveView ve Svelte'in nasıl birleştirileceğine dair ElixirConf 2022'de bir sunum yaptım ve live_svelte katkıcıları bunun gerçeğe dönüşmesine katkı sağladı.

  • İstemci tarafı durum, özellikle zengin UX'e sahip uygulamalarda her zaman gereklidir.
  • New York'ta özellikle hareket halindeyken ağ bağlantısı garanti değildir.
  • Phoenix'in pubsub özelliğini kullanarak başka sunucularda gerçekleşen sunucu tarafı durum değişikliklerini istemciye reaktif biçimde push edebilmek çok güçlüdür.

• Yeni satırlar geldiğinde LiveView istemciyi güncelliyor, bu yüzden onları yalnızca tabloya push etmeniz yeterli.

  • Etkileşimli satırlara sahip iş uygulamalarında bu yöntemin kullanılmamasını tavsiye ederim.
  • Kullanıcının yanlış bir şeye tıklaması, yanlış müşteriye e-posta göndermesi veya yanlış işlemi iade etmesi gibi algısal gecikmelere yol açabilir.
  • Verinin değiştiğini söyleyen bir sticker banner kullanmak ya da acilse kaydırma konumunu değiştirmeden yalnızca yeni satırlar eklemek iyi bir UX'tir.

• BeaconCMS'te Svelte ve LiveView'ü birlikte kullanıyoruz.

  • İstemcide UI üzerinde daha ince ayarlı kontrol istediğinizde bunun iyi kullanım alanları var.
  • Phoenix kullansanız bile cevap her zaman LiveView değildir; bazen statik render edilen bir sayfa tamamen yeterlidir.
  • Her şey için ya hep ya hiç yaklaşımını benimsememeyi tavsiye ederim.
  • Yazının işaret ettiği gibi, 'LiveView yaklaşımı'nın dışına çıkan bazı iyi kullanım alanları var.
  • Eğer 1000ms'lik bir round trip süreniz varsa başka değerlendirmeler gerekebilir; ancak coğrafi olarak yakın sunucular maliyet gibi nedenlerle kullanılamıyor olabilir, bu durumda istemci tarafı durum yönetimi eklemek çözüm olabilir.

• İstemcide durumu yönetmek yerine, hem istemcide hem de sunucuda durumu yönetiyorsunuz.

  • Bunun bir iyileştirme olduğunu söylemek zor; başka bir API kurma gerekliliğini ortadan kaldırıyor ama bu tek başına bir gelişme anlamına gelmiyor.

• Bu yaklaşımın sınırı ışık hızıdır: sunucunun kullanıcıya ne kadar yakın olabileceğinin bir sınırı vardır.

  • Bir sonraki adım, sunucuyu WebAssembly'ye derleyip istemciye göndermek ve gerçek sunucu yanıtı dönene kadar iyimser biçimde yanıtı render etmektir.
  • Biraz çılgınca gelebilir ama bunu bir projede gerçekten başarıyla yaptık ve büyüleyici bir deneyim.

• LiveSvelte'in geliştiricisi olarak, sorularınız varsa bana iletin.

• Genel olarak uygulamaları bu modelle inşa etmek istiyordum: olay odaklı, çift yönlü gerçek zamanlı güncellemeler ve sunucu, sıralı olaylar, yerel ve uzak durum...

  • LiveView'den haberim yoktu ve Erlang ekosisteminden bir dil hiç kullanmamıştım, ama belli ki bir şeyleri doğru yakalamışlar.
  • Geleneksel istek-yanıt modeli tutarlılık ve bayat veri konusunda çok fazla sorun çıkarıyor.
  • Umutlu ama muhtemelen tartışmalı bir düşünce: Eğer son 10 yıl ana akım dillere FP kavramlarını entegre etmekle geçtiyse, önümüzdeki 10 yılın da duruma sahip mesaj odaklı (reaktif?) programlamayı ana akım full-stack geliştirmeye entegre etmekle geçmesini umuyorum.

• Uygulamada LiveView ile birlikte yeniden kullanılabilir Stimulus controller'lar kullanıyoruz ve bu da sorunsuz çalışıyor.

  • Genel olarak LiveView ile geliştirmek keyifli, ancak onu gerçek senaryolarda ne kadar çok kullanırsam durum bilgisiz HTTP framework'lerinin avantajlarını o kadar iyi anlıyorum.
  • Hotwire gibi framework'ler daha iyi performans ve yeniden bağlanmaya karşı daha yüksek dayanıklılık sunuyor, ayrıca kullanıcıya daha yakın sunucular yerleştirme ihtiyacını da ortadan kaldırıyor.

• Harika bir proje! Bununla ilgili bir Svelte Radio bölümü az önce yayınladım.