LiveView, Svelte के साथ सबसे बेहतर मेल खाने वाली तकनीक

 (blog.sequin.io)
2 पॉइंट द्वारा GN⁺ 2024-04-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें

LiveView और Svelte का संयोजन

  • LiveView वेब applications बनाने का एक अनोखा तरीका प्रदान करता है.
  • सर्वर state को संभालता है, फ्रंटेंड के व्यवहार को बैकएंड में प्रोसेस करता है और DOM को क्रमिक रूप से अपडेट करता है.
  • SPA की जटिलता distributed system की जटिलता से आती है, और LiveView फ्रंटेंड microservices के बिना भी समृद्ध client experience देता है.

LiveView की कठिनाइयाँ

  • client-side state अपरिहार्य है, और सर्वर व उपयोगकर्ता के बीच latency से बचा नहीं जा सकता.
  • LiveView सर्वर से बहुत से DOM बदलाव संभालता है, लेकिन वह सब कुछ नियंत्रित नहीं कर सकता.
  • LiveView में तीन तरह के component होते हैं: LiveViews, LiveComponents, और Components.
  • LiveView और LiveComponents के बीच refactoring अपेक्षा से अधिक झंझटभरी है.

LiveView की अस्पष्ट दिशा

  • LiveView अक्सर यह एहसास देता है कि इसमें कुछ कमी है.
  • LiveView में आधुनिक फ्रंटेंड framework से कई समानताएँ हैं, लेकिन उसके अंतर को समझकर समस्याओं को अलग तरीके से देखना ज़रूरी है.

LiveView + Svelte

  • LiveSvelte, LiveView में Svelte components को render करने देता है.
  • बैकएंड फ्रंटेंड components के props को नियंत्रित करता है, और फ्रंटेंड व बैकएंड दोनों के पास state होती है.
  • फ्रंटेंड और बैकएंड के बीच निजी और bidirectional communication channel मौजूद होता है.

LiveSvelte की नवोन्मेषी विशेषताएँ

  • बैकएंड और फ्रंटेंड के बीच जिम्मेदारियों का बँटवारा स्पष्ट है, और जटिलता मुख्यतः सर्वर side पर केंद्रित रहती है.
  • LiveView बैकएंड के लिए फ्रंटेंड के रूप में सबसे अधिक चमकता है, क्योंकि यह फ्रंटेंड components को render करने और state बनाए रखने वाली backend process उपलब्ध कराता है.

GN⁺ की राय

  • LiveView और Svelte का संयोजन सर्वर और client के बीच state management को प्रभावी ढंग से अलग करता है और developers को applications अधिक तेज़ी और सहजता से बनाने में मदद करता है.
  • यह तकनीक खास तौर पर उन web applications में उपयोगी हो सकती है जहाँ real-time interaction महत्वपूर्ण हो, और यह user experience बेहतर बनाने में योगदान दे सकती है.
  • हालाँकि, सर्वर के साथ latency user experience को प्रभावित कर सकती है, इसलिए performance optimization और क्षेत्रीय server deployment महत्वपूर्ण विचार हो सकते हैं.
  • LiveView और Svelte का संयोजन पारंपरिक SPA development से परिचित developers के लिए एक नया paradigm प्रस्तुत करता है, जिसमें learning curve कम करने और development efficiency बढ़ाने की क्षमता है.
  • इस तकनीक द्वारा दी गई real-time state synchronization और bidirectional communication विशेष रूप से collaboration tools, dashboards, या real-time data संभालने वाले applications के लिए आकर्षक विकल्प हो सकते हैं.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-05
