Fuego での経験から Go API を作成する方法

Fuego を使用して Go API を構築した私の経験

数年の経験を持つ Go 開発者として、私はさまざまな Web フレームワークを検討してきました。 私の旅には、標準ライブラリ、Gin、Fiber が含まれていました。 それぞれに利点がありますが、検証、シリアル化、ドキュメント化のために複数のライブラリを統合するために、より多くの構造が必要になったり、過度の時間が費やされたりすることがよくありました。 そこでフエゴが試合を変えた。

当初、Fuego は単なるフレームワークのように思えました。しかし、最新の Go 機能、特にジェネリックスを使用して OpenAPI 仕様をコードから直接自動的に生成することに、私は興味をそそられました。小規模な社内プロジェクトでテストすることにしました。これが私の正直な説明です。

---

第一印象

フエゴの単純さはすぐに分かりました。 基本的なサーバーのセットアップにはほんの数分しかかかりませんでした:

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、外部検証ライブラリ、カスタム エラー処理が不要になりました。

---

なぜフエゴが傑出しているのか

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. 小規模なエコシステム: Jin や Echo と比較して、Fuego のユーザー ベースが小さいため、すぐに利用できるコミュニティ リソースが少なくなります。ただし、リポジトリの例とドキュメントで十分であることがわかりました。

2. 限定された組み込みミドルウェア: Fuego はいくつかのミドルウェアを提供しますが、一部の古いフレームワークほど広範囲ではありません。 net/http 外部ライブラリまたはカスタムミドルウェアを使用すると互換性が許可されます。

---

結論

フエゴは、利便性と柔軟性の魅力的なバランスを提供します。 Go の原則に忠実でありながら、組み込みの検証、シリアル化、ドキュメント生成により API 開発を加速します。 型付き構造体を使用し、Fuego に残りの管理を任せることで、ワークフローが大幅に改善されました。

主な利点:

• 生産性の向上: コードがすっきりし、定型文が削減されます。
• 自動ドキュメント: 常に最新の OpenAPI 仕様。
• スムーズな移行: 既存の net/http ハンドラーと簡単に統合できます。

最新で柔軟な Go フレームワークを探している場合、特に OpenAPI の手動メンテナンスにうんざりしている場合は、Fuego を強くお勧めします。これにより、Go のミニマリスト哲学に忠実でありながら、開発プロセスが簡素化されました。 GitHub リポジトリは、包括的な情報と有望なロードマップを提供します。私はその将来性に非常に期待しており、今後のプロジェクトでも引き続き使用していきます。

以上がFuego での経験から Go API を作成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。