DEV Community: Brender Adhiambo

Why I Chose Chi for My Go Backend

Brender Adhiambo — Wed, 02 Sep 2026 04:47:35 +0000

When I started building my Go backend, one of the decisions I had to make was which router to use.

There are quite a few options in the Go ecosystem, but I decided to go with Chi.

I had used Go for smaller projects before, but building a larger backend made me realize that choosing the right tools is just as important as writing the code itself.

I wasn't looking for something that would build the whole application for me. I wanted something that would handle routing and give me enough flexibility to decide how the rest of my backend should be structured.

That's where Chi came in.

Why Chi?

The first thing I liked about Chi was its simplicity.

Chi doesn't try to do everything for you. It focuses mainly on routing and middleware, while allowing you to structure the rest of your application the way you want.

For my project, that was exactly what I needed.

A simple route can look like this:

r := chi.NewRouter()

r.Get("/users", getUsers)
r.Post("/users", createUser)

There isn't much happening here, and that's actually what I liked about it.

The route tells me exactly what it does. A GET request goes to one handler, while a POST request goes to another.

As I worked on the backend, I started understanding these things more clearly instead of just copying patterns from examples.

That was important for me because I wasn't only trying to make the application work. I was also trying to understand why it was structured that way.

Working With Middleware

Another part of Chi that I found useful was middleware.

When I first started working with backend applications, I mostly thought about routes and handlers. As the project became bigger, I realized there was a lot of functionality that didn't belong inside individual handlers.

Things like logging, authentication, recovering from panics, and checking requests are good examples.

Chi made it easy to apply middleware to my routes.

For example:

r.Use(middleware.Logger)
r.Use(middleware.Recoverer)

This helped me understand an important backend concept: not everything needs to live inside the handler.

Middleware sits between the incoming request and the handler. It can perform some work before the request reaches the handler and, depending on the middleware, also work with the response afterward.

That changed how I thought about structuring my backend.

Instead of putting everything into one function, I could separate responsibilities and make each part easier to understand.

Route Groups

As I added more endpoints, I also started organizing routes into groups.

For example:

r.Route("/api", func(r chi.Router) {
r.Route("/users", func(r chi.Router) {
r.Get("/", getUsers)
r.Post("/", createUser)
})
})

This became more useful as the application grew.

Having all the routes in one large list can quickly become difficult to maintain. Grouping them allowed me to organize endpoints around different parts of the application.

It also made the router easier to read.

When I looked at my routes, I could get a quick idea of how the API was organized without having to search through the entire application.

Chi and My Backend Structure

One of the biggest things I learned while using Chi was that the router is only one part of a backend.

It is easy to think that building an API is mostly about creating endpoints, but there is much more happening behind each request.

A request can go through middleware, reach a handler, be validated, interact with the database, and eventually return a response.

Working with Chi made me pay more attention to these boundaries.

I started thinking more carefully about questions like:

What should the router be responsible for?
What belongs in the handler?
Where should validation happen?
Where should database logic live?
Which functionality should be middleware?
How should different parts of the API be organized?

These questions became more important as my project grew.

Instead of putting everything into one place just because it worked, I started thinking about how I could keep the code easier to maintain.

What I Learned

Using Chi taught me more than just how to create routes.

It helped me understand how a Go backend is structured and how different parts of a request move through an application.

I became more comfortable working with:

HTTP methods
Routes and handlers
Middleware
Route groups
API structure
Request handling
Separation of responsibilities

I also learned that a framework doesn't need to be complicated to be useful.

Before using Chi, I sometimes assumed that a more feature-heavy framework would automatically make backend development easier.

My experience was a little different.

Having a lightweight router meant I had to understand more of what I was building. At first, that meant I had more questions. But those questions were actually useful because they pushed me to understand the fundamentals instead of depending on the framework to make decisions for me.

Looking Back

Choosing Chi was one of the decisions that made building my Go backend easier.

It gave me the routing and middleware tools I needed without forcing me into a large framework structure.

More importantly, working with it helped me understand something I didn't fully appreciate when I started: good backend development isn't only about making endpoints work.

It's also about knowing where different responsibilities belong and keeping the code understandable as the project grows.

As I continue working with Go, I'm learning that the tools you choose can influence how you think about and structure your application.

For me, Chi was a good fit because it stayed out of the way and let me focus on building the backend.

And honestly, that's one of the things I appreciate most about Go in general.

# From CLI to Docker: What Three Go Projects Taught Me

Brender Adhiambo — Tue, 07 Jul 2026 13:22:26 +0000

When I started the ascii-art project, I thought I was just going to print text in different ASCII fonts.

A few weeks later, I had built a web server, learned the basics of HTTP, worked with HTML templates and CSS, handled user input, and packaged the entire application with Docker.

Looking back, ascii-art, ascii-art-web, and ascii-art-web-dockerize were more than coding exercises—they showed me how software evolves from a simple command-line tool into a deployable web application.

Building ascii-art

The first project introduced me to much more than string manipulation. I learned how to:

Parse files and process user input.
Organize code into reusable functions and packages.
Handle errors and edge cases.
Follow the flow of a Go application instead of putting everything inside main().

One lesson that stood out was understanding program flow:

main()
↓
ParseInput()
↓
LoadBanner()
↓
GenerateASCII()
↓
PrintOutput()

Once I understood how functions work together, reading larger Go projects became much easier.

Building ascii-art-web

Turning the terminal application into a web application introduced me to backend development.

Along the way I learned:

The difference between GET and POST requests.
How HTTP handlers process requests and return responses.
How to render HTML using Go templates.
Basic CSS to improve the user experience.
How to validate input and return meaningful error pages.

For the first time, I saw how a browser communicates with a Go server and how each request flows through the application.

Dockerizing the Application

The final project introduced me to Docker and deployment.

I learned how to:

Package an application into a container.
Write Dockerfiles.
Use multi-stage builds to create smaller production images.
Take advantage of Docker layer caching for faster rebuilds.

It also helped me understand why containers are so widely used: they make applications portable and consistent across environments.

Beyond the Code

These projects changed the way I approach software development.

I became more confident in:

Debugging problems instead of guessing.
Reading documentation.
Structuring Go projects.
Breaking large problems into smaller tasks.
Using Git throughout development.

Most importantly, I realized that software is built step by step. A command-line application can grow into a web application, and that same application can be prepared for deployment with Docker.

Final Thoughts

What started as a project to print ASCII characters became one of the most valuable learning experiences in my Go journey.

These three projects strengthened my understanding of Go, web development, and containerization while showing me how real-world applications evolve over time.

I'm looking forward to applying these lessons as I continue building larger, production-grade applications.

Learning Go: The Beauty of Simplicity

Brender Adhiambo — Wed, 17 Jun 2026 16:40:03 +0000

Diving into Go has been incredibly refreshing.

Coming into it, you might expect a powerful language to come bogged down with complex syntax. Instead, Go forces you to focus on solving problems with straightforward, elegant solutions rather than leaning on over-complicated language features. Its syntax is clean, highly readable, and naturally nudges you toward writing simpler code.
To get up to speed, I've been working through small, targeted exercises. Making mistakes along the way only accelerated the process, each error taught me more than getting it right the first time. Breaking things down into bite-sized challenges helped me truly grasp the foundational mechanics of the language:

- Functions & Loops — learning the Go way of control flow
- Strings & Arrays — manipulating data efficiently
- Error Handling — embracing Go's explicit, upfront approach to handling what goes wrong
- Writing Clean Code — realizing readability is a core feature of the language, not an afterthought.

Every small victory and green test suite built a little more confidence.