LiveView เทคโนโลยีที่เข้ากับ Svelte ได้ดีที่สุด

 (blog.sequin.io)
2 คะแนน โดย GN⁺ 2024-04-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การผสาน LiveView และ Svelte

  • LiveView มอบวิธีที่ไม่เหมือนใครในการสร้างเว็บแอปพลิเคชัน
  • เซิร์ฟเวอร์เป็นผู้เก็บสถานะ จัดการพฤติกรรมฝั่งฟรอนต์เอนด์จากแบ็กเอนด์ และอัปเดต DOM แบบค่อยเป็นค่อยไป
  • ความซับซ้อนของ SPA มาจากความซับซ้อนของระบบกระจาย และ LiveView มอบประสบการณ์ไคลเอนต์ที่สมบูรณ์โดยไม่ต้องมีฟรอนต์เอนด์ไมโครเซอร์วิส

สิ่งที่ยากของ LiveView

  • สถานะฝั่งไคลเอนต์เป็นสิ่งที่หลีกเลี่ยงไม่ได้ และหลีกเลี่ยงความหน่วงระหว่างเซิร์ฟเวอร์กับผู้ใช้ไม่ได้
  • LiveView ให้เซิร์ฟเวอร์รับผิดชอบการเปลี่ยนแปลง DOM จำนวนมาก แต่ไม่สามารถควบคุมทุกอย่างได้
  • LiveView มีคอมโพเนนต์อยู่ 3 ประเภท: LiveViews, LiveComponents และ Components
  • การรีแฟกเตอร์ระหว่าง LiveView กับ LiveComponents ยุ่งยากกว่าที่คาดไว้

ทิศทางที่กำกวมของ LiveView

  • LiveView มักทำให้รู้สึกว่ามีบางอย่างขาดหายไป
  • LiveView มีจุดร่วมหลายอย่างกับเฟรมเวิร์กฟรอนต์เอนด์สมัยใหม่ แต่ต้องตระหนักถึงความแตกต่างและเข้าหาปัญหาในแบบที่ต่างออกไป

LiveView + Svelte

  • LiveSvelte ทำให้สามารถเรนเดอร์คอมโพเนนต์ Svelte ใน LiveView ได้
  • แบ็กเอนด์ควบคุม props ของคอมโพเนนต์ฟรอนต์เอนด์ และทั้งฟรอนต์เอนด์กับแบ็กเอนด์ต่างก็มีสถานะของตัวเอง
  • มีช่องทางสื่อสารแบบส่วนตัวและสองทางระหว่างฟรอนต์เอนด์กับแบ็กเอนด์

คุณลักษณะที่พลิกเกมของ LiveSvelte

  • การแบ่งความรับผิดชอบระหว่างแบ็กเอนด์กับฟรอนต์เอนด์ชัดเจน และความซับซ้อนถูกรวมไว้ที่ฝั่งเซิร์ฟเวอร์
  • LiveView โดดเด่นที่สุดเมื่อเป็นฟรอนต์เอนด์สำหรับแบ็กเอนด์ โดยมอบโปรเซสฝั่งแบ็กเอนด์ที่เรนเดอร์คอมโพเนนต์ฟรอนต์เอนด์และคงสถานะไว้

ความเห็นของ GN⁺

  • การผสาน LiveView กับ Svelte แยกการจัดการสถานะระหว่างเซิร์ฟเวอร์กับไคลเอนต์ได้อย่างมีประสิทธิภาพ และช่วยให้นักพัฒนาสร้างแอปพลิเคชันได้รวดเร็วและเป็นธรรมชาติมากขึ้น
  • เทคโนโลยีนี้อาจมีประโยชน์อย่างยิ่งกับเว็บแอปพลิเคชันที่การโต้ตอบแบบเรียลไทม์เป็นเรื่องสำคัญ และอาจช่วยยกระดับประสบการณ์ผู้ใช้ได้
  • อย่างไรก็ตาม ความหน่วงในการสื่อสารกับเซิร์ฟเวอร์อาจส่งผลต่อประสบการณ์ผู้ใช้ ดังนั้นการเพิ่มประสิทธิภาพและการวางเซิร์ฟเวอร์ให้ใกล้ผู้ใช้จึงเป็นประเด็นสำคัญ
  • การผสาน LiveView กับ Svelte นำเสนอพาราไดม์ใหม่ให้แก่นักพัฒนาที่คุ้นเคยกับการพัฒนาแบบ SPA ซึ่งมีศักยภาพในการลดเส้นโค้งการเรียนรู้และเพิ่มประสิทธิภาพการพัฒนา
  • การซิงก์สถานะแบบเรียลไทม์และการสื่อสารสองทางที่เทคโนโลยีนี้มอบให้ อาจเป็นตัวเลือกที่น่าสนใจอย่างยิ่งสำหรับเครื่องมือทำงานร่วมกัน แดชบอร์ด หรือแอปพลิเคชันที่จัดการข้อมูลแบบเรียลไทม์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-04-05
