Feather，一個受 Express.js 啟發的輕量級 Rust web 框架，在開發者社群引發了關於其設計選擇和效能特性的重要討論。雖然該框架旨在提供簡單、以中介軟體為先的架構，並強調開發者體驗，但社群成員已經發現了幾個可能影響其實用性的基本限制。
單執行緒架構引發擔憂
最突出的批評圍繞著 Feather 的單執行緒特性。社群成員的技術分析揭示，該框架按順序處理請求而非併發處理，這造成了限制負載下效能的瓶頸。一位開發者透過一個簡單的測試展示了這一限制：當向一個處理時間為2秒的伺服器同時傳送兩個請求時，第二個請求需要4秒才能完成，因為它必須等待第一個請求完成才能開始。
「一個請求可以輕鬆獲取共享上下文的可變引用這一點讓我感到可疑，所以我進行了一個快速測試，結果表明整個伺服器似乎是單執行緒的...當請求處理器需要2秒鐘，而你同時傳送兩個請求時，其中一個在2秒後返回，但另一個需要4秒，因為它必須等待第一個請求完成才能開始。」
這種設計選擇似乎源於 Feather 的狀態管理方法，它允許直接可變訪問共享上下文，而不需要像 Arc<Mutex> 這樣的執行緒安全包裝器。雖然這簡化了 API，但它創造了一個與 Rust 安全併發程式設計聲譽相矛盾的基本併發限制。
Feather 框架的主要侷限性：
- 單執行緒請求處理
- 併發請求的隊頭阻塞問題
- 路由處理器中需要 MiddlewareResult::Next 樣板程式碼
- 缺乏執行緒安全的狀態管理（沒有 Arc<Mutex<T>> 模式）
替代的 Rust Web 框架：
- Rocket：多執行緒且具有同步路由處理器 API
- Axum：基於非同步但效能更高
框架特點：
- 中介軟體優先架構
- 用於狀態管理的上下文 API
- 內建 JWT 認證（可選功能）
- 不需要非同步程式碼
開發者體驗與效能的權衡
Feather 將自己定位為以開發者體驗（DX）為先，優先考慮開發者體驗而非其他因素。該框架試圖透過避免 Rust 的非同步程式設計模型來區分自己，因為非同步程式設計對新手來說可能具有挑戰性。幾位評論者承認，非同步 Rust 確實帶來了顯著的心智負擔，特別是對於來自 Python、C#、Java 或 C++ 等語言的開發者。
然而，其他社群成員質疑 Feather 的方法是否真的提供了更好的開發者體驗，他們指出所需的樣板程式碼（如強制性的 MiddlewareResult::Next 返回值）創造了不必要的重複。一些人指向了像 Rocket 這樣的替代框架，它能夠為路由處理程式提供同步 API，同時在底層仍保持多執行緒效能。
使用場景和替代方案
討論強調，Feather 的方法可能適用於小型教育專案或效能要求最低的應用程式。然而，對於生產工作負載，大多數開發者更傾向於那些能更好地平衡易用性和效能的成熟替代方案。
討論中還提到了效能比較，引用了 TechEmpower 基準測試，顯示設計良好的 Rust web 框架通常比用 Go、Node.js 或 Python 編寫的框架效能更好。這種效能優勢是開發者首先考慮使用 Rust 進行 web 伺服器開發的主要原因之一，這使得 Feather 的單執行緒限制尤為問題。
總之，雖然 Feather 試圖將 Express.js 式的簡潔性引入 Rust web 開發，但其架構選擇創造了顯著的效能限制。對於希望在 web 應用程式中利用 Rust 效能優勢的開發者來說，那些能更好地處理併發性同時仍提供良好開發者體驗的替代方案可能是更合適的選擇。
參考：Feather