- Spine เป็นเฟรมเวิร์กเว็บแบ็กเอนด์บนพื้นฐาน Go ที่ไม่ซ่อนลำดับการทำงาน แต่แสดงให้เห็นอย่างชัดเจน
- Pipeline เดียวเป็นเจ้าของลำดับการทำงานทั้งหมด และ Controller โฟกัสเฉพาะ business logic
- เมธอดซิกเนเจอร์คือสัญญา API โดยตรง ไม่มี automation แบบ annotation หรือ convention
- ลำดับของคำขอสามารถมองเห็นได้อย่างชัดเจนจากโค้ด
- มุ่งเน้นความสามารถในการบำรุงรักษาระยะยาวและความง่ายในการติดตาม execution flow มากกว่าประสิทธิภาพการพัฒนาในช่วงเริ่มต้น
- ใช้ Echo เป็น HTTP Transport และออกแบบแบบไม่ผูกกับ ORM จึงเลือกใช้ Bun/GORM ฯลฯ ได้อย่างอิสระ
ภาพรวมของ Spine
Spine เป็นเฟรมเวิร์กที่มีเป้าหมายในการทำให้ execution flow ของ web request แสดงออกมาอย่างชัดเจน
เฟรมเวิร์กส่วนใหญ่มักซ่อนลำดับการทำงานไว้เพื่อความสะดวก แต่ Spine ตรึงลำดับนั้นไว้ในโครงสร้างโค้ด
มุ่งสู่โครงสร้างที่ตอบได้อย่างชัดเจนว่า "คำขอเริ่มต้นที่ไหน ใครเป็นผู้จัดการ และทำงานตามลำดับใด"
หลักการออกแบบ
นโยบายไร้เวทมนตร์
- มีเพียง Pipeline เท่านั้นที่รู้ลำดับการทำงาน
- ลดพฤติกรรมแบบ "จัดการให้เองอัตโนมัติ" ให้น้อยที่สุด
- การขยายและการทำงานทั้งหมดถูกลงทะเบียนแบบชัดเจนและมีลำดับที่คาดการณ์ได้
สัญญาแบบอิงซิกเนเจอร์
- เมธอดซิกเนเจอร์คือสัญญา API โดยตรง
- การสร้างอินพุตเป็นหน้าที่ของ ArgumentResolver ส่วนการจัดการเอาต์พุตเป็นหน้าที่ของ ReturnValueHandler
- ไม่อนุญาตการแมปแบบ annotation และการอนุมานอัตโนมัติจาก convention
ความเป็นอิสระของ Controller
- Controller ไม่ขึ้นต่อชนิด HTTP/Transport
- ใช้เฉพาะ semantic type อย่าง path., query., httperr.*
- ไม่จำเป็นต้องรู้ execution model แต่ระบุแหล่งที่มาของอินพุตผ่าน type อย่างชัดเจน
ความสามารถหลัก
Routing และพารามิเตอร์
- รองรับ Path Parameter (binding ตามลำดับ)
- ยูทิลิตี Query Values (parse Int, String, Boolean)
- auto binding สำหรับ Body DTO
การจัดการการตอบกลับ
- แปลง struct -> JSON อัตโนมัติผ่าน ReturnValueHandler
- map error -> HTTP status code อัตโนมัติ
- ประเภทข้อผิดพลาดเชิงความหมาย เช่น httperr.NotFound, BadRequest
Cross-cutting concerns
- Interceptor (PreHandle, PostHandle, AfterCompletion)
- มี CORS Interceptor ในตัว
- IoC Container แบบ constructor-based
สถาปัตยกรรม
- แยกชั้น Transport (ปัจจุบันคือ Echo และออกแบบให้สลับเปลี่ยนได้)
- ออกแบบแบบไม่ผูกกับ ORM (ใช้ Bun, GORM ฯลฯ ได้อย่างอิสระ ⚠️ ขณะนี้ยืนยันความเข้ากันได้กับ Bun เท่านั้น)
จุดแข็งในสภาพแวดล้อมขนาดใหญ่
เนื่องจากมีเพียงองค์ประกอบเดียวที่รู้ลำดับการทำงาน ต้นทุนในการติดตาม request flow จึงลดลง
cross-cutting concerns เช่น logging, transaction, security ถูกวางไว้ที่ Pipeline เท่านั้น ทำให้คาดการณ์จุดและจังหวะของการนำไปใช้ได้ เป็นกลยุทธ์ที่ยอมลด productivity ระยะแรกบางส่วนเพื่อดูดซับความซับซ้อนที่เพิ่มขึ้นในระยะยาวด้วยโครงสร้าง
สิ่งที่ Spine ไม่ใช่
- ไม่ใช่ตัวแทนของ Spring/NestJS
- ไม่ใช่เฟรมเวิร์กที่มุ่งเพิ่ม productivity สูงสุด
- ไม่ใช่เฟรมเวิร์ก automation แบบ annotation
- ไม่ใช่เฟรมเวิร์กที่ยึด HTTP Engine หรือ Router เป็นศูนย์กลาง
โปรเจกต์ที่ Spine ต้องการความช่วยเหลือ
Spine ยังไม่ใช่เฟรมเวิร์กที่เสร็จสมบูรณ์ และตั้งใจเผยแพร่ทั้งที่หลายส่วนยังไม่เสร็จ
จำเป็นต้องตรวจสอบว่าโครงสร้างอธิบายได้ดีพอหรือไม่ และ execution model แสดงปัญหาในโลกจริงได้ดีเพียงใด
วิธีมีส่วนร่วม
- กด ⭐️ บน GitHub เพื่อติดตามโปรเจกต์
- ลองใช้งานแล้วฝากความเห็นหรือข้อสงสัยไว้ใน issue
- ฝากคำวิจารณ์ ข้อเสนอแนะ หรือคำถามเกี่ยวกับการออกแบบไว้ในคอมเมนต์
ลิงก์อ้างอิง
- โปรเจกต์ Spine: https://github.com/NARUBROWN/spine
- Spine + Bun ORM User Demo: https://github.com/NARUBROWN/spine-user-demo
2 ความคิดเห็น
ถ้าช่วยปรับคำอธิบายของ AI อีกนิดให้เป็นประโยคที่เป็นธรรมชาติมากขึ้น ก็น่าจะช่วยเพิ่มความน่าเชื่อถือได้ครับ
สวัสดีครับ ขอบคุณมากสำหรับฟีดแบ็ก
ที่บอกว่าดูเหมือน AI หมายถึงโพสต์ใน GeekNews ใช่ไหมครับ?
ที่นี่ผมนึกว่าเดิมทีต้องเขียนแบบนี้ ^^… เพราะโพสต์อื่น ๆ ก็เป็นแบบนี้เลยตั้งใจเขียนแบบนี้เหมือนกัน
https://spine.na2ru2.me/ko/
นอกจากนี้ยังได้เปิดเว็บไซต์สำหรับเรียนรู้ spine เพิ่มเติมด้วย
ถ้าสนใจลองเข้าไปดูกันได้นะครับ ขอบคุณครับ