根據我使用 Fuego 的經驗，我是如何編寫 Go API 的

我使用 Fuego 建立 Go API 的經驗

身為一名擁有多年經驗的 Go 開發人員，我探索了各種 Web 框架。 我的旅程包括標準庫、Gin 和 Fiber。 雖然每個庫都有優點，但我經常發現自己需要更多的結構或花費過多的時間來整合多個庫以進行驗證、序列化和文件記錄。 這就是 Fuego 改變遊戲規則的地方。

最初，Fuego 看起來只是另一個框架。然而，它使用現代 Go 功能（特別是泛型）來直接從程式碼自動產生 OpenAPI 規範，這引起了我的興趣。我決定在一個小型內部專案上測試它，這是我的誠實帳戶。

---

第一印象

Fuego 的簡單性立即顯而易見。 設定基本伺服器只需幾分鐘：

package main

import "github.com/go-fuego/fuego"

func main() {
    s := fuego.NewServer()
    fuego.Get(s, "/", func(c fuego.ContextNoBody) (string, error) {
        return "Hello, World!", nil
    })
    s.Run()
}

熟悉程度是驚人的——類似於 Gin，但具有內建的 OpenAPI 支援。

---

現實世界的例子

「Hello World」範例並未反映現實世界的複雜性。我的應用程式需要 JSON 資料處理、驗證和類型化回應。 其他框架需要自訂 JSON 解碼、錯誤處理和中間件整合。 Fuego 使用類型化路由處理程序大幅簡化了這個過程。

這是一個簡化的路由處理程序：

type UserInput struct {
    Name string `json:"name" validate:"required"`
}

type UserOutput struct {
    Message string `json:"message"`
}

func main() {
    s := fuego.NewServer()
    fuego.Post(s, "/user", handleUser)
    s.Run()
}

func handleUser(c fuego.ContextWithBody[UserInput]) (UserOutput, error) {
    in, err := c.Body()
    if err != nil {
        return UserOutput{}, err
    }
    return UserOutput{Message: "Hello, " + in.Name}, nil
}

主要改善：

1. 類型化處理程序： fuego.ContextWithBody[UserInput] 自動將 JSON 反序列化為 UserInput 結構。
2. 驗證： validate:"required" 確保 Name 欄位存在； Fuego 優雅地處理錯誤。
3. 回應： 回傳 UserOutput 結構會自動將其序列化為 JSON。

這消除了重要的樣板程式碼 - 沒有 json.Unmarshal、外部驗證庫或自訂錯誤處理。

---

為什麼 Fuego 會脫穎而出

1. 原生 Go 感覺： 與大量包裹 net/http 的框架不同，Fuego 感覺非常原生。它直接利用 net/http，允許標準中間件和處理程序的無縫整合。我重複使用了現有的身份驗證中間件，沒有出現任何問題。

2. 自動 OpenAPI 產生： 我以前管理單獨的 YAML 檔案或依賴 OpenAPI 規範的註釋，這是一個乏味且容易出錯的過程。 Fuego 會自動根據路由處理程序類型產生規範，確保文件始終保持最新狀態。

3. 驗證和錯誤處理：整合驗證（使用go-playground/validator）非常直觀，並且簡化了錯誤處理。無效的 UserInput 結構會導致符合 RFC 標準的結構化錯誤訊息。

---

資料轉換

為了確保所有傳入的 Name 欄位都是小寫，我利用了 Fuego 的 InTransform 方法：

package main

import "github.com/go-fuego/fuego"

func main() {
    s := fuego.NewServer()
    fuego.Get(s, "/", func(c fuego.ContextNoBody) (string, error) {
        return "Hello, World!", nil
    })
    s.Run()
}

這會在到達路由處理程序之前自動轉換資料。

---

遇到的挑戰

1. 較小的生態系統：與 Gin 或 Echo 相比，Fuego 的使用者群較小，導致可用的社群資源較少。然而，事實證明，儲存庫的範例和文件已經足夠了。

2. 有限的內建中間件：雖然 Fuego 提供了一些中間件，但它並不像一些舊框架那麼廣泛。 net/http 允許使用外部函式庫或自訂中間件的相容性。

---

結論

Fuego 提供了便利性和靈活性之間令人信服的平衡。 它透過內建驗證、序列化和文件生成加速 API 開發，同時保持 Go 的原則。 使用類型化結構並讓 Fuego 管理其餘部分顯著改善了我的工作流程。

主要優點：

• 提高生產力：更清晰的程式碼和減少樣板檔案。
• 自動化文件：始終保持最新的 OpenAPI 規格。
• 平滑過渡：與現有的net/http處理程序輕鬆整合。

如果您正在尋找一個現代、靈活的 Go 框架，特別是如果您厭倦了手動 OpenAPI 維護，我強烈推薦 Fuego。它簡化了我的開發過程，同時忠於 Go 的極簡主義哲學。 GitHub 儲存庫提供了全面的資訊和有前景的路線圖。我對它的未來充滿熱情，並將繼續在未來的專案中使用它。

以上是根據我使用 Fuego 的經驗，我是如何編寫 Go API 的的詳細內容。更多資訊請關注PHP中文網其他相關文章！