ไลบรารี TypeScript ใหม่ที่เรียกว่า socket-call ได้เกิดขึ้นมา โดยสัญญาว่าจะทำให้การสื่อสารเว็บแบบเรียลไทม์ง่ายขึ้น ด้วยการอนุญาตให้นักพัฒนาเรียกใช้ socket events เหมือนกับฟังก์ชัน async ทั่วไป ไลบรารีนี้สร้างขึ้นบนเฟรมเวิร์ก socket.io ที่ได้รับความนิยม โดยมีเป้าหมายเพื่อให้ประสบการณ์การเขียนโปรแกรมที่เข้าใจง่ายขึ้นสำหรับการจัดการการสื่อสารระหว่างไคลเอนต์และเซิร์ฟเวอร์
ไลบรารีนี้เปลี่ยนการจัดการ socket event แบบดั้งเดิมให้เป็นการเรียกใช้แบบฟังก์ชัน พร้อมด้วยการสนับสนุน TypeScript เพื่อความปลอดภัยของโค้ดที่ดีขึ้น นักพัฒนาสามารถเขียน event handlers ฝั่งเซิร์ฟเวอร์ที่ดูและทำงานเหมือนฟังก์ชัน async มาตรฐาน ในขณะที่โค้ดฝั่งไคลเอนต์สามารถเรียกใช้ events เหล่านี้และรับการตอบกลับโดยใช้ไวยากรณ์แบบ promise ที่คุ้นเคย
คุณสมบัติหลักของไลบรารี socket-call :
- สร้างขึ้นบนพื้นฐานของเฟรมเวิร์ก socket.io
- รองรับ TypeScript พร้อมความปลอดภัยของประเภทข้อมูลแบบเต็มรูปแบบ
- ไวยากรณ์ async/await สำหรับเหตุการณ์ socket
- ตัวจัดการเหตุการณ์ฝั่งเซิร์ฟเวอร์เป็นฟังก์ชันปกติ
- การเรียกเหตุการณ์ฝั่งไคลเอนต์แบบ promise-based
- รองรับ namespace สำหรับการสื่อสารที่เป็นระเบียบ
ความกังวลของชุมชนเกี่ยวกับการนามธรรมที่เกินไป
ชุมชนนักพัฒนาได้ตั้งคำถามที่สำคัญเกี่ยวกับว่าแนวทางนี้เพิ่มความซับซ้อนที่ไม่จำเป็นหรือไม่ นักวิจารณ์โต้แย้งว่า socket.io ให้การนามธรรมที่เพียงพอแล้วเหนือการเชื่อมต่อ WebSocket แบบดิบ และการเพิ่มชั้นอีกหนึ่งชั้นอาจสร้างปัญหามากกว่าที่จะแก้ไข
โดยทั่วไปแล้วฉันไม่ชอบ APIs ที่ซ่อนสิ่งที่เกิดขึ้นภายใต้การนามธรรมที่มหัศจรรย์ นอกจากนี้สิ่งนี้ดูเหมือนจะรั่วไหล เนื่องจากมันทำนามธรรมบน socket.io แต่ต้องการให้คุณรู้ว่ามันทำงานอย่างไร
ความกังวลนี้เน้นย้ำถึงความตึงเครียดที่พบบ่อยในการพัฒนาซอฟต์แวร์ระหว่างความง่ายในการใช้งานและความโปร่งใส เมื่อการนามธรรมกลายเป็นแบบรั่วไหล นักพัฒนาต้องเข้าใจทั้งการนามธรรมและเทคโนโลยีพื้นฐาน ซึ่งอาจทำให้เส้นโค้งการเรียนรู้เพิ่มขึ้นเป็นสองเท่า
โซลูชันทางเลือกที่ได้รับความสนใจ
การอภิปรายนี้ยังได้นำความสนใจไปสู่โซลูชันที่มีอยู่แล้วซึ่งแก้ไขปัญหาที่คล้ายกัน ระบบการส่งข้อความ NATS เสนอรูปแบบ request-response พร้อมการสนับสนุนไลบรารีไคลเอนต์ระดับแรก รวมถึงความเข้ากันได้กับ WebSocket สำหรับแอปพลิเคชันเบราว์เซอร์ ระบบนี้สร้างหัวข้อชั่วคราวสำหรับการตอบกลับ โดยให้โมเดลการสื่อสารที่สะอาด
นักพัฒนาคนอื่นๆ ได้ชี้ไปที่ WebSocket transport ของ tRPC และโซลูชันการเก็บข้อมูลแบบ type-safe ของ Convex เป็นทางเลือกที่เป็นผู้ใหญ่ เครื่องมือเหล่านี้เสนอประโยชน์ด้านความปลอดภัยของประเภทที่คล้ายกัน ในขณะที่ให้ฟังก์ชันการทำงานที่กว้างขึ้นนอกเหนือจากการสื่อสาร socket เพียงอย่างเดียว
ทางเลือกอื่นที่กล่าวถึง:
- NATS: รูปแบบ request-response พร้อม ephemeral topics และรองรับ WebSocket
- tRPC: การส่งข้อมูลผ่าน WebSocket พร้อม type safety
- Convex: ความคงทนของข้อมูลแบบ type-safe และการสื่อสารผ่าน WebSocket
- socket.io: การใช้งานโดยตรงโดยไม่ต้องผ่านชั้น abstraction เพิ่มเติม
การตอบรับเชิงบวกสำหรับประสบการณ์นักพัฒนา
แม้จะมีความกังวลเกี่ยวกับชั้นการนามธรรม สมาชิกชุมชนบางคนก็ชื่นชมประสบการณ์นักพัฒนาที่ดีขึ้น การออกแบบที่เน้นความสะดวกสบายและการรวม TypeScript ของไลบรารีได้รับคำชมสำหรับการทำให้การสื่อสารแบบเรียลไทม์เข้าถึงได้มากขึ้น โดยเฉพาะสำหรับนักพัฒนาที่ชอบ APIs แบบฟังก์ชันมากกว่ารูปแบบที่ขับเคลื่อนด้วย event
ไลบรารี socket-call แสดงถึงวิวัฒนาการที่กำลังดำเนินอยู่ในวิธีที่นักพัฒนาเข้าหาการสื่อสารเว็บแบบเรียลไทม์ แม้ว่าจะเสนอประโยชน์ที่ชัดเจนในแง่ของความสามารถในการอ่านโค้ดและความปลอดภัยของประเภท การถกเถียงของชุมชนสะท้อนถึงคำถามที่กว้างขึ้นเกี่ยวกับเมื่อไหร่ที่การนามธรรมช่วยเหลือเมื่อเทียบกับเมื่อไหร่ที่มันขัดขวางการพัฒนาซอฟต์แวร์ เช่นเดียวกับเครื่องมือหลายๆ อย่าง คุณค่าน่าจะขึ้นอยู่กับกรณีการใช้งานเฉพาะและความชอบของทีม
อ้างอิง: socket-call