Hacker News की राय

  • मल्टीप्लेयर वीडियो गेम में इस्तेमाल होने वाले पैटर्न्स में से एक यह है कि कुछ code ऐसा होता है जो मूल रूप से client और server दोनों पर चलता है.

    • client code, server state के prediction के रूप में चलता है.
    • server state मिलते ही client state को forcefully apply किया जाता है.
    • गेम्स में "prediction" सही शब्द है, क्योंकि client input के नतीजे का अच्छा अनुमान लगा सकता है, लेकिन दूसरे players के input को नहीं जानता, इसलिए यह पक्का नहीं होता.
    • इस paradigm का इस्तेमाल server की authoritative state का इंतज़ार करते समय client input पर तुरंत प्रतिक्रिया देने के लिए भी किया जा सकता है (जैसे dropdown enable/disable करना, loading spinner दिखाना).
    • बहुत-सी client state ऐसी भी होती है जो server पर नहीं चलती (जैसे particle system, ragdoll — जिन्हें हर client पर बिल्कुल एक जैसा होने की ज़रूरत नहीं होती और जो दूसरे players के input/physics के साथ interact नहीं करते).

  • LiveView और Svelte को जोड़ने के तरीके पर ElixirConf 2022 में एक प्रस्तुति दी गई थी, और live_svelte contributors ने इसे वास्तविकता बनाने में योगदान दिया.

    • client-side state की ज़रूरत हमेशा रहती है, खासकर rich UX वाले apps में.
    • New York City में, खासकर यात्रा के दौरान, network connectivity की गारंटी नहीं होती.
    • Phoenix के pubsub का उपयोग करके दूसरे server पर हुए server-side state changes को client तक reactively push करने की क्षमता बहुत शक्तिशाली है.

  • जब नई row आती है तो LiveView client को update कर देता है, इसलिए बस उसे table में push करना होता है.

    • interactive rows वाले business apps में इस तरीके का उपयोग न करने की सलाह दी जाती है.
    • इससे cognitive lag हो सकता है, जैसे user गलत चीज़ पर click कर दे, गलत customer को email भेज दे, या गलत transaction refund कर दे.
    • यह बताने के लिए sticker banner का उपयोग करना कि data बदल गया है, या जल्दी की स्थिति में scroll position बदले बिना केवल नई rows जोड़ना, अच्छा UX है.

  • BeaconCMS में Svelte और LiveView का साथ में उपयोग होता है.

    • जब client पर UI को ज़्यादा बारीकी से control करना हो, तब इसके अच्छे use cases हैं.
    • Phoenix इस्तेमाल करने पर भी LiveView हमेशा जवाब नहीं होता; कभी-कभी statically rendered page पूरी तरह ठीक होता है.
    • हर चीज़ के लिए all-or-nothing approach न अपनाने की सलाह दी जाती है.
    • जैसा लेख में बताया गया है, 'LiveView way' से बाहर जाने के कुछ अच्छे use cases हैं.
    • अगर round trip 1000ms हो, तो अलग considerations हो सकती हैं, लेकिन cost जैसी वजहों से geographically located servers इस्तेमाल न किए जा सकें, तो client-side state management जोड़ना समाधान हो सकता है.

  • client पर state manage करने के बजाय, state को client और server दोनों पर manage किया जाता है.

    • इसे improvement कहना कठिन है; हाँ, यह एक और API बनाने की ज़रूरत कम कर देता है, लेकिन इससे यह अपने-आप बेहतर नहीं हो जाता.

  • इस approach की सीमा light speed में है: server इस बात में सीमित है कि वह user के कितना करीब हो सकता है.

    • अगला कदम server को WebAssembly में compile करके client को भेजना है, ताकि असली server response आने तक optimistic response render किया जा सके.
    • यह थोड़ा पागलपन जैसा लग सकता है, लेकिन इसे एक project में सफलतापूर्वक किया गया है, और अनुभव जादुई लगता है.

  • LiveSvelte बनाने वाले व्यक्ति के रूप में, अगर कोई सवाल हो तो बताने के लिए कहा गया है.

  • सामान्य रूप से, इस model के साथ app बनाना चाहा गया: event-driven, bidirectional real-time updates और server, ordered events, local और remote state...

    • LiveView के बारे में पता नहीं था, और Erlang family की languages कभी इस्तेमाल नहीं की थीं, लेकिन साफ है कि उन्होंने कुछ महत्वपूर्ण खोजा है.
    • पारंपरिक request-response model consistency और stale data की बहुत-सी समस्याएँ पैदा करता है.
    • एक आशावादी, लेकिन शायद विवादास्पद विचार: अगर पिछले 10 साल mainstream languages में FP concepts को शामिल करने के बारे में थे, तो उम्मीद है कि अगले 10 साल stateful message-oriented (reactive?) programming को mainstream full stack में शामिल करने के बारे में होंगे.

  • app में LiveView के साथ reusable Stimulus controllers का उपयोग किया जा रहा है, और यह भी सहज रूप से काम करता है.

    • सामान्य रूप से LiveView के साथ build करना आनंददायक है, लेकिन इसे वास्तविक scenarios में जितना अधिक इस्तेमाल किया जाता है, उतना ही stateless HTTP frameworks के फायदे समझ में आते हैं.
    • Hotwire जैसे frameworks बेहतर performance और reconnection resilience देते हैं, और user के ज़्यादा करीब server तैनात करने की ज़रूरत से बचाते हैं.

  • शानदार project है! इस पर अभी Svelte Radio का एक episode जारी किया गया है.