ทำแชตหรือเกมหลายผู้เล่นแบบเรียลไทม์ด้วย WebSocket บน BrewInTH

ให้ AI ทำแชตสด เกมหลายคน หรือหน้าจอที่อัปเดตเองด้วย WebSocket แล้วโฮสต์บน BrewInTH รู้ขีดจำกัดต่อแพ็กเกจ วิธีต่อใหม่เมื่อหลุด และเก็บข้อมูลไม่ให้หาย
อยากทำห้องแชตที่ข้อความเด้งขึ้นทันทีโดยไม่ต้องกดรีเฟรช เกมทายคำที่เพื่อนหลายคนเล่นพร้อมกัน หรือจอหน้าร้านที่คิวลูกค้าอัปเดตเองทุกครั้งที่มีคนจอง ทั้งหมดนี้ใช้เทคนิคเดียวกันคือ WebSocket สายเชื่อมต่อที่เปิดค้างไว้ระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์ ส่งข้อความไปกลับได้ตลอดเวลา
บทความนี้อธิบายว่า WebSocket คืออะไร ใช้กับงานแบบไหน ให้ AI สร้างยังไง แล้วเอาขึ้น BrewInTH ได้เลยโดยไม่ต้องตั้งค่าเซิร์ฟเวอร์เอง พร้อมขีดจำกัดต่อแพ็กเกจที่ควรรู้ และวิธีเขียนให้ระบบต่อสายใหม่เองเมื่อหลุด ซึ่งเป็นจุดที่โค้ดจาก AI มักลืม
สรุปสั้นก่อนอ่าน
✅ BrewInTH รับ WebSocket ที่ชื่อเว็บเดิมของโปรเจกต์ ผ่าน HTTPS (wss://) รวมถึงโดเมนของคุณเอง
✅ ต้องเป็นโปรเจกต์แบบแอป เช่น Node.js, Python หรือ Go เว็บ static ล้วนรับสาย WebSocket ไม่ได้
✅ เชื่อมต่อพร้อมกันได้ 32 สายต่อโปรเจกต์บน Free และ 500 ถึง 4,000 สายบนแพ็กเกจที่จ่ายเงิน
✅ สายที่เงียบ 10 นาทีถูกปิด และทุกครั้งที่เผยแพร่เวอร์ชันใหม่สายเดิมถูกตัด จึงต้องส่ง ping และต่อใหม่เอง
✅ เก็บข้อความ คะแนน หรือสถานะห้องไว้ใน Redis หรือฐานข้อมูล ไม่ใช่ในหน่วยความจำของแอปอย่างเดียว
WebSocket คืออะไร ต่างจากหน้าเว็บปกติยังไง
หน้าเว็บปกติทำงานแบบ "ถามแล้วตอบ" เบราว์เซอร์ขอหน้า เซิร์ฟเวอร์ส่งกลับ แล้วจบ ถ้าอยากรู้ว่ามีข้อความใหม่ไหม ต้องถามซ้ำทุกไม่กี่วินาที ซึ่งทั้งช้าและเปลือง
WebSocket เปิดสายค้างไว้หนึ่งเส้น เมื่อมีอะไรเกิดขึ้น เซิร์ฟเวอร์ส่งบอกเบราว์เซอร์ได้ทันที และเบราว์เซอร์ก็ส่งกลับได้ทันทีเหมือนกัน ข้อความจึงขึ้นภายในเสี้ยววินาที เหมาะกับงานแบบนี้
- แชตสด ห้องคุยของทีม แชตสอบถามบนหน้าร้าน แชตในห้องเรียน
- เกมหลายผู้เล่น เกมทายคำ เกมตอบคำถามแข่งกันแบบ Kahoot เกมกระดานที่ผลัดกันเดิน
- หน้าจอที่อัปเดตเอง จอเรียกคิว แดชบอร์ดยอดขาย สถานะออเดอร์ในครัว
- ทำงานร่วมกัน กระดานไอเดียที่หลายคนแก้พร้อมกัน โหวตสดระหว่างประชุม
WebSocket บน BrewInTH ทำงานยังไง

คำขอทุกอย่างของเว็บบน BrewInTH ผ่านด่านหน้าของแพลตฟอร์ม (edge) ก่อนถึงแอปของคุณ WebSocket ก็เช่นกัน สิ่งที่ต้องรู้มีไม่กี่ข้อ
- ที่อยู่เดียวกับเว็บ ถ้าเว็บอยู่ที่
https://ชื่อเว็บ.host.brewinth.netฝั่งเบราว์เซอร์ต่อwss://ชื่อเว็บ.host.brewinth.net/ws(path ตั้งได้ตามที่แอปรับ) ถ้าเชื่อมโดเมนของตัวเองแล้ว ใช้โดเมนนั้นได้เหมือนกัน - ใช้
wss://เสมอ เพราะเว็บบน BrewInTH เป็น HTTPS ทั้งหมด ถ้าเขียนws://เบราว์เซอร์จะไม่ยอมต่อ วิธีที่ปลอดภัยคือให้โค้ดสร้างที่อยู่จากหน้าเว็บที่เปิดอยู่ เช่น `${location.protocol === "https:" ? "wss" : "ws"}://${location.host}/ws` - ต้องเป็นแอป WebSocket ต้องมีโปรแกรมฝั่งเซิร์ฟเวอร์คอยรับสาย โปรเจกต์ที่เป็นไฟล์ HTML/CSS/JS ล้วนไม่มีตัวรับ ให้ใช้ Node.js (เช่น ไลบรารี
wsหรือ Socket.IO), Python (FastAPI, websockets) หรือ Go - แอปเปิดพอร์ตเดียว หน้าเว็บและ WebSocket อยู่ในแอปตัวเดียวกัน พอร์ตเดียวกับที่แอปอ่านจาก
PORTไม่ต้องเปิดพอร์ตแยก
ขีดจำกัดที่ควรรู้ก่อนเริ่ม

