Forem: Favor Charles Owuor

Understanding Back-End Project Structures in Go: A Guide to Separate Concerns

Favor Charles Owuor — Wed, 11 Mar 2026 10:11:18 +0000

Code on laptop with hands typing in the dark Free Photo

When I first started writing Go to make a back-end API, I did what most people do — threw everything into one file. The handler, the business logic, the database calls, all of it crammed together. It worked, until it didn't. The moment I tried to refactor or write tests, three things broke. Sound familiar?

The fix isn't complicated, but it does require a bit of upfront thinking about how you organize your code. In this article I'll walk through a project structure that I learned recently. Companies like Uber and Netflix use similar patterns to manage large systems. It allows for scaling while remaining resilient to failures.

Why Bother Separating Concerns?

Most developers have all written messy code at some point. But once things are separated, the breathing room allows for testing, changes and reuse.

The idea behind separation of concerns is simple: each part of your code should have one job and one job only. When your handler is doing database queries and business logic, changes and tests can get tedious

The Four Layers

For this project we use four layers:

Model — the data structure
Repository — database access
Service — business logic
Handler — HTTP request handling

The payoff is that the same core logic runs with different routers (standard net/http, Gin, or Chi) and different databases (SQLite or MongoDB) without touching the middle layers at all.

1. Model

This is just the shape of your data. No HTTP, no database — just a structure, or skeleton.

type Todo struct {
    ID        string
    Title     string
    Completed bool
    CreatedAt time.Time
}

Everything else in the app revolves around this.

2. Repository

The repository is the only layer that talks to the database. Everything above it just calls repository methods.

You define an interface first:

type TodoRepository interface {
    Create(todo Todo) error
    GetByID(id string) (Todo, error)
    GetAll() ([]Todo, error)
    Update(todo Todo) error
    Delete(id string) error
}

Then you implement it for each database. Want to switch from SQLite to MongoDB? Write a new implementation, swap it in — nothing else changes.

3. Service

This is where your actual business logic lives. The service interact with whatever database being used, and it has nothing to do with HTTP. It just takes inputs, does something meaningful with them, and returns a result.

type TodoService struct {
    Repo TodoRepository
}

func (s *TodoService) Create(title string) (Todo, error) {
    todo := Todo{
        ID:        uuid.New().String(),
        Title:     title,
        Completed: false,
        CreatedAt: time.Now(),
    }
    err := s.Repo.Create(todo)
    return todo, err
}

Notice it only knows about the repository interface. That's the point.

4. Handler

Handlers sit at the edge of the application and deal with HTTP. They decode requests, call the service, and write responses.

func (h *TodoHandler) Create(w http.ResponseWriter, r *http.Request) {
    var req struct {
        Title string `json:"title"`
    }

    json.NewDecoder(r.Body).Decode(&req)

    todo, err := h.Service.Create(req.Title)
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(todo)
}

Because handlers only talk to the service (not the database), you can write different handlers for different routers — standard net/http, Gin, Chi — and they all call the exact same service methods underneath.

How It All Fits Together

Here's the flow when a request comes in:

HTTP Request → Handler → Service → Repository → Database

And back:

Database → Repository → Service → Handler → HTTP Response

Each layer only knows about the one directly below it. The handler doesn't know about the database. The service doesn't know about HTTP. The repository doesn't know about business logic. No bleed-through.

In practice, wiring it all together in main.go looks like this:

repo    := repository.NewSQLiteRepo(db)
service := service.NewTodoService(repo)
handler := handler.NewStdHandler(service)
router  := router.NewStdRouter(handler)

Want MongoDB instead? Change one line:

repo := repository.NewMongoRepo(collection)

Want Gin instead of net/http? Change one line:

handler := handler.NewGinHandler(service)
router  := router.NewGinRouter(handler)

The service layer doesn't move. The repository interface doesn't move. Only the edges change.

This is the resulting file structure:

├── cmd
│   └── main.go
├── internal
│   └── handlers
│   └── models
│   └── repository
│   └── services

Wrapping Up

This structure might feel like extra work upfront compared to dumping everything in one file and it is. This is true only for small projects. But the moment you need to write a test, switch a database, or hand the project to someone else, you'll be glad you did it.

I built the full working example of this with a Todo List API — complete with SQLite and MongoDB repositories, and handlers for net/http, Gin, and Chi. Take a look if you want to see all the pieces in place.

Start with this structure even on small projects. It's a habit that pays off fast.

A Compiled Review

Favor Charles Owuor — Tue, 17 Feb 2026 20:50:03 +0000

As a new developer using Go, I often wondered how different other compiled languages really are. I was advised to learn Go first because of its simplicity and speed. But what about the others? What are they and what can they offer.

There are many compiled languages, both popular and obscure. In this article, we focus on just four: C, C++, Rust, and Go. Let’s examine what each brings to the table.

Origins and Boom Years

C appeared in 1972, created by Dennis Ritchie at Bell Labs. It was developed to overcome limitations in B and BCPL and to build the Unix operating system. C provided low level memory access while maintaining structured programming concepts, which made it ideal for operating systems and critical performance software.

C++ was introduced in 1985 by Bjarne Stroustrup. It expanded C with object oriented programming features. The language gained strong popularity in the late 1990s and early 2000s during the rise of large scale software systems and game development.

Go was released by Google in 2009. It was influenced by C but designed to reduce complexity. It gained traction in the mid 2010s alongside cloud computing and microservices architecture due to its fast compilation and built in concurrency support.

