Elixir Phoenix LiveView Real-time Processing | SiamCafe Blog

Elixir Phoenix LiveView คืออะไร และทำงานแบบ Real-time ได้อย่างไร

Elixir Phoenix LiveView คือเฟรมเวิร์กที่ช่วยให้เราสร้างหน้าเว็บแบบ real-time ได้โดยไม่ต้องเขียน JavaScript เองเลยสักเท่าไหร่

หัวใจของมันคือการรันโค้ดทั้งหมดบนฝั่งเซิร์ฟเวอร์ แล้วส่งข้อมูลเฉพาะส่วนที่เปลี่ยนแปลงไปยังเบราว์เซอร์ผ่าน WebSocket ทำให้หน้าจอผู้ใช้งานอัปเดตทันทีที่ข้อมูลเปลี่ยน โดยไม่ต้องรีโหลดหน้าทั้งหน้า ผมใช้งาน Elixir มาหลายปีในงานที่ต้องรับข้อมูลราคาและสัญญาณเทรดแบบเรียลไทม์ และยังไม่เคยเจอเครื่องมือไหนที่จัดการเชื่อมต่อพร้อมกันหลายแสนรายการได้ง่ายและเสถียรเท่ากับ Phoenix LiveView เลยครับ

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

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

สำหรับงานที่ผมทำ อย่างแดชบอร์ดแสดงราคาทองคำและค่าเงินที่เปลี่ยนทุกวินาที LiveView ตอบโจทย์ได้ดีมาก เพราะข้อมูลที่มาจากแหล่งภายนอกสามารถกระจายผ่านระบบช่องทางข้อมูลของ Phoenix ไปยังผู้ใช้ทุกคนที่เปิดหน้านั้นค้างไว้ได้ทันทีในครั้งเดียว นี่คือเหตุผลที่บทความนี้จะพาไปดูตั้งแต่พื้นฐานจนถึงการนำไปใช้งานจริงในระบบที่ต้องประมวลผลข้อมูลแบบต่อเนื่อง

สถาปัตยกรรมของ Phoenix LiveView ถูกออกแบบมาให้ประมวลผลข้อมูลที่ไหลเข้ามาตลอดเวลาได้อย่างเป็นระบบ โดยประกอบจากหลายชั้นที่ทำงานร่วมกัน

การเข้าใจแต่ละชั้นช่วยให้เราออกแบบระบบได้ถูกทางตั้งแต่ต้น และไม่ต้องมานั่งแก้โครงสร้างทีหลังเมื่อผู้ใช้เยอะขึ้น ซึ่งเป็นปัญหาที่ผมเจอบ่อยมากในโปรเจกต์ที่รับช่วงต่อจากทีมอื่น

สถาปัตยกรรมของ Phoenix LiveView ถูกออกแบบมาให้ประมวลผลข้อมูลที่ไหลเข้ามาตลอดเวลาได้อย่างเป็นระบบ โดยประกอบจากหลายชั้นที่ทำงานร่วมกัน การเข้าใจแต่ละชั้นช่วยให้เราออกแบบระบบได้ถูกทางตั้งแต่ต้น และไม่ต้องมานั่งแก้โครงสร้างทีหลังเมื่อผู้ใช้เยอะขึ้น ซึ่งเป็นปัญหาที่ผมเจอบ่อยมากในโปรเจกต์ที่รับช่วงต่อจากทีมอื่น

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

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

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

ตารางต่อไปนี้สรุปการเปรียบเทียบแนวทาง LiveView กับแนวทางอื่นที่นิยมใช้

ประเด็น	Phoenix LiveView	SPA แบบ JavaScript	เว็บแบบดั้งเดิม
การอัปเดตข้อมูล	ส่งเฉพาะส่วนที่เปลี่ยนผ่าน WebSocket	เรียกข้อมูลผ่านแอปพลิเคชันโปรแกรมติดต่อ	รีโหลดทั้งหน้า
การเก็บสถานะ	ฝั่งเซิร์ฟเวอร์	ฝั่งเบราว์เซอร์	ฝั่งเซิร์ฟเวอร์รายคำขอ
จำนวนโค้ดที่ต้องดูแล	ภาษาเดียวคือ Elixir	สองภาษาคือฝั่งหลังและฝั่งหน้า	น้อยแต่ประสบการณ์ผู้ใช้ต่ำ
การขยายระบบ	เพิ่มเครื่องได้โดยไม่แก้โค้ด	ต้องออกแบบระบบกระจายสถานะ	ขยายง่ายแต่อัปเดตช้า