จำนวนสายที่เปิดพร้อมกันต่อโปรเจกต์ นับจากคนที่เปิดหน้าเว็บค้างไว้ในเวลาเดียวกัน
| แพ็กเกจ | เชื่อมต่อพร้อมกัน |
|---|---|
| Free | 32 สาย |
| Starter / Seed | 500 สาย |
| Maker | 1,000 สาย |
| Growth | 2,000 สาย |
| Pro | 4,000 สาย |
ถ้าเกินจำนวนนี้ สายใหม่จะถูกปฏิเสธจนกว่าจะมีคนปิดหน้าเว็บ บน Free จึงเหมาะกับการลองทำ เกมกับเพื่อนกลุ่มเล็ก หรือห้องเรียนหนึ่งห้อง ถ้าเปิดให้คนทั่วไปใช้ ควรเลือกแพ็กเกจที่จ่ายเงิน (ดูราคาได้ที่บทความ แพ็กเกจของ BrewInTH เลือกแบบไหนดี)
สายที่เงียบ 10 นาทีถูกปิด ถ้าไม่มีข้อความวิ่งเลยทั้งสองทาง ระบบจะปิดสายนั้น วิธีแก้คือให้แอปส่ง ping หรือข้อความสั้น ๆ ทุก 30-60 วินาที ไลบรารีส่วนใหญ่ เช่น Socket.IO ทำให้อยู่แล้ว
สายหนึ่งอยู่ได้นานสุด 24 ชั่วโมง สำหรับจอที่เปิดทิ้งไว้ทั้งวัน เช่นจอเรียกคิว ให้ต่อใหม่เองเมื่อครบ
นับรวมใน bandwidth ข้อความที่วิ่งผ่าน WebSocket นับเป็นปริมาณข้อมูลรายเดือนของแพ็กเกจเหมือนหน้าเว็บ แชตตัวอักษรใช้น้อยมาก แต่ถ้าส่งรูปหรือข้อมูลก้อนใหญ่ทุกวินาทีควรดูหน้า การใช้งาน เป็นระยะ
สายหลุดได้เสมอ: เขียนให้ต่อใหม่เอง

