Feather ซึ่งเป็นเฟรมเวิร์คเว็บน้ำหนักเบาสำหรับ Rust ที่ได้แรงบันดาลใจจาก Express.js ได้จุดประเด็นถกเถียงอย่างมากในชุมชนนักพัฒนาเกี่ยวกับการออกแบบและคุณลักษณะด้านประสิทธิภาพ แม้ว่าเฟรมเวิร์คนี้มุ่งเน้นที่จะนำเสนอสถาปัตยกรรมแบบ middleware-first ที่เรียบง่ายโดยเน้นประสบการณ์ของนักพัฒนา แต่สมาชิกในชุมชนได้ระบุข้อจำกัดพื้นฐานหลายประการที่อาจส่งผลกระทบต่อประโยชน์การใช้งานจริง
สถาปัตยกรรมแบบ Single-Threaded สร้างความกังวล
คำวิจารณ์ที่โดดเด่นที่สุดเกี่ยวข้องกับลักษณะแบบ single-threaded ของ Feather การวิเคราะห์ทางเทคนิคโดยสมาชิกในชุมชนเปิดเผยว่าเฟรมเวิร์คนี้ประมวลผลคำขอแบบลำดับ (sequentially) แทนที่จะเป็นแบบพร้อมกัน (concurrently) ซึ่งสร้างคอขวดที่จำกัดประสิทธิภาพภายใต้โหลด นักพัฒนาคนหนึ่งได้แสดงข้อจำกัดนี้ด้วยการทดสอบอย่างง่ายที่แสดงให้เห็นว่าเมื่อมีคำขอพร้อมกันสองรายการไปยังเซิร์ฟเวอร์ที่มีเวลาประมวลผล 2 วินาที คำขอที่สองจะใช้เวลา 4 วินาทีในการทำงานให้เสร็จสิ้นเพราะต้องรอให้คำขอแรกเสร็จสิ้นก่อน
การที่คำขอสามารถรับการอ้างอิงแบบ mutable ไปยังบริบทที่ใช้ร่วมกันได้อย่างง่ายดายทำให้ผมรู้สึกสงสัย ดังนั้นผมจึงทำการทดสอบอย่างรวดเร็ว และดูเหมือนว่าเซิร์ฟเวอร์ทั้งหมดเป็นแบบ single-threaded... เมื่อตัวจัดการคำขอใช้เวลา 2 วินาที และคุณส่งคำขอสองรายการพร้อมกัน คำขอหนึ่งจะตอบกลับใน 2 วินาที แต่อีกคำขอหนึ่งใช้เวลา 4 วินาที เพราะต้องรอให้คำขอแรกเสร็จสิ้นก่อนที่จะเริ่มต้นได้
ทางเลือกในการออกแบบนี้ดูเหมือนจะมาจากแนวทางการจัดการสถานะของ Feather ซึ่งอนุญาตให้เข้าถึงบริบทที่ใช้ร่วมกันแบบ mutable โดยตรงโดยไม่มีตัวห่อที่ปลอดภัยสำหรับเธรดเช่น Arc<Mutex> แม้ว่าสิ่งนี้จะทำให้ API ง่ายขึ้น แต่มันสร้างข้อจำกัดด้านการทำงานพร้อมกันที่ขัดแย้งกับชื่อเสียงของ Rust ในด้านการเขียนโปรแกรมแบบพร้อมกันที่ปลอดภัย
ข้อจำกัดหลักของ Feather Framework:
- การประมวลผลคำขอแบบเธรดเดียว
- การบล็อกแบบ Head-of-line สำหรับคำขอที่เข้ามาพร้อมกัน
- ต้องใช้โค้ดมาตรฐาน MiddlewareResult::Next ในตัวจัดการเส้นทาง
- ขาดการจัดการสถานะแบบปลอดภัยต่อเธรด (ไม่มีรูปแบบ Arc<Mutex<T>>)
เฟรมเวิร์คเว็บอื่นๆ ใน Rust:
- Rocket: มัลติเธรดพร้อม API ตัวจัดการเส้นทางแบบซิงโครนัส
- Axum: ใช้ระบบ Async แต่มีประสิทธิภาพสูงกว่า
คุณสมบัติของเฟรมเวิร์ค:
- สถาปัตยกรรมที่เน้น Middleware เป็นหลัก
- API บริบทสำหรับการจัดการสถานะ
- มีระบบยืนยันตัวตน JWT ในตัว (คุณสมบัติเสริม)
- ไม่จำเป็นต้องใช้โค้ด async
การแลกเปลี่ยนระหว่างประสบการณ์นักพัฒนากับประสิทธิภาพ
Feather ทำการตลาดตัวเองว่าเป็น DX-first โดยให้ความสำคัญกับประสบการณ์นักพัฒนามากกว่าข้อพิจารณาอื่นๆ เฟรมเวิร์คนี้พยายามสร้างความแตกต่างโดยหลีกเลี่ยงโมเดลการเขียนโปรแกรมแบบ async ของ Rust ซึ่งอาจเป็นความท้าทายสำหรับผู้เริ่มต้น ผู้แสดงความคิดเห็นหลายคนยอมรับว่า async Rust สร้างภาระทางความคิดที่สำคัญ โดยเฉพาะอย่างยิ่งสำหรับนักพัฒนาที่มาจากภาษาเช่น Python, C#, Java หรือ C++
อย่างไรก็ตาม สมาชิกชุมชนคนอื่นๆ ตั้งคำถามว่าแนวทางของ Feather มอบประสบการณ์นักพัฒนาที่ดีกว่าจริงหรือไม่ โดยสังเกตว่าโค้ด boilerplate ที่จำเป็น (เช่น ค่าการส่งคืน MiddlewareResult::Next ที่บังคับ) สร้างการทำซ้ำที่ไม่จำเป็น บางคนชี้ไปที่เฟรมเวิร์คทางเลือกเช่น Rocket ซึ่งสามารถให้ API แบบ synchronous สำหรับตัวจัดการเส้นทางในขณะที่ยังคงรักษาประสิทธิภาพแบบ multi-threaded ไว้ใต้ฝากระโปรง
กรณีการใช้งานและทางเลือก
การอภิปรายเน้นย้ำว่าแนวทางของ Feather อาจเหมาะสำหรับโครงการเพื่อการศึกษาขนาดเล็กหรือแอปพลิเคชันที่มีความต้องการด้านประสิทธิภาพน้อย อย่างไรก็ตาม สำหรับงานในระดับการผลิต นักพัฒนาส่วนใหญ่ชอบทางเลือกที่มีอยู่แล้วซึ่งสร้างความสมดุลระหว่างความง่ายในการใช้งานกับประสิทธิภาพได้ดีกว่า
การเปรียบเทียบประสิทธิภาพก็ได้รับการอภิปรายด้วย โดยมีการอ้างอิงถึง TechEmpower benchmarks ที่แสดงให้เห็นว่าเฟรมเวิร์คเว็บ Rust ที่ออกแบบมาอย่างดีมักจะมีประสิทธิภาพดีกว่าเฟรมเวิร์คที่เขียนด้วย Go, Node.js หรือ Python ข้อได้เปรียบด้านประสิทธิภาพนี้เป็นหนึ่งในเหตุผลหลักที่นักพัฒนาพิจารณาใช้ Rust สำหรับการพัฒนาเว็บเซิร์ฟเวอร์ตั้งแต่แรก ซึ่งทำให้ข้อจำกัดแบบ single-threaded ของ Feather เป็นปัญหาอย่างยิ่ง
โดยสรุป แม้ว่า Feather พยายามนำความเรียบง่ายแบบ Express.js มาสู่การพัฒนาเว็บด้วย Rust แต่ทางเลือกในการออกแบบสถาปัตยกรรมของมันสร้างข้อจำกัดด้านประสิทธิภาพที่สำคัญ สำหรับนักพัฒนาที่ต้องการใช้ประโยชน์จากประสิทธิภาพของ Rust ในแอปพลิเคชันเว็บ ทางเลือกอื่นที่จัดการกับการทำงานพร้อมกันได้ดีกว่าในขณะที่ยังคงให้ประสบการณ์นักพัฒนาที่ดีอาจเป็นตัวเลือกที่เหมาะสมกว่า
อ้างอิง: Feather