การเริ่มต้นใช้งาน Phoenix LiveView สำหรับงานประมวลผลข้อมูลแบบทันทีไม่ได้ยากอย่างที่หลายคนคิด

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

การเริ่มต้นสร้างระบบประมวลผลเรียลไทม์ทีละขั้นตอน

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

ขั้นแรกคือการเตรียมเครื่องมือ ต้องติดตั้ง Elixir เวอร์ชันล่าสุดซึ่งมาพร้อมระบบจัดการไลบรารีในตัว และฐานข้อมูล PostgreSQL สำหรับเก็บข้อมูลถาวร สำหรับเครื่องพัฒนา แนะนำหน่วยประมวลผลอย่างน้อยสองแกน หน่วยความจำสี่กิกะไบต์ขึ้นไป และพื้นที่จัดเก็บยี่สิบกิกะไบต์ จากนั้นสร้างโปรเจกต์ใหม่ด้วยคำสั่งสร้างโปรเจกต์ของ Phoenix โดยเลือกเปิดใช้ LiveView ตั้งแต่แรก ระบบจะสร้างโครงสร้างพื้นฐานที่ครบครันให้ทันที

ขั้นที่สองคือการออกแบบโมดูล LiveView หลัก ตัวอย่างโค้ดต่อไปนี้เป็นแดชบอร์ดที่แสดงข้อมูลและเหตุการณ์ล่าสุด พร้อมอัปเดตอัตโนมัติทุกห้าวินาที

defmodule MyAppWeb.DashboardLive do use MyAppWeb, :live_view

@refreshinterval 5000

@impl true def mount(params, session, socket) do if connected?(socket) do :timer.sendinterval(@refreshinterval, :refresh) Phoenix.PubSub.subscribe(MyApp.PubSub, "updates") end

{:ok, socket

> assign(:page_title, "แดชบอร์ดข้อมูลสด")
> assign(:data, MyApp.Data.get_current())
> assign(:events, MyApp.Events.recent(50))}

end

@impl true def handle_info(:refresh, socket) do {:noreply, assign(socket, :data, MyApp.Data.get_current())} end

def handleinfo({:newevent, event}, socket) do events = [event | socket.assigns.events] |> Enum.take(50) {:noreply, assign(socket, :events, events)} end

@impl true def handle_event("filter", %{"type" => type}, socket) do {:noreply, assign(socket, :events, MyApp.Events.recent(50, type: type))} end

@impl true def render(assigns) do ~H"""

""" end end

เมื่อระบบพื้นฐานทำงานได้แล้ว ขั้นต่อไปคือการยกระดับให้ทนต่อการใช้งานจริงที่มีทั้งปริมาณข้อมูลมหาศาลและสถานการณ์ที่ไม่คาดคิด จากประสบการณ์ของผม

มีแนวปฏิบัติไม่กี่ข้อที่แยกระหว่างระบบที่โอเคในการสาธิตกับระบบที่อยู่รอดในการใช้งานจริงได้อย่างชัดเจน

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

เทคนิคขั้นสูงและแนวปฏิบัติที่ดีสำหรับงานเรียลไทม์

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

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

ข้อที่สองคือการจัดการอัตราการไหลเข้าของข้อมูล เมื่อแหล่งข้อมูลส่งมาเร็วมาก เช่น ราคาที่อัปเดตร้อยครั้งต่อวินาที เราไม่ควรส่งทุกอย่างไปยังผู้ใช้ทันที ควรรวบรวมแล้วส่งครั้งเดียวในทุกหลักร้อยมิลลิวินาที เทคนิคนี้เรียกว่าการลดความถี่การอัปเดต ช่วยลดปริมาณข้อมูลที่ส่งลงได้มากโดยผู้ใช้แทบไม่รู้สึกถึงความต่าง

