การใช้ Server-Sent Events แทน WebSockets
(germano.dev)-
เวลาสร้างเว็บแอปพลิเคชันแบบเรียลไทม์ ปกติมักจะนึกถึง WebSocket กันก่อน แต่ SSE ก็อาจเป็นทางเลือกที่เรียบง่ายได้
-
ปัญหาของ WebSocket: เนื่องจากไม่ได้อยู่บนพื้นฐานของ HTTP จึงไม่ได้รับข้อดีของ HTTP
→ ไม่สามารถบีบอัดได้, รองรับ HTTP/2 multiplexing ได้ไม่ดี, Proxy ต่าง ๆ ไม่รองรับ, อาจถูก hijacking ได้
- Server-Sent Events (SSE)
→ เป็นความสามารถที่เซิร์ฟเวอร์สามารถส่ง push event แบบ low-latency ไปยังไคลเอนต์ได้
→ เป็นมาตรฐาน HTML และทุกเบราว์เซอร์รองรับ (ยกเว้น IE)
→ ต่างจาก WebSocket ตรงที่ SSE เป็นการสื่อสารทางเดียวจากเซิร์ฟเวอร์ไปยังไคลเอนต์ (จึงไม่เหมาะกับเกมที่ต้องการการสื่อสารสองทาง)
→ ทำงานอยู่บน HTTP และไม่ต้องใช้โปรโตคอลแยกต่างหาก
5 ความคิดเห็น
ในสภาพแวดล้อมที่มี Load Balancer หรือ Proxy มักมีกรณีที่รองรับ SSE ได้ไม่ดีนัก (+Enterprise Firewall)
หากคุณกำลังพิจารณาสภาพแวดล้อมอย่าง Cloudflare หรือ AWS CLB เป็นต้น ควรตรวจสอบให้รอบคอบอีกครั้งก่อนนำ SSE มาใช้
บางกรณีก็ถูกนำไปใช้แทน WebSocket ในฐานะ transport สำหรับ GraphQL Subscription
การติดตั้งใช้งาน GraphQL SSE handler: https://github.com/enisdenjo/graphql-sse
ตัวอย่างการใช้ SSE เป็น subscription transport: https://www.graphql-yoga.com/docs/features/subscriptions
อาจเป็นทางเลือกได้เมื่อยากต่อการใช้งาน WebSocket ในสภาพแวดล้อมเฉพาะอย่าง Deno Deploy หรือ Lambda :-)
ไม่นานมานี้ผมเองก็เพิ่งรู้จัก SSE เป็นครั้งแรก ตอนที่ดูตัวอย่างแชตบน Deno Deploy
https://github.com/lucacasonato/deploy_chat
มีแบบนี้ด้วยนะ ได้ความรู้เลย
แนะนำให้อ่านคอมเมนต์ของบทความนี้และคอมเมนต์ใน HN ประกอบกันด้วย
มีความเห็นหลากหลายมาก ทั้งจากคนที่ใช้งาน SSE อยู่ กรณีที่ย้ายมาจาก WebSocket และกรณีที่เปลี่ยนไปใช้ SSE แล้วสุดท้ายกลับไปใช้ WebSocket อีกครั้ง
https://news.ycombinator.com/item?id=30312897
จริง ๆ แล้วในบทความนี้พูดถึงข้อดีของ SSE ไว้มากก็จริง แต่จะมีประโยชน์เป็นหลักในบางสถานการณ์เฉพาะเท่านั้น
ทุกวันนี้ฝั่ง WebSocket เองก็มีไลบรารีออกมามาก ทำให้การพัฒนาง่ายขึ้นด้วย
ก็มีข้อเสนอแบบนี้อยู่เหมือนกัน