How I write Go APIs in my experience with Fuego

My Experience Building Go APIs with Fuego

As a Go developer with several years of experience, I've explored various web frameworks. My journey included the standard library, Gin, and Fiber. While each has merits, I often found myself needing more structure or spending excessive time integrating multiple libraries for validation, serialization, and documentation. That's where Fuego changed the game.

Initially, Fuego seemed like just another framework. However, its use of modern Go features, particularly generics, to automatically generate OpenAPI specifications directly from code, intrigued me. I decided to test it on a small internal project, and here's my honest account.

---

First Impressions

Fuego's simplicity was immediately apparent. Setting up a basic server took mere minutes:

<code class="language-go">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()
}</code>

The familiarity was striking—similar to Gin, but with built-in OpenAPI support.

---

A Real-World Example

The "Hello World" example doesn't reflect real-world complexities. My application required JSON data handling, validation, and typed responses. Other frameworks necessitate custom JSON decoding, error handling, and middleware integration. Fuego streamlined this considerably using typed route handlers.

Here's a simplified route handler:

<code class="language-go">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
}</code>

Key improvements:

1. Typed Handlers: fuego.ContextWithBody[UserInput] automatically deserializes JSON into the UserInput struct.
2. Validation: validate:"required" ensures the Name field is present; Fuego handles errors gracefully.
3. Responses: Returning a UserOutput struct automatically serializes it to JSON.

This eliminated significant boilerplate code—no json.Unmarshal, external validation libraries, or custom error handling.

---

Why Fuego Stands Out

1. Native Go Feel: Unlike frameworks that heavily wrap net/http, Fuego feels remarkably native. It utilizes net/http directly, allowing seamless integration of standard middleware and handlers. I reused existing authentication middleware without issues.

2. Automatic OpenAPI Generation: I previously managed separate YAML files or relied on comments for OpenAPI specs, a tedious and error-prone process. Fuego automatically generates the spec from route handler types, ensuring documentation always stays current.

3. Validation and Error Handling: The integrated validation (using go-playground/validator) was intuitive, and error handling was simplified. Invalid UserInput structs resulted in structured error messages adhering to RFC standards.

---

Data Transformations

To ensure all incoming Name fields were lowercase, I leveraged Fuego's InTransform method:

<code class="language-go">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()
}</code>

This automatically transforms data before reaching the route handler.

---

Challenges Encountered

1. Smaller Ecosystem: Fuego's smaller user base compared to Gin or Echo resulted in fewer readily available community resources. However, the repository's examples and documentation proved sufficient.

2. Limited Built-in Middleware: While Fuego provides some middleware, it's not as extensive as some older frameworks. net/http compatibility allowed using external libraries or custom middleware.

---

Conclusion

Fuego offers a compelling balance of convenience and flexibility. It accelerates API development with built-in validation, serialization, and documentation generation, while remaining true to Go's principles. Using typed structs and letting Fuego manage the rest significantly improved my workflow.

Key benefits:

• Increased Productivity: Cleaner code and reduced boilerplate.
• Automated Documentation: Always up-to-date OpenAPI specifications.
• Smooth Transitions: Easy integration with existing net/http handlers.

If you're seeking a modern, flexible Go framework, especially if you're weary of manual OpenAPI maintenance, I strongly recommend Fuego. It simplified my development process while staying true to Go's minimalist philosophy. The GitHub repository provides comprehensive information and a promising roadmap. I'm enthusiastic about its future and will continue using it for future projects.

The above is the detailed content of How I write Go APIs in my experience with Fuego. For more information, please follow other related articles on the PHP Chinese website!