ระบบที่ดีไม่ได้แปลว่าไม่มีปัญหา แต่แปลว่าเรารู้ว่ามีปัญหาก่อนลูกค้าจะโทรมาบอก

การเฝ้าดูระบบจึงเป็นส่วนที่ห้ามมองข้ามเด็ดขาดในงานประมวลผลข้อมูลแบบทันที เพราะปัญหาในระบบเรียลไทม์มักแสดงอาการเป็นความล่าช้าที่ค่อย ๆ แย่ลง ไม่ใช่ล่มทั้งระบบในครั้งเดียว ถ้าไม่มีตัวชี้วัดให้ดู เราจะไม่รู้ตัวจนผู้ใช้เริ่มบ่น

ข้อที่สี่คือการวางแผนการกู้คืนเมื่อระบบล่ม ทุกองค์ประกอบต้องมีแผนสำรอง ฐานข้อมูลต้องสำรองข้อมูลทุกวันและทดสอบการกู้คืนจริงเป็นระยะ เพราะการสำรองที่ไม่เคยทดสอบถือว่าไม่มีการสำรองเกิดขึ้นเลย และควรตั้งระบบเฝ้าดูให้แจ้งเตือนเมื่อค่าสำคัญเกินเกณฑ์ตั้งแต่วันแรกของการเปิดใช้งาน

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

การเฝ้าดูระบบและแก้ไขปัญหาเมื่อเกิดเหตุการณ์

ระบบที่ดีไม่ได้แปลว่าไม่มีปัญหา แต่แปลว่าเรารู้ว่ามีปัญหาก่อนลูกค้าจะโทรมาบอก การเฝ้าดูระบบจึงเป็นส่วนที่ห้ามมองข้ามเด็ดขาดในงานประมวลผลข้อมูลแบบทันที เพราะปัญหาในระบบเรียลไทม์มักแสดงอาการเป็นความล่าช้าที่ค่อย ๆ แย่ลง ไม่ใช่ล่มทั้งระบบในครั้งเดียว ถ้าไม่มีตัวชี้วัดให้ดู เราจะไม่รู้ตัวจนผู้ใช้เริ่มบ่น

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

สำหรับระบบ Elixir มีข้อดีพิเศษคือมีเครื่องมือเฝ้าดูในตัวที่ชื่อว่าโอบเซอร์เวอร์ ช่วยให้เราดูสถานะของทุกกระบวนการในระบบสด ๆ ว่าใครกินหน่วยความจำเยอะ ใครทำงานหนักเกินไป ใช้เวลาตอบสนองนาน ซึ่งเป็นสิ่งที่ภาษาอื่นส่วนใหญ่ต้องติดตั้งเครื่องมือเสริมที่ซับซ้อน ตัวอย่างสคริปต์เฝ้าดูสถานภาพเซิร์ฟเวอร์อย่างง่ายที่ผมใช้ประจำ

#!/bin/bash set -euo pipefail SERVICE="myapp-liveview" HEALTH_URL="http://localhost:8080/health" LOG="/var/log/$SERVICE/health.log"