Rust reached its stable release in 2015 from Mozilla, created by Graydon Hoare. It grew rapidly in the 2020s because of its strict memory safety model and strong performance guarantees. Many companies adopted it to reduce bugs related to memory errors.

Why Choose One and Leave the Other

As software systems became more complex, languages evolved to solve new problems. C provides control and performance. C++ adds abstraction to manage larger systems. Rust enforces memory safety, and Go simplifies concurrency and improves developer productivity.

Each language solves a different problem. C and C++ offer flexibility but require careful management. Rust prevents many classes of bugs at compile time. Go focuses on clarity and fast builds, making it practical for distributed systems and cloud services.

There is no one language that is better. There are trade offs. The best choice depends on what you as the developer want and/or need from whatever language you choose.

Concurrency Benchmark Across Languages

This test computes the sum of squares of the first 100,000,000 numbers split across 4 threads or goroutines. Execution time is measured in milliseconds.

Language	Sum	Time (ms)
C	672,921,401,752,298,880	113.4060
C++	672,921,401,752,298,880	80.5660
Rust	333,333,338,333,333,350,000	1171.7290
Go	672,921,401,752,298,880	48.8229

View Code

Why This Test Matters

These benchmarks show more than execution speed. They reveal how each language approaches concurrency and numerical safety under the same workload. While C, C++, and Go completed the computation without warnings. You see the computed numbers were too big for int64 so Rust refused silent overflow and required a larger integer type i.e. int128 while the other languages used the values as is.

Conclusion

Compiled languages are not interchangeable tools. Each reflects different priorities in software engineering. C and C++ reward experience and precision. Rust enforces correctness and offers strong safety guarantees. Go values simplicity and productivity.

Understanding these differences allows developers to choose intentionally instead of following trends. The right language is not about which is fastest. It is about which aligns best with the problem you are solving.

Building an AI Agent for Business Viability In a 24 Hour Hackathon

Favor Charles Owuor — Thu, 05 Feb 2026 11:16:59 +0000

I recently participated in a hackathon focused on building AI agents. The main rule was clear. AI could not be the product by itself. It had to support a real system.

Our team had five members. We worked for just over 24 hours. The pressure was real. So was the ambition.

The Problem We Chose

Many people have business ideas. Very few know if those ideas make financial sense before investing money.

We saw a gap. People needed a way to test ideas early, using numbers and logic, not hope and vibes.

Our goal was to build a tool that helps someone answer a simple question. Is this business idea viable or not?

The Core Idea

We built a business viability checker called Microbiz.

The user enters structured inputs. These include starting capital, pricing, expected monthly sales, operating costs, and time horizon.

At the core of the system is a calculation engine. It computes revenue, total costs, profit margins, and sustainability indicators over time.

This part was fully deterministic. Just math and logic to get consistent results every time.

We wanted users to trust the numbers first.

System Design and Team Roles

We used Django for the back-end. I worked mainly on this part.

My role involved handling inputs, validating data, running financial calculations, and structuring outputs. I also prepared the data so it could be consumed cleanly by the AI component.

Two teammates worked on the front-end. Their focus was speed and clarity. They designed an interface that made complex inputs easier to manage under time pressure.

Another teammate focused on prompt engineering. Their job was to control how the AI reasoned, what context it received, and how it communicated results.

Where the AI Fit In

We integrated Groq AI using an API key.

The AI did not redo the calculations. It received the raw user inputs plus all internal computed values.

From there, it performed higher level reasoning. It considered market conditions, pricing realism, demand signals, and feasibility based on what is currently visible online.

The AI produced one output; it gave a recommendation on whether the business idea was likely viable or risky under the given assumptions. It stated reasons based on the input given

The AI was meant to support decisions, not motivate or sell dreams.

The Reality Check

We underestimated the workload.

Writing formulas was not the hardest part. Defining realistic assumptions was.

We had to research small business behavior, cost structures, margins, and failure points. That research slowed development since none of us have any financial or business backgrounds, but skipping it would have made the system useless.

Time worked against us. Features piled up faster than we could finish them. We created and broke code again and again until we got to a middle ground that wasn't perfect but works well enough.

Despite working through the night, we did not complete everything we planned.

Pitch Day

Before demos, all teams were called to a common area and given three minutes for an elevator pitch with slides and demos. When our turn came, we presented with nothing but words.
It still worked in our favor since we understood the product deeply. We explained the problem clearly and answered the judges' questions without much thinking. We explained why pure AI was not enough and how logic and AI reasoning worked together.

We did not make the podium. However, the judges told us the product was useful and encouraged us to keep building it. That feedback mattered more than placement.

Lessons Learned

First, scope matters. AI agents amplify systems. They do not replace solid foundations.

If your assumptions are wrong, AI makes the output confidently wrong. It's just how systems work; GIGO (Garbage In Garbage Out)

Second, research is not optional. Especially when dealing with money and real people.

Third, clear ownership helps under pressure. Back-end, front-end, and AI roles stayed mostly separate. That prevented chaos.

What Comes Next

This project is not finished and it most definitely won't be shelved.

Our next step is reducing the amount of input required. The system should do more inference with less user effort so that even those who are green in business but would still like to start one can do it but with more knowledge.

Long term, the goal is idea discovery. The system should recommend business ideas directly, starting with specific regions in Kenya. And as the scope expands maybe even worldwide. Maybe one day you may even interact with it.

The hackathon may have ended, but the product will live on.