การกำหนดเส้นทางเซิร์ฟเวอร์ HTTP ที่ปรับปรุงแล้วใน Go 1.22

• บทความเกี่ยวกับการปรับปรุงความสามารถในการจับคู่แพตเทิร์นของ HTTP serving multiplexer พื้นฐานในแพ็กเกจ net/http ของ Go 1.22
• เดิมที multiplexer (http.ServeMux) มีการจับคู่เส้นทางพื้นฐาน ทำให้ต้องใช้ไลบรารี 3rd party เมื่อต้องการความสามารถขั้นสูง
• multiplexer ใหม่ของ Go 1.22 มอบการจับคู่ขั้นสูง ช่วยลดช่องว่างเมื่อเทียบกับแพ็กเกจ 3rd party
• multiplexer (mux) ใหม่นี้สามารถระบุ HTTP method อย่างชัดเจนเป็นส่วนหนึ่งของแพตเทิร์น และรองรับการจับคู่แบบ wildcard ในองค์ประกอบของเส้นทาง
• ในบทความมีตัวอย่างการใช้งาน mux ใหม่ รวมถึงการจัดการความขัดแย้งที่อาจเกิดขึ้นระหว่างแพตเทิร์นต่าง ๆ
• เอกสารของ ServeMux ใหม่อธิบายกฎลำดับความสำคัญของแพตเทิร์นและความขัดแย้งที่อาจเกิดขึ้น
• บทความยังกลับไปทบทวนตัวอย่างจากซีรีส์ REST server ใน Go และเปรียบเทียบว่า mux ใหม่ใน stdlib มีลักษณะอย่างไรเมื่อเทียบกับ gorilla/mux
• mux ใหม่ของ Go 1.22 ทำให้สามารถทำ routing ที่ซับซ้อนขึ้นได้ และลดความจำเป็นในการตัดสินใจ routing ภายใน handler
• ผู้เขียนเชื่อว่าความสามารถที่ดีขึ้นใน Go 1.22 จะเปลี่ยนคำตอบทั่วไปของคำถามว่า "ควรใช้แพ็กเกจ router ตัวไหนดี?" โดยหลายคนน่าจะมองว่า mux ใหม่ใน stdlib เพียงพอกับความต้องการของตน
• อย่างไรก็ตาม โปรแกรมเมอร์ Go บางส่วนอาจยังคงชอบแพ็กเกจ 3rd party หรือเฟรมเวิร์กขนาดเบาอย่าง Gin ซึ่งมีทั้ง router และเครื่องมือเพิ่มเติมสำหรับสร้างเว็บแบ็กเอนด์
• โดยรวมแล้ว ผู้เขียนมองว่าความสามารถที่ดีขึ้นใน Go 1.22 เป็นการเปลี่ยนแปลงเชิงบวกสำหรับผู้ใช้ Go ทุกคน ทำให้ไลบรารีมาตรฐานมีความสามารถมากขึ้นและเป็นประโยชน์ต่อชุมชนโดยรวม

[GN⁺]

ความคิดเห็นจาก Hacker News

• บทความเกี่ยวกับการกำหนดเส้นทาง HTTP server แบบใหม่ใน Go 1.22
• ผู้ใช้บางคนเข้าใจได้ยากกับ panic ที่เกิดขึ้นเมื่อมีสอง route ที่ตรงกัน โดยเว็บเฟรมเวิร์กส่วนใหญ่มักใช้ route แรกที่ลงทะเบียนไว้ซึ่งตรงกัน
• การเก็บถาวรและการยกเลิกการเก็บถาวรของโปรเจ็กต์ gorrila/mux ทำให้เกิดความสับสน แต่บางคนมองว่านี่เป็นหลักฐานถึงความมั่นคงของโปรเจ็กต์โอเพนซอร์ส
• มีเสียงวิจารณ์ต่อไวยากรณ์ที่เสนอ โดยบางคนเสนอให้ใช้อาร์กิวเมนต์จริงแทนการสร้าง magic string เพื่อกำหนด handler
• ผู้ใช้บางคนไม่ชอบการใช้ prefix ของเมธอดที่แปลงเป็นสตริง และชอบ type safety ของเมธอดที่แยกตามคำกริยามากกว่า
• มีคำถามว่าเมื่อ route ตรงกันแต่เมธอดไม่ตรงกันจะเกิดอะไรขึ้น ซึ่งคำตอบคือ 405 พร้อม Allow header ที่ถูกเติมอย่างเหมาะสม
• มีข้อเสนอแนะว่าผู้ใช้ที่มีความต้องการขั้นสูงควรพิจารณาตัวเลือกอื่นหรือเขียน router ของตนเอง แทนที่จะใช้ sub mux พื้นฐาน
• บางคนชอบให้เส้นทางที่ซ้อนทับกันจับคู่ตามลำดับที่ถูกกำหนด มากกว่าที่จะ panic
• ผู้ใช้บางคนไม่ชอบข้อเสนอนี้ โดยเฉพาะการรวม HTTP request method ไว้ใน URI
• มีคำวิจารณ์ต่อ ServeMux เริ่มต้นที่จัดการทุกอย่างเมื่อที่อยู่นั้นเป็น prefix โดยไม่มีวิธีง่าย ๆ สำหรับการจัดการแบบตรงกันเป๊ะ
• แต่ผู้ใช้บางคนก็มองว่าการกำหนดเส้นทางแบบใหม่นี้เป็นการเปลี่ยนแปลงในทางบวก ช่วยลด dependency ภายนอกและเพิ่มประสิทธิภาพการทำงาน