check_health() { local code code=$(curl

คำถามที่พบบ่อย

Phoenix LiveView ทำงานแบบ real-time ได้อย่างไรโดยไม่ต้องเขียน JavaScript เอง?

Phoenix LiveView ทำงานโดยการรันโค้ดทั้งหมดบนฝั่งเซิร์ฟเวอร์ แล้วส่งข้อมูลเฉพาะส่วนที่เปลี่ยนแปลงไปยังเบราว์เซอร์ผ่าน WebSocket ทำให้หน้าจอผู้ใช้อัปเดตทันทีที่ข้อมูลเปลี่ยนโดยไม่ต้องรีโหลดหน้าทั้งหน้า จุดสำคัญคือเมื่อสถานะเปลี่ยน LiveView จะสร้างผลลัพธ์ใหม่แล้วเทียบกับผลลัพธ์เดิม ส่งเฉพาะความต่างกลับไปยังเบราว์เซอร์ผ่านไลบรารีฝั่งหน้าบ้านที่เบาและเร็ว ซึ่งจะนำความต่างไปอัปเดตหน้าจอทันทีภายในเวลาไม่กี่มิลลิวินาที ผู้ใช้จึงรู้สึกเหมือนข้อมูลไหลมาแบบต่อเนื่องโดยไม่มีอาการสะดุด ทั้งหมดนี้ทำให้เราแทบไม่ต้องเขียน JavaScript เองเลย เพราะตรรกะทั้งหมดอยู่บนเซิร์ฟเวอร์ด้วยภาษา Elixir เพียงภาษาเดียว ลดภาระการดูแลโค้ดหลายภาษาลงอย่างมาก

BEAM มีบทบาทอย่างไรต่อความเสถียรของระบบ LiveView?

BEAM คือเครื่องจักรเสมือนเดียวกับที่ใช้รัน Erlang เดิม และเป็นหัวใจสำคัญที่ทำให้ Phoenix LiveView มีความเสถียรสูงมาก จุดแข็งของ BEAM คือการสร้างกระบวนการย่อยได้หลายล้านตัวพร้อมกันในเครื่องเดียว โดยแต่ละกระบวนการแยกกันโดยสมบูรณ์ ถ้ากระบวนการหนึ่งล้ม กระบวนการอื่นจะไม่ได้รับผลกระทบ สำหรับงานประมวลผลข้อมูลแบบเรียลไทม์ คุณสมบัตินี้สำคัญมาก เพราะการเชื่อมต่อของผู้ใช้แต่ละคนจะถูกจัดการโดยกระบวนการแยกกัน ถ้ามีผู้ใช้คนหนึ่งส่งข้อมูลประหลาดเข้ามาจนเกิดข้อผิดพลาด ระบบจะตัดเฉพาะกระบวนการนั้นทิ้งแล้วเริ่มใหม่โดยอัตโนมัติ ขณะที่ผู้ใช้คนอื่นยังใช้งานต่อได้ตามปกติ จากประสบการณ์จริงยังไม่เคยเจอเครื่องมือไหนจัดการเชื่อมต่อพร้อมกันหลายแสนรายการได้ง่ายและเสถียรเท่านี้

Phoenix LiveView จัดการสถานะของผู้ใช้แบบไหน และมีข้อดีด้านความปลอดภัยอย่างไร?

ผู้ใช้แต่ละคนที่เปิดหน้าแบบ LiveView จะถูกสร้างกระบวนการแยกต่างหากบน BEAM โดยกระบวนการนี้ทำหน้าที่เก็บสถานะของหน้าจอของผู้ใช้คนนั้น ไม่ว่าจะเป็นค่าที่กรองไว้ ข้อมูลล่าสุดที่แสดง หรือสถานะของฟอร์ม ข้อดีของการเก็บสถานะฝั่งเซิร์ฟเวอร์คือด้านความปลอดภัย เพราะตรรกะทั้งหมดอยู่บนเซิร์ฟเวอร์ ผู้ใช้ไม่สามารถแก้ไขข้อมูลฝั่งตัวเองเพื่อหลอกระบบได้ง่าย ๆ เหมือนกับเวลาที่เก็บสถานะไว้ในเบราว์เซอร์แบบ SPA ทั่วไป นอกจากนี้ยังช่วยให้การจัดการสถานะมีความสม่ำเสมอ เพราะทุกอย่างอยู่ในที่เดียวและถูกควบคุมด้วยภาษาเดียวคือ Elixir ทำให้ไม่ต้องซิงก์สถานะระหว่างฝั่งเซิร์ฟเวอร์กับฝั่งไคลเอนต์ ซึ่งเป็นแหล่งเกิดบั๊กที่พบบ่อยในแนวทางอื่น

Phoenix Channels/PubSub ช่วยกระจายข้อมูลเรียลไทม์ไปยังผู้ใช้หลายคนได้อย่างไร?

ระบบ PubSub ของ Phoenix ทำหน้าที่เหมือนกระดานประกาศกลาง ใครสมัครรับข้อมูลหัวข้อไหนไว้ เมื่อมีข้อความใหม่เข้ามาในหัวข้อนั้น ระบบจะส่งต่อให้ทุกคนที่รอฟังอยู่ทันที ข้อมูลจากแหล่งภายนอก เช่น ราคาจากโบรกเกอร์ ข

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6