ความคิดเห็นใน Hacker News

  • หนึ่งในแพตเทิร์นที่ใช้ในวิดีโอเกมแบบผู้เล่นหลายคน คือมีโค้ดที่โดยพื้นฐานแล้วทำงานทั้งบนไคลเอนต์และเซิร์ฟเวอร์

    • โค้ดฝั่งไคลเอนต์จะทำงานจากการคาดการณ์สถานะของเซิร์ฟเวอร์
    • เมื่อได้รับสถานะจากเซิร์ฟเวอร์แล้ว ก็จะบังคับใช้สถานะนั้นกับฝั่งไคลเอนต์
    • ในเกม คำว่า "การคาดการณ์" เป็นคำที่เหมาะสม เพราะไคลเอนต์สามารถเดาผลลัพธ์ของอินพุตตัวเองได้ค่อนข้างดี แต่ไม่อาจแน่ใจได้เพราะไม่รู้ถึงอินพุตของผู้เล่นคนอื่น
    • กระบวนทัศน์นี้ยังสามารถใช้เพื่อตอบสนองต่ออินพุตของไคลเอนต์ได้ทันทีระหว่างที่รอสถานะอย่างเป็นทางการจากเซิร์ฟเวอร์ (เช่น เปิด/ปิด dropdown, แสดง loading spinner)
    • ยังมีสถานะฝั่งไคลเอนต์อีกมากที่ไม่ได้รันบนเซิร์ฟเวอร์ด้วย (เช่น particle system, ragdoll — สิ่งที่ไม่จำเป็นต้องเหมือนกันทุกไคลเอนต์เป๊ะ และไม่ได้โต้ตอบกับอินพุต/ฟิสิกส์ของผู้เล่นคนอื่น)

  • เคยมีการบรรยายในงาน ElixirConf 2022 เกี่ยวกับวิธีผสาน LiveView กับ Svelte และผู้มีส่วนร่วมของ live_svelte ก็ช่วยทำให้สิ่งนี้เกิดขึ้นจริง

    • สถานะฝั่งไคลเอนต์ยังคงจำเป็นเสมอ โดยเฉพาะกับแอปที่มี UX ที่หลากหลาย
    • ในนิวยอร์กซิตี้ โดยเฉพาะระหว่างการเดินทาง การเชื่อมต่อเครือข่ายไม่ได้รับประกันเสมอไป
    • ความสามารถในการใช้ pubsub ของ Phoenix เพื่อ push การเปลี่ยนแปลงสถานะฝั่งเซิร์ฟเวอร์ที่เกิดจากเซิร์ฟเวอร์อื่นไปยังไคลเอนต์แบบ reactive นั้นทรงพลังมาก

  • เมื่อมีแถวใหม่เข้ามา LiveView จะอัปเดตไคลเอนต์ ดังนั้นแค่ push เข้าไปในตารางก็พอ

    • แต่แนะนำว่าไม่ควรใช้วิธีนี้กับแอปธุรกิจที่มีแถวแบบโต้ตอบได้
    • อาจเกิดความหน่วงในการรับรู้ ทำให้ผู้ใช้คลิกสิ่งผิด ส่งอีเมลหาลูกค้าผิดคน หรือ refund ธุรกรรมผิดรายการได้
    • UX ที่ดีกว่าคือใช้แบนเนอร์แบบสติกเกอร์เพื่อแจ้งว่าข้อมูลมีการเปลี่ยนแปลง หรือถ้าจำเป็นจริง ๆ ก็เพียงเพิ่มแถวใหม่โดยไม่เปลี่ยนตำแหน่งการเลื่อนหน้าจอ

  • ใน BeaconCMS มีการใช้ Svelte ร่วมกับ LiveView

    • นี่เป็นกรณีใช้งานที่ดีเมื่ออยากควบคุม UI ทางฝั่งไคลเอนต์ได้ละเอียดขึ้น
    • ต่อให้ใช้ Phoenix อยู่ LiveView ก็ไม่ใช่คำตอบเสมอไป และบางครั้งหน้าแบบ static rendering ก็เหมาะสมอย่างยิ่ง
    • มีคำแนะนำว่าอย่าใช้แนวทางแบบทั้งหมดหรือไม่เอาเลยกับทุกสิ่ง
    • อย่างที่บทความชี้ไว้ มีกรณีใช้งานดี ๆ บางอย่างที่ออกนอก "แนวทาง LiveView"
    • หากมี round trip 1000ms ก็อาจต้องมีข้อพิจารณาอื่น แต่เซิร์ฟเวอร์ที่ตั้งใกล้ภูมิศาสตร์ของผู้ใช้อาจใช้ไม่ได้ด้วยเหตุผลด้านต้นทุน เป็นต้น ดังนั้นการเพิ่มการจัดการสถานะฝั่งไคลเอนต์อาจเป็นทางออกได้

  • แทนที่จะจัดการสถานะบนไคลเอนต์ ก็กลายเป็นว่าต้องจัดการสถานะทั้งบนไคลเอนต์และเซิร์ฟเวอร์

    • ยากจะมองว่านี่เป็นการปรับปรุง แม้มันจะช่วยให้ไม่ต้องสร้าง API อีกชุดหนึ่งก็ตาม แต่นั่นไม่ได้แปลว่าดีขึ้น

  • ข้อจำกัดของแนวทางนี้อยู่ที่ความเร็วแสง: เซิร์ฟเวอร์มีขีดจำกัดว่าจะอยู่ใกล้ผู้ใช้ได้แค่ไหน

    • ขั้นต่อไปคือคอมไพล์เซิร์ฟเวอร์เป็น WebAssembly แล้วส่งไปให้ไคลเอนต์ เพื่อเรนเดอร์การตอบสนองแบบ optimistic ไปก่อนจนกว่าเซิร์ฟเวอร์จริงจะตอบกลับ
    • มันอาจฟังดูบ้าหน่อย ๆ แต่เคยทำสิ่งนี้สำเร็จในโปรเจ็กต์จริง และประสบการณ์ที่ได้เหมือนเวทมนตร์

  • ในฐานะคนที่สร้าง LiveSvelte ขึ้นมา ถ้ามีคำถามก็เชิญถามได้

  • โดยทั่วไปแล้วอยากสร้างแอปด้วยโมเดลแบบนี้: event-driven, อัปเดตแบบเรียลไทม์สองทางพร้อมเซิร์ฟเวอร์, event ที่มีลำดับ, สถานะทั้ง local และ remote...

    • เดิมไม่รู้จัก LiveView และไม่เคยใช้ภาษาตระกูล Erlang มาก่อน แต่ชัดเจนว่าพวกเขาค้นพบบางอย่าง
    • โมเดล request-response แบบดั้งเดิมก่อปัญหาเรื่องความสอดคล้องและข้อมูลล้าสมัยไว้มาก
    • ความคิดที่ฟังดูมีความหวังแต่ก็น่าจะถกเถียงกันได้: ถ้า 10 ปีที่ผ่านมาเป็นเรื่องของการผสานแนวคิด FP เข้าสู่ภาษากระแสหลัก 10 ปีข้างหน้าก็น่าจะเป็นเรื่องของการผสานการเขียนโปรแกรมแบบ message-oriented ที่มีสถานะ (reactive?) เข้าสู่ full stack กระแสหลักโดยรวม

  • ในแอปมีการใช้ Stimulus controller ที่นำกลับมาใช้ซ้ำได้ร่วมกับ LiveView ซึ่งก็ทำงานได้ลื่นไหลเช่นกัน

    • โดยทั่วไปการสร้างด้วย LiveView เป็นเรื่องน่าเพลิดเพลิน แต่ยิ่งใช้ในสถานการณ์จริงมากขึ้น ก็ยิ่งตระหนักถึงข้อดีของเฟรมเวิร์ก HTTP แบบไร้สถานะ
    • เฟรมเวิร์กอย่าง Hotwire ให้ประสิทธิภาพที่ดีกว่าและทนทานต่อการเชื่อมต่อใหม่มากกว่า อีกทั้งยังหลีกเลี่ยงความจำเป็นในการวางเซิร์ฟเวอร์ให้ใกล้ผู้ใช้มากขึ้น

  • เป็นโปรเจ็กต์ที่ยอดเยี่ยม! เพิ่งปล่อยตอนของ Svelte Radio เกี่ยวกับเรื่องนี้ออกมา