Exploring Go through backend engineering practices (Part 2)

Adexandria — Thu, 07 May 2026 07:46:44 +0000

Error Handling

In Part 2, I explore how error handling works in Go and how structured logging can be used to surface and trace failures effectively.

Go takes a fundamentally different approach to error handling. Without a
try/catch mechanism, errors are explicitly returned and handled at each step. While this may not seem substantial at first, it leads to more predictable and transparent control flow.

func (r *TaskRepository) GetAll(page int, pageSize int) []models.Task {
    ctx := context.Background()

    tasks, err := gorm.G[models.Task](r.Db).Limit(pageSize).Offset((page - 1) * pageSize).Order("created_at").Find(ctx)

    if err != nil {
        r.Log.Error("Failed to get all tasks" + err.Error())
        return []models.Task{}
    }
    return tasks

}

Logging using slog

For logging, I used slog with a JSONHandler to produce structured logs. This format makes logs significantly easier to parse and analyze, especially in distributed or production environments. The logger is registered within the dependency container, allowing it to be injected across layers, including the repository. This ensures consistent logging while still capturing context-specific details at different points in the application.

func generateHandler() *slog.JSONHandler {
    return slog.NewJSONHandler(os.Stderr, nil)
}

func CreateContainer() *dig.Container {
    container := RegisterDb()
        // Register json handler
    err = container.Provide(generateHandler)
    if err != nil {
        panic(err)
    }
    return container
}

Consistent API Response

Another focus was on establishing a consistent API response model. Standardizing responses simplifies both testing and error handling by providing a predictable structure for all outcomes.

The API defines two response types: one for operations that return data and one for those that do not.

The ActionResult type includes a status code, an IsSuccess flag, and an optional error field. This error represents domain-level failures and provides a clear signal when a request does not succeed.

type ActionResult struct {
    StatusCode int
    IsSuccess  bool
    Error      []string
}

ActionResultModel builds on this by introducing a generic Data field, allowing responses to carry typed payloads. This was a practical way to explore generics in Go, as well as underlying types to achieve composition. While Go is not an object-oriented programming language, it provides flexible mechanisms to model similar patterns without relying on inheritance.

type ActionResultModel[T any] struct {
    Data T
    ActionResult
}

Swagger documentation

While I’ve used Swagger before, implementing it in Go felt quite different. The Go community embraces a strong “build it yourself” mindset, which I appreciate—I enjoy that level of control, though not in every situation. Writing OpenAPI specifications for each endpoint was a great learning experience, but it’s easy to see how it could become overwhelming with a larger number of endpoints.

Next Up

Implementing request validation alongside authentication and authorization to ensure robust and secure API interactions.

Exploring Go through backend engineering practices (Part 1)

Adexandria — Tue, 21 Apr 2026 12:08:42 +0000

During my first week working with Golang, I focused less on basic syntax and more on applying familiar backend engineering principles within a new ecosystem. The goal wasn’t just to learn Go, but to understand how established patterns translate into its design philosophy.

To explore this, I built a simple to-do list API using the Gin framework, SQLite for persistence, and Uber’s Dig for dependency injection.

Project Architecture

The application follows a layered architecture to maintain separation of concerns:

Handlers: manage HTTP requests and responses
Services: contain business logic and orchestrate operations
Repositories: handle data access and database interactions
Models: define domain entities and DTOs

This structure ensures that each layer has a clear responsibility, making the system easier to maintain and extend.

Database Integration

The first step was establishing a connection to SQLite using GORM. This provides a convenient abstraction over SQL while still allowing control when needed.

func connect() *gorm.DB {
    db, err := gorm.Open(sqlite.Open("todo.db"), &gorm.Config{})
    if err != nil {
        panic(err)
    }

    err = db.AutoMigrate(&models.Task{})
    if err != nil {
        panic("failed to connect database")
    }
    return db
}

Dependency Injection in Go

Unlike frameworks that rely heavily on implicit dependency wiring, Go encourages explicit composition. To manage dependencies cleanly, I used Dig to construct a container for all registered components.

Instead of instantiating dependencies directly in main, constructors are registered and resolved through the container.

// Registers db dependency used to connect to the SQLite
func RegisterDb() *dig.Container {
    container := dig.New()

    err := container.Provide(connect)
    if err != nil {
        panic(err)
    }

    return container
}

Repository Pattern and Abstraction

To decouple business logic from data access, I implemented the repository pattern. By depending on interfaces rather than concrete implementations, the application remains flexible to future changes (e.g., switching implementation of a behaviour).
Concrete implementations are then registered with the DI container as the interface type, allowing seamless resolution across layers.

Application Bootstrap

Finally, the application is wired together in main. The DI container is built, handlers are registered, routes are initialized, and the server is exposed on port 8080

func main() {
    container := services.CreateContainer()

    err := container.Provide(handlers.TaskHandler)
    if err != nil {
        panic(err)
    }

    router := gin.Default()

    err = container.Invoke(func(h *handlers.Handler) {
        publicRoutes := router.Group("/api/tasks")

        publicRoutes.GET("/:id", h.GetTaskById)
        publicRoutes.POST("/create", h.CreateTask)
        publicRoutes.PUT("/:id", h.UpdateTask)
        publicRoutes.DELETE("/:id", h.DeleteTask)
        publicRoutes.GET("/", h.GetAllTasks)
        publicRoutes.GET("/filter", h.FilterTasks)
        publicRoutes.GET("/search", h.SearchByTask)
    })

    if err != nil {
        panic(err)
    }

    err = router.Run(":8080")
    if err != nil {
        return
    }

}

Final Thoughts
Working with Go has been less about learning new concepts and more about rethinking how familiar patterns are applied in a language that prioritizes simplicity and explicitness. While the ecosystem differs from more opinionated frameworks, the core engineering principles remain consistent.

Next, I’ll focus on strengthening observability with structured logging and implementing more robust error handling.

View the github repo

Forem: Adexandria