นี่คือเรื่องที่สำคัญที่สุดของบทความ สาย WebSocket หลุดได้จากหลายเหตุผล และส่วนใหญ่ไม่ใช่ความผิดของโค้ด
- เผยแพร่เวอร์ชันใหม่ เมื่อเวอร์ชันใหม่ขึ้นออนไลน์ สายที่ต่อกับเวอร์ชันเดิมจะถูกปิดภายในราวครึ่งนาที ผู้ใช้ทุกคนต้องต่อเข้ามาใหม่ที่เวอร์ชันใหม่
- เงียบนานเกิน 10 นาที หรือ ครบ 24 ชั่วโมง
- เน็ตของผู้ใช้ มือถือสลับจาก Wi-Fi เป็น 4G หรือพับหน้าจอไว้
- เว็บบนแพ็กเกจ Free ที่พักอยู่ เว็บ Free ที่ไม่มีคนเข้านานจะพักเครื่อง สายแรกที่เข้ามาตอนนั้นจะถูกปฏิเสธระหว่างที่แอปกำลังตื่น รอ 5-10 วินาทีแล้วต่อใหม่ก็ได้ (อ่านเพิ่มที่ เว็บฟรีเปิดช้าครั้งแรก? รู้จักการพักอัตโนมัติ)
ทางแก้เหมือนกันทุกกรณี ให้ฝั่งเบราว์เซอร์ ต่อใหม่เองแบบรอนานขึ้นเรื่อย ๆ (1, 2, 4, 8 วินาที ไม่เกิน 30 วินาที) และเมื่อต่อติดแล้วให้ ดึงสถานะล่าสุด มาแสดง เช่นข้อความ 50 อันล่าสุดของห้อง หรือคะแนนปัจจุบันของเกม
ทำไมต้องเก็บสถานะไว้นอกแอป
ทุกครั้งที่เผยแพร่เวอร์ชันใหม่ แอปตัวเดิมหยุดและตัวใหม่เริ่มจากศูนย์ ถ้าเก็บข้อความหรือคะแนนไว้ในตัวแปรของโปรแกรมเท่านั้น ข้อมูลจะหายไปกับแอปตัวเดิม
- Redis เหมาะกับข้อมูลที่เปลี่ยนเร็ว เช่น ใครอยู่ในห้องไหน คะแนนระหว่างเกม ข้อความล่าสุด โปรเจกต์ละ 1 ตัว ไม่นับในโควตาฐานข้อมูล ระบบใส่ค่า
REDIS_URLให้แอปเอง อ่านเพิ่มที่ Redis คืออะไร ทำให้เว็บเร็วขึ้นยังไง - ฐานข้อมูลหลัก (PostgreSQL, MySQL, MongoDB) เหมาะกับประวัติแชตที่ต้องเก็บถาวร ผลเกมย้อนหลัง หรือบัญชีผู้ใช้
ให้ AI สร้างและเอาขึ้น BrewInTH
ถ้าใช้ coding agent ที่เชื่อมกับโปรเจกต์ BrewInTH อยู่แล้ว ส่ง prompt แบบนี้ได้เลย ปรับเรื่องของแอปตามที่ต้องการ
ช่วยทำเว็บแชตห้องเดียวแบบเรียลไทม์ด้วย Node.js และ WebSocket (ไลบรารี ws)
- ผู้ใช้ตั้งชื่อเล่นก่อนเข้าห้อง เห็นข้อความใหม่ทันทีโดยไม่ต้องรีเฟรช
- หน้าเว็บกับ WebSocket อยู่ในแอปเดียวกัน ฟังพอร์ตจาก process.env.PORT
- ฝั่งเบราว์เซอร์สร้างที่อยู่จาก location (https = wss) path /ws
- ส่ง ping ทุก 30 วินาที และต่อใหม่เองเมื่อหลุด รอ 1, 2, 4, 8 วินาที ไม่เกิน 30 วินาที
- เก็บข้อความ 50 อันล่าสุดใน Redis ของโปรเจกต์ (อ่าน REDIS_URL) ต่อติดเมื่อไรให้โหลดมาแสดง
- จำกัดความยาวข้อความ 500 ตัวอักษร และกันข้อความ HTML ไม่ให้รันในหน้าคนอื่น
แล้วเอาขึ้น BrewInTH ให้ด้วย ถ้าโปรเจกต์ยังไม่มี Redis ให้สร้าง
หลังขึ้นแล้วทดสอบโดยเปิดสองหน้าต่าง ส่งข้อความจากฝั่งหนึ่งแล้วดูว่าอีกฝั่งเห็น
สำหรับเกมหลายผู้เล่น ใช้ prompt แนวเดียวกัน แต่บอกกติกาให้ชัด
ทำเกมทายคำแบบผลัดกันวาดสำหรับ 2-8 คนด้วย WebSocket
- ผู้เล่นสร้างห้องแล้วได้รหัสห้อง 4 ตัวไปแชร์ให้เพื่อน
- เซิร์ฟเวอร์เป็นคนตัดสินคะแนนและเวลา ไม่เชื่อค่าที่เบราว์เซอร์ส่งมา
- เก็บสถานะห้อง ผู้เล่น และคะแนนใน Redis ถ้าสายหลุดแล้วต่อใหม่ให้กลับเข้าห้องเดิมได้
- ห้องที่ไม่มีคนเกิน 30 นาทีให้ลบทิ้ง
ไม่มี coding agent
ให้แชต AI เขียนโค้ดตาม prompt ข้างบน แล้วนำไฟล์ขึ้นผ่านหน้า อัปโหลดแล้วขึ้นเว็บ ได้ ถ้าโค้ดใช้ Redis ระบบจะสร้าง Redis ให้โปรเจกต์เอง (หน้านี้ยังอยู่ในขั้นทดสอบ BETA)
ดูว่ามีคนต่อเข้ามาเท่าไร
ถ้าบัญชีเปิดใช้สถิติไว้ แท็บ สถิติ ของโปรเจกต์แสดงจำนวน WebSocket sessions ระยะเวลาเชื่อมต่อเฉลี่ย และปริมาณข้อมูล นับจากฝั่งแพลตฟอร์มโดยไม่ต้องใส่โค้ดอะไรในแอป ใช้ดูได้ว่าเกมหรือห้องแชตมีคนใช้จริงแค่ไหน และใกล้ขีดจำกัดของแพ็กเกจหรือยัง
ข้อควรระวังด้านความปลอดภัย
- ตรวจผู้ใช้ตอนเปิดสาย ถ้าห้องเป็นของสมาชิก ให้แอปตรวจ session หรือ token ตอนเริ่มเชื่อมต่อ ไม่ใช่ปล่อยใครก็ต่อได้
- อย่าเชื่อข้อมูลจากเบราว์เซอร์ คะแนน เวลา และผลแพ้ชนะต้องคำนวณที่เซิร์ฟเวอร์
- จำกัดขนาดและความถี่ของข้อความ กันคนส่งข้อความรัว ๆ จนห้องใช้ไม่ได้
- กัน HTML ในข้อความ แสดงข้อความเป็นตัวอักษรธรรมดา ไม่ใช่ HTML
คำถามที่พบบ่อย
ต้องตั้งค่าอะไรใน BrewInTH เพื่อเปิด WebSocket ไหม
ไม่ต้อง WebSocket ใช้ได้กับทุกโปรเจกต์แบบแอปตั้งแต่แรก ขอแค่แอปรับการเชื่อมต่อที่พอร์ตเดียวกับหน้าเว็บ
ใช้ Socket.IO ได้ไหม
ได้ Socket.IO เปิดสาย WebSocket ผ่านที่อยู่เดียวกับเว็บ และมี ping กับการต่อใหม่ในตัว จึงเข้ากับขีดจำกัดเรื่องสายเงียบได้ดี
เว็บ static ที่ทำด้วย HTML ล้วนทำแชตได้ไหม
รับสาย WebSocket เองไม่ได้ เพราะไม่มีโปรแกรมฝั่งเซิร์ฟเวอร์ ต้องเปลี่ยนเป็นโปรเจกต์แบบแอป เช่นให้ AI เพิ่มเซิร์ฟเวอร์ Node.js เล็ก ๆ ที่เสิร์ฟหน้าเว็บเดิมและรับ WebSocket ไปพร้อมกัน
ทำไมทุกคนหลุดพร้อมกันหลังอัปเดตเว็บ
เป็นเรื่องปกติ เมื่อเวอร์ชันใหม่ขึ้นออนไลน์ สายที่ต่อกับเวอร์ชันเดิมถูกปิด ถ้าแอปเขียนให้ต่อใหม่เองและโหลดสถานะจาก Redis หรือฐานข้อมูล ผู้ใช้จะเห็นแค่สะดุดไม่กี่วินาที
คนใช้เกินจำนวนสายของแพ็กเกจแล้วเกิดอะไรขึ้น
สายใหม่ถูกปฏิเสธจนกว่าจะมีคนออก คนที่ต่ออยู่แล้วใช้ได้ตามปกติ ถ้าเกิดบ่อย ให้เปลี่ยนเป็นแพ็กเกจที่ใหญ่ขึ้น
สรุป
WebSocket ทำให้เว็บที่สร้างด้วย AI กลายเป็นแชตสด เกมหลายผู้เล่น หรือจอที่อัปเดตเองได้ บน BrewInTH ใช้ได้ทันทีที่ชื่อเว็บเดิมผ่าน wss:// ขอให้เป็นโปรเจกต์แบบแอป จำขีดจำกัดสามข้อให้ดี คือจำนวนสายต่อแพ็กเกจ สายเงียบ 10 นาทีถูกปิด และเวอร์ชันใหม่ตัดสายเดิม แล้วให้ AI เขียนการต่อใหม่และเก็บสถานะไว้ใน Redis หรือฐานข้อมูลตั้งแต่แรก
