ไขข้อข้องใจ Solon WebSocket ทำไมถึงไม่เหมือน Java มาตรฐาน
เจาะลึกการทำงานของ Solon WebSocket ที่ฉีกแนวจากมาตรฐาน JSR-356 แบบเดิมๆ ด้วยรูปแบบ Listener Interface ที่ทดสอบและควบคุมง่ายกว่า
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Solon WebSocket มีสถาปัตยกรรมที่แตกต่างจากมาตรฐาน JSR-356 ของ Java อย่างสิ้นเชิง
- รองรับการใช้งานแบบพอร์ตแชร์ร่วมกับ HTTP ผ่านการตั้งค่า server.websocket.port
- โค้ดที่ใช้ @ServerEndpoint แบบเดิมจำเป็นต้องเขียนใหม่ให้เข้ากับ Listener Interface
- จุดเด่นคือทดสอบง่ายและทำ Routing ได้ชัดเจนโดยไม่ต้องพึ่งพา Annotation Scanning
ระบบ WebSocket ของ Solon ถือเป็นหนึ่งในจุดที่นักพัฒนาสาย Java อาจต้องปรับตัวทำความเข้าใจใหม่ เนื่องจากแนวทางการออกแบบมีความแตกต่างจากมาตรฐานทั่วไปอย่าง JSR-356 ที่ใช้งานกันแพร่หลายใน Spring, Tomcat หรือคอนเทนเนอร์ Java EE อื่นๆ แม้จะไม่ใช่ระบบที่แย่กว่า แต่เป็นแนวคิดที่เลือกเดินคนละทาง เมื่อทำความเข้าใจรูปแบบของมันได้แล้ว จะพบว่ามีความสะอาดและเป็นระเบียบกว่ามากทีเดียว
โครงสร้างการทำงานหลักของ Solon WebSocket จะแบ่งออกเป็น 2 รูปแบบ ขึ้นอยู่กับปลั๊กอินของเซิร์ฟเวอร์ที่เลือกใช้งาน ดังนี้:
- การใช้งานแบบพอร์ตแชร์ (Shared port): การจราจรทั้ง HTTP และ WebSocket จะใช้พอร์ตเดียวกัน ซึ่งปลั๊กอินเซิร์ฟเวอร์ส่วนใหญ่รองรับการทำงานนี้ได้ทันที
- การกำหนดค่าผ่านพารามิเตอร์
server.websocket.port : 18080โดยไม่ต้องกังวลเรื่องหมายเลขเวอร์ชันในการประกาศ dependency เนื่องจากระบบ Solon BOM จะทำหน้าที่จัดการให้ทั้งหมด
ข้อควรระวังสำคัญคือ Solon WebSocket ไม่ได้ใช้งาน API ตามมาตรฐาน JSR-356 ดังนั้น หากนักพัฒนากำลังย้ายระบบโค้ดเดิมที่เรียกใช้คลาส javax.websocket.Session, แอนโนเทชัน @ServerEndpoint หรือระบบ Encoder/Decoder ของ JSR-356 โค้ดส่วนนั้นจำเป็นต้องถูกเขียนใหม่ทั้งหมดให้อยู่ในรูปแบบของ listener interface pattern แม้จะไม่ใช่การเขียนใหม่ทั้งหมดในปริมาณที่ใหญ่โต แต่มันก็เป็นงานที่ต้องลงมือทำจริงจัง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การเปลี่ยนผ่านจาก Annotation มาเป็น Listener Interface ในทางวิศวกรรมซอฟต์แวร์ช่วยลดปัญหาความซับซ้อนที่เกิดจาก Magic Annotation (แอนโนเทชันวิเศษที่ซ่อนการทำงานเบื้องหลัง) ซึ่งมักสร้างความประหลาดใจหรือตรวจหาข้อผิดพลาดได้ยาก การใช้ Listener ตรงๆ ช่วยให้เราเห็นลำดับการทำงาน (Pipeline) ได้อย่างชัดเจนผ่านโค้ดตรงหน้า
ในทางกลับกัน ข้อดีที่ได้กลับคืนมาคือรูปแบบ listener นั้นช่วยให้การเขียน Unit Test กลายเป็นเรื่องง่ายดาย เพียงแค่สร้างอินสแตนซ์ของคลาส listener ขึ้นมาแล้วเรียกใช้งานเมธอดโดยตรง นอกจากนี้ยังช่วยเรื่องการประกอบระบบและการทำ routing ผ่าน path ได้อย่างชัดเจน อ่านง่าย โดยไร้ความประหลาดใจจากระบบสแกนแอนโนเทชันที่มักซ่อนอยู่เบื้องหลัง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น