DEV Community: Steve Omollo

I Chose Buffalo for a 48-Hour Hackathon. Then I Had to Figure Out How to Use It

Steve Omollo — Wed, 02 Sep 2026 09:14:45 +0000

I had worked with Go before.

I had also worked with Bitcoin.

What I had not worked with was a Go web framework.

Then came a 48-hour GreenTech hackathon at Zone01 Kisumu.

Naturally, I decided to change that.

Not because I had carefully compared every Go framework and found the perfect one. Not because I had years of experience building production applications with Go. I simply researched some of the popular Go backend frameworks for beginners, came across Buffalo, and thought:

"Well, Buffalo it is."

That decision would come back to haunt me a little.

But first, we had a problem to solve.

From BSF farming to organic waste

The hackathon was organized around broad problem tracks. Teams would choose a track and then narrow it down to a specific problem.

Our group settled on the waste management track.

The initial idea came from BSF — Black Soldier Fly farming. BSF farming uses organic waste as part of the process, and somewhere in our discussions, the idea clicked:

What if organic waste could be treated as a resource rather than simply waste?

But then we asked ourselves whether we should build the entire idea specifically around BSF farming.

We eventually decided against narrowing it that much.

Instead, we would build something broader around organic waste recycling, while still using the BSF farming cycle in our pitch because it was a relevant and familiar use case.

That became the foundation for RegenFeed.

The idea was fairly simple.

There are businesses and other large producers generating organic waste. There are farmers and other people who can make use of that waste.

Why not create a platform that connects the two?

Dividing the work

Once we had the direction, we divided the work and started researching our individual responsibilities.

I was part of the backend team, which had three people.

My responsibility was the backend core — broadly covering the database, authentication, and core migrations.

That was also when I started researching which framework I should use.

I already knew Go, but I had never used a framework for building a Go web application.

So I searched.

And Buffalo appeared.

I knew there were other options. I just hadn't used any of them before. At that point, Buffalo looked like a reasonable starting point for someone new to the concept of Go frameworks.

So I committed to it.

Looking back, it was definitely a premature judgment.

But it made sense at the time.

"You've chosen Buffalo? Then you guide us."

There was one small problem.

I was learning Buffalo.

My teammates didn't necessarily know that.

I remember pushing my first commit. Somewhere in the project they saw buffalo, and that was enough for them to realize what framework I had chosen.

Then came something along the lines of:

"You've settled on Buffalo? Buffalo it is. You guide us through it."

That sent shivers down my spine.

Guide you?

I had just started learning it myself.

But that was the situation.

So I started figuring it out.

And honestly, my first impression of Buffalo was magical.

You run a command — sometimes one that doesn't seem directly related to what you're trying to accomplish — and suddenly something has happened.

A model appears.

A migration is generated.

Some project structure is created.

Something is wired up.

And you're sitting there thinking:

"Wait. What just happened?"

That's one of the strange things about frameworks.

They can make development incredibly fast, but they can also hide a lot of what is actually happening underneath.

At times I felt like some of the commands were so shortened or abstracted that I could get something working without necessarily knowing the underlying SQL, module creation, or all the individual steps that would have been required without the framework.

That was both exciting and slightly terrifying.

The framework makes things easier — until it doesn't

This hackathon taught me something I hadn't really understood about frameworks.

Frameworks do make work easier.

But only if you know what to do with them.

If you don't understand the framework, you can end up in a much worse situation than if you had simply used the standard library.

And I experienced that firsthand.

As the backend started taking shape, the frontend team was already moving.

They kept reminding us that the backend was supposed to come first so that they could build against the endpoints.

They waited.

And waited.

Eventually, they decided to start anyway.

The agreement became: we'll sort out the endpoint issues later.

That "later" eventually arrived.

And it arrived with very little sleep.

When Buffalo met Svelte

The integration between the backend and the Svelte frontend was probably one of the hardest parts of the hackathon for me.

I pushed my work to the remote repository, expecting that we'd bring everything together and continue.

Instead, we got conflicts.

Things weren't communicating properly.

Work that had made sense in isolation suddenly had to work with everyone else's work.

And by then, I was exhausted.

It was almost morning.

At that point, I honestly can't give you a perfectly technical explanation of everything that went wrong. My brain was already running on fumes.

What I remember is debugging.

And needing help.

And eventually putting lunch on the line.

One of my teammates and I had developed a little system during the hackathon: whenever I got stuck and needed her help, we'd put sweets — and sometimes lunch — at stake.

I'd owe her one.

This was one of those moments.

And somehow, we got through it.

That's another thing I learned during the hackathon:

Group work is magical.

I would advocate for it any day.

Someone gets tired. Someone gets stuck. Someone's brain simply stops cooperating.

And somehow, the work continues because somebody else is still going.

What RegenFeed actually did

The MVP revolved around two main types of users:

Waste producers and farmers.

A waste producer could list organic waste on the platform.

The listing could contain information such as:

the type of waste or its composition, such as carbohydrates, protein, or vitamins
the weight available
the price
a picture
the producer's locality

A farmer could then log into the platform, browse or search through available waste, find something useful, and place an order.

We also incorporated Bitcoin Lightning into the concept.

The producer could price the waste in satoshis, and when a farmer initiated an order, the platform could initiate a Lightning invoice for payment.

The physical exchange between the farmer and producer, however, happened outside the platform.

That distinction mattered.

We weren't trying to become a logistics company in 48 hours.

We were trying to create the digital marketplace connecting the two sides.

The part we didn't solve

And this is where being honest about hackathons matters.

We had an MVP.

But it wasn't a finished product.

The payment implementation was about as basic as we could make it within the time available. Questions around security, platform sustainability, and exactly how the business would make money weren't fully demonstrated.

There were also features that weren't completely implemented on the backend.

Every time we solved one issue, another unfinished piece seemed to appear.

So when I say we built RegenFeed, I don't mean we built a production-ready marketplace.

We built a proof of concept under a 48-hour constraint.

There was still a lot pending.

And that's okay.

Three minutes

Eventually, we had to present.

We had an MVP, and we had a story to tell.

Then we discovered another challenge:

Three minutes is not a lot of time.

Our idea had to be compressed into those three minutes, while still explaining the problem, the solution, the marketplace, the organic waste cycle, and the role of Bitcoin Lightning.

The competition was stiff.

The first three teams received prizes and recognition.

We weren't among them.

But the judges did give us something valuable: they acknowledged that the underlying idea was sound.

For me, that was enough to make the experience worthwhile.

What I would do differently

If I were starting that hackathon again, I'd change one major thing.

I would get comfortable with the backend framework and the core endpoint setup as quickly as possible.

The frontend team needed endpoints to move, and I took too long getting there.

A lot of the integration pressure later came from that delay.

I'd also establish the API contract much earlier.

Instead of waiting until everyone had built their pieces and then trying to make them communicate, I'd want the frontend and backend teams to agree early on:

what endpoints exist
what requests look like
what responses look like
what authentication looks like
what data structures we're sharing

That would have saved us a lot of pain later.

What Buffalo taught me

I still haven't mastered Buffalo.

And I don't think I need to pretend that I did.

What the hackathon gave me was something more useful: I became less afraid of unfamiliar frameworks.

Before this experience, I might have looked at a new framework and thought:

"I don't know this. I'll stick with what I know."

Now my reaction is closer to:

"I don't know this yet. Let's figure it out."

That's progress.

I'm still more comfortable with Go's standard library at the moment. And I suspect that will continue to change as I explore more frameworks and build more applications.

But now I know something I didn't know before:

A framework isn't magic.

It is a collection of decisions and abstractions designed to make certain things easier.

The trick is understanding enough of those abstractions that they work for you rather than becoming another problem you have to fight.

And sometimes, the fastest way to learn that is to choose a framework on a questionable assumption, tell your teammates you'll guide them through it, and then spend the next 48 hours figuring out how to actually do it.

That's pretty much what happened to me.

I chose Buffalo.

Then Buffalo chose me.

Structuring Go Projects For Growth with Packages

Steve Omollo — Thu, 30 Jul 2026 20:11:33 +0000

Previously, we built a complete CRUD API for managing tasks.

Although everything works, our entire application currently lives inside a single main.go file. This approach is fine for small examples, but as projects grow, a single file quickly becomes difficult to navigate and maintain.

In this article, we'll reorganize our API into multiple packages, giving each part of the application a clear responsibility while still using Go's standard library.

By the end, you'll understand:

why Go projects are split into packages
how to organize code into folders
how to create your own packages
how to import your own code
how separation of concerns makes applications easier to maintain.

Step 1 — Our Current Project

Our project currently looks like this:

go-crud-api/
├─ go.mod
└─ main.go

At this stage, every part of our application lives inside a single file. Our data model, HTTP handler, routing, and server startup code are still mixed together.

For a project with only a few features, this isn't a problem. In fact, keeping in one file can make learning easier because all the code is in one place.

However, applications rarely stay this small.

Imagine adding:

user authentication
logging
middleware
request validation
database connections
configuration files

Very quickly, main.go would become hundreds of lines long, making the application harder to read and maintain.

Instead of putting everything into one file, Go encourages us to group related code together using packages.

Step 2 — Create the Project Structure

We'll reorganize the project into separate folders.

Our project will now look like this:

go-crud-api/
├─ go.mod
├─ main.go
├─ handlers/
│  └─ tasks.go
└─ models/
   └─ task.go

Rather than one file doing everything, each folder now has a specific purpose.

main.go starts the server.
handlers contains functions that process incoming HTTP requests.
models defines the application's data structures.

This idea is known as separation of concerns.

Instead of one file handling every responsibility, each package focuses on one job.

As your application grows, this organization makes it much easier to locate code, fix bugs, and add new features.

Step 3 — Move the Task Struct

Create a folder named models, then create a file called task.go.

Add the following code:

package models

type Task struct {
    ID    int    `json:"id"`
    Title string `json:"title"`
}

Let's break this down.

The first line is:

package models

Every Go source file belongs to a package.

A package is simply a way of grouping related code together.

Think of a package as a folder that contains code with a common purpose.

In our project, the models package will contain the structures that represent our application's data.

In this case, that data is our Task struct.

Moving the struct into its own package makes it reusable throughout the application without duplicating code.

Later, if we add User or Project struct, they can also live inside the models package.

Step 4 — Create the Handler

Now we'll move the CRUD logic from main.go into the handlers package.

Most of the code is identical to what we wrote in the previous article. The main difference is that now it lives in its own package and uses the Task struct from the models package.

Create a folder named handlers, then add a file called tasks.go.

Add the following code:

package handlers

import (
    "encoding/json"
    "net/http"

    "go-crud-api/models"
)

var tasks []models.Task

func TaskHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")

    switch r.Method {

    case http.MethodGet:
        json.NewEncoder(w).Encode(tasks)

    case http.MethodPost:
        var task models.Task

        err := json.NewDecoder(r.Body).Decode(&task)
        if err != nil {
            http.Error(w, "Invalid JSON", http.StatusBadRequest)
            return
        }

        tasks = append(tasks, task)
        json.NewEncoder(w).Encode(task)

    case http.MethodPut:
        var updatedTask models.Task

        err := json.NewDecoder(r.Body).Decode(&updatedTask)
        if err != nil {
            http.Error(w, "Invalid JSON", http.StatusBadRequest)
            return
        }

        for i, task := range tasks {
            if task.ID == updatedTask.ID {
                tasks[i].Title = updatedTask.Title
                json.NewEncoder(w).Encode(tasks[i])
                return
            }
        }

        http.Error(w, "Task not found", http.StatusNotFound)

    case http.MethodDelete:
        var taskToDelete models.Task

        err := json.NewDecoder(r.Body).Decode(&taskToDelete)
        if err != nil {
            http.Error(w, "Invalid JSON", http.StatusBadRequest)
            return
        }

        for i, task := range tasks {
            if task.ID == taskToDelete.ID {
                tasks = append(tasks[:i], tasks[i+1:]...)
                w.Write([]byte("Task deleted"))
                return
            }
        }

        http.Error(w, "Task not found", http.StatusNotFound)

    default:
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
    }
}

This file now contains the same CRUD logic from the previous article, but it has been moved into its own package and updated to use the models.Task type.

You might be wondering why the tasks slice wasn't moved into the models package along with the Task struct.

The models package is responsible for defining the shape of our data, while the handlers package is responsible for processing HTTP requests. Since we're still storing tasks in memory for simplicity, keeping the slice in the handler avoids introducing another package before it's needed.

In a larger application, this data would typically be managed by a database or a dedicated storage layer.

What's different?

You may notice a few differences compared to the previous article.

First, the package declaration is now:

package handlers

instead of:

package main

because this file belongs to the handlers package.

Second, we import our own package:

"go-crud-api/models"

This allows us to use the Task struct that now lives inside the models package.

Finally, the handler is named TaskHandler instead of taskHandler.

Because it begins with a capital letter, it is exported and can be accessed from main.go.

If we left the function names as taskHandler, Go would report an error because functions that begin with a lowercase letter are only visible within the same package.

Understanding Import Paths

You might be wondering where this import path comes from:

"go-crud-api/models"

The first part, go-crud-api, is the module name we created earlier when we ran:

go mod init go-crud-api

Go uses the module name as the base for importing packages within the same project.

If your module had a different name, such as:

go mod init task-manager

the import would become:

"task-manager/models"

This allows the handlers package to access exported identifiers from the models package.

This is why it's important that the import path matches the module name in your go.mod file.

Step 5 — Update main.go

Now that the application has been split into packages, main.go becomes much smaller.

package main

import (
    "net/http"

    "go-crud-api/handlers"
)

func main() {
    http.HandleFunc("/tasks", handlers.TaskHandler)

    http.ListenAndServe(":8080", nil)
}

Since TaskHandler now lives in another package, we must import thehandlerspackage before we can use it. Once imported, we access the exported functions using the package name followed by a dot, such ashandlers.TaskHandler`.

Notice how little code remains.

Instead of containing all the CRUD logic, main.go now has a single responsibility: starting the application.

This makes the file much easier to read.

Whenever we need to modify how tasks are handled, we know exactly where to look: the handlers package.

Keeping each package focused on one responsibility makes applications easier to understand as they grow.

Understanding Exported Names

You may have noticed that our handler function is now called:

go TaskHandler

instead of:

go taskHandler

This change is important.

In Go, any name that begins with a capital letter is exported.

Exported identifiers can be accessed from other packages.

Names beginning with a lowercase letter remain private to the package where they are declared.

For example:

go func TaskHandler(...) {}

can be used from main.go, while:

go func taskHandler(...) {}

cannot.

This convention is one of the simplest yet most distinctive features of Go, and you'll use it throughout the standard library.

What Changed?

Although our API behaves exactly as before, its internal structure is much cleaner.

Here's what changed:

Before	After
Everything lived in `main.go`	Code is split into packages
One file handled everything	Each package has one responsibility
Difficult to grow	Easier to maintain
Harder to navigate	Easier to understand

We haven't added any new features yet—but we've made our project much easier to extend.

As applications grow, good organization becomes just as important as writing correct code.

Step 6 — Run the Application

bash go run .

Notice that we use go run . instead of go run main.go.

Now test the API just as you did in the previous article.

Create a task.
Retrieve the list of tasks.
Update a task.
Delete a task.

You'll notice that the API behaves exactly as before. The only difference is that the code is now organized into packages, making it easier to maintain as the project grows.

Although we reorganized the code into packages, the application's behavior hasn't changed. We've simply made the project easier to understand and maintain.

Once a project spans multiple files and packages, go run . becomes the more natural command because it builds the entire module.

Thanks for reading!

Happy coding!

Building a CRUD API in Go

Steve Omollo — Thu, 16 Jul 2026 08:32:48 +0000

Previously, we built a simple task API that could create and retrieve tasks.

If you have been following this series, we've gradually progressed from building a simple HTTP server to creating a JSON-based task API. In this article, we will complete that progression by adding update and delete functionality, giving our API the four operations commonly known as CRUD.

CRUD stands for:

Create
Read
Update
Delete

These operations form the foundation of many backend applications and APIs.

In this tutorial, we will extend our task API using only Go's standard library. To keep things simple, we'll continue storing tasks in memory using a slice rather than a database.

By the end, you'll understand:

how CRUD APIs work
how to handle multiple HTTP methods
how to update existing data
how to remove data from slices
how backend APIs manage resources

Prerequisites

To follow along, you should have:

Go installed
basic familiarity with Go syntax
understanding of the net/http package
basic understanding of JSON handling

You can confirm if Go is installed by running:

go version

Step 1 — Create the Project

Create a new folder for the project:

mkdir go-crud-api
cd go-crud-api

Now initialize a Go module:

go mod init go-crud-api

Step 2 — Create the Server File

Create a file called main.go.

Your project structure should now look like this.

go-crud-api/
├─ go.mod
└─ main.go

Step 3 — Write the CRUD API

Open main.go and add the following code:

package main

import (
    "encoding/json"
    "net/http"
)

type Task struct {
    ID        int        `json:"id"`
    Title     string     `json:"title"`
}

var tasks []Task

func tasksHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")

    switch r.Method {

    case http.MethodGet:
        json.NewEncoder(w).Encode(tasks)

    case http.MethodPost:
        var task Task

        err := json.NewDecoder(r.Body).Decode(&task)
        if err != nil {
            http.Error(w, "Invalid JSON", http.StatusBadRequest)
            return
        }

        tasks = append(tasks, task)
        json.NewEncoder(w).Encode(task)

    case http.MethodPut:
        var updatedTask Task

        err := json.NewDecoder(r.Body).Decode(&updatedTask)
        if err != nil {
            http.Error(w, "Invalid JSON", http.StatusBadRequest)
            return
        }

        for i, task := range tasks {
            if task.ID == updatedTask.ID {
                tasks[i].Title = updatedTask.Title
                json.NewEncoder(w).Encode(tasks[i])
                return
            }
        }

        http.Error(w, "Task not found", http.StatusNotFound)

    case http.MethodDelete:
        var taskToDelete Task

        err := json.NewDecoder(r.Body).Decode(&taskToDelete)
        if err != nil {
            http.Error(w, "Invalid JSON", http.StatusBadRequest)
            return
        }

        for i, task := range tasks {
            if task.ID == taskToDelete.ID {
                tasks = append(tasks[:i], tasks[i+1:]...)
                w.Write([]byte("Task deleted"))
                return
            }
        }

        http.Error(w, "Task not found", http.StatusNotFound)

    default:
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
    }
}

func main() {
    http.HandleFunc("/tasks", tasksHandler)

    http.ListenAndServe(":8080", nil)
}

Now let's unpack what is happening.

Understanding CRUD Operations

CRUD represents the four most common actions performed on data.

Operation	HTTP Method
Create	POST
Read	GET
Update	PUT
Delete	DELETE

Most backend APIs are built around these operations.

Create and Read

The POST and GET handlers work exactly as they did in the previous tutorial.

POST creates tasks
GET retrieves tasks

These operations allow us to add and view data.

Understanding Updates

This section handles updates:

case http.MethodPut:

The server expects updated task information in the request body.

For example:

{
    "id": 1,
    "title": "Learn Advanced Go"
}

After decoding the request, we search for a matching task:

for i, task := range tasks {
    if task.ID == updatedTask.ID {

If a match is found, we update the title:

tasks[i].Title = updatedTask.Title

Then we return the updated task as JSON.

Understanding Deletes

This section handles deleting tasks:

case http.MethodDelete:

The client sends the ID of the task to remove:

{
    "id": 1
}

We search for the task with matching ID and remove it from the slice.

The deletion happens here:

tasks = append(tasks[:i], tasks[i+1:]...)

This combines:

everything before the task
everything after the task

into a new slice that no longer contains the deleted item.

Understanding Slice Deletion

This line often looks strange at first:

tasks = append(tasks[:i], tasks[i+1:]...)

Let's break it down.

Suppose we have:

tasks = [1 2 3 4]

and want to remove:

Then:

tasks[:i]

gives:

[1]

and:

tasks[i+1:]

gives:

[3 4]

Appending them together creates:

[1 3 4]

The item has effectively been removed.

Go Tip: The append(tasks[:i], tasks[i+1:]...) pattern is one of the most common ways to remove an element from a slice in Go. You'll see it in many Go projects, so it's worth understanding how it works.

Step 4 — Run the Server

Start the application:

go run main.go

The server should now be running on port 8080.

Step 5 — Create a Task

curl -X POST http://localhost:8080/tasks \
-H "Content-Type: application/json" \
-d '{"id":1,"title":"Learn Go"}'

Response:

{
    "id": 1,
    "title": "Learn Go"
}

Step 6 — Retrieve Tasks

curl http://localhost:8080/tasks

Response:

[
    {
        "id": 1,
        "title": "Learn Go"
    }
]

Step 7 — Update a Task

curl -X PUT http://localhost:8080/tasks \
-H "Content-Type: application/json" \
-d '{"id":1,"title":"Learn Advanced Go"}'

Response:

{
    "id": 1,
    "title": "Learn Advanced Go"
}

Step 8 — Delete a Task

curl -X DELETE http://localhost:8080/tasks \
-H "Content-Type: application/json" \
-d '{"id":1}'

Response:

Task deleted

What Happens When a Request Is Made?

Here's the flow:

The client sends an HTTP request.
Go checks the request method.
The appropriate handler creates, retrieves, updates, or deletes a task.
The server prepares the response.
A response is sent back to the client

This is the foundation of many real-world APIs.

Where to Go Next

Now that we have a simple CRUD API, we could extend it by adding:

route parameters
persistent databases
request validation
middleware
authentication

This is where backend applications begin moving closer to production-ready systems.

Final Thoughts

We started with a simple task API and extended it into a complete CRUD API.

Along the way, we learned about:

HTTP methods
updating data
deleting data
slice manipulation
API design

These concepts appear in countless backend applications and services.

Thanks for reading!

Happy coding!

Building a Simple Task API in Go

Steve Omollo — Mon, 01 Jun 2026 06:44:38 +0000

Previously, we learned how to send and receive JSON data in Go.

One of the next steps in building backend applications is creating APIs with multiple endpoints that can handle different types of requests.

In this tutorial, we will build a simple task API in Go using only the standard library.

By the end, you will understand:

how API endpoints work
how to handle multiple HTTP methods
how to store data in memory using slices
how to send and receive JSON data
how backend APIs manage resources

Prerequisites

To follow along, you should have:

Go installed
basic familiarity with Go syntax
understanding of the net/http package
basic understanding of JSON handling

You can confirm if Go is installed by running:

go version

Step 1 — Create the Project

Create a new folder for the project:

mkdir go-task-api
cd go-task-api

Now initialize a Go module:

go mod init go-task-api

This creates a go.mod file for managing project dependencies.

Step 2 — Create the Server File

Create a file called main.go.

Your project structure should now look like this:

go-task-api/
├─ go.mod
└─ main.go

Step 3 — Write the API

Open main.go and add the following code:

package main

import (
    "encoding/json"
    "net/http"
)

type Task struct {
    ID    int    `json:"id"`
    Title string `json:"title"`
}

var tasks []Task

func tasksHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")

    switch r.Method {

    case http.MethodGet:
        json.NewEncoder(w).Encode(tasks)

    case http.MethodPost:
        var task Task

        err := json.NewDecoder(r.Body).Decode(&task)
        if err != nil {
            http.Error(w, "Invalid JSON", http.StatusBadRequest)
            return
        }

        tasks = append(tasks, task)

        json.NewEncoder(w).Encode(task)

    default:
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
    }
}

func main() {
    http.HandleFunc("/tasks", tasksHandler)

    http.ListenAndServe(":8080", nil)
}

Now let's unpack what is happening.

Understanding the Struct

This struct represents a task:

type Task struct {
    ID    int    `json:"id"`
    Title string `json:"title"`
}

Each task contains:

an ID
a Title

This struct defines the JSON format our API will use.

For example:

{
    "id": 1,
    "title": "Learn Go"
}

Understanding In-Memory Storage

This line:

var tasks []Task

creates a slice that stores tasks in memory.

For now, our data only exists while the server is running.

Once the server stops, the data disappears.

This keeps the tutorial simple before introducing databases later.

Understanding HTTP Methods

This part checks the request method:

switch r.Method

HTTP methods tell the server what action the client wants to perform.

Here, we handle:

Method	Purpose
`GET`	Retrieves tasks
`POST`	Creates tasks

Later, we could also add:

PUT for updating tasks
DELETE for removing tasks

Because, you know, every backend journey eventually leads there.

Handling GET Requests

This section handles fetching tasks:

case http.MethodGet:
    json.NewEncoder(w).Encode(tasks)

When the client sends a GET request:

the server retrieves all tasks
the tasks are converted into JSON
the JSON response is sent back to the client

Handling POST Requests

This section handles creating tasks:

case http.MethodPost:

Inside this block:

var task Task

we create a task variable to store the incoming JSON data.

Then we decode the request body:

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

If decoding succeeds, we add the task to the slice:

tasks = append(tasks, task)

Finally, we return the created task as JSON.

Understanding `append`

This line:

tasks = append(tasks, task)

adds a new task to the slice.

Slices in Go are dynamic, that is, they can grow as we add more data.

This allows our API to store multiple tasks.

Understanding Error Handling

This section checks whether the JSON request is valid:

if err != nil {
    http.Error(w, "Invalid JSON", http.StatusBadRequest)
    return
}

If decoding fails:

the server sends an error response
the request stops processing

This helps keep the API stable when invalid data is sent.

Step 4 — Run the Server

Start the application:

go run main.go

The server should now be running on port 8080.

Step 5 — Create a Task

We can create a task using curl.

Run:

curl -X POST http://localhost:8080/tasks \
-H "Content-Type: application/json" \
-d '{"id":1,"title":"Learn Go"}'

You should receive:

{
    "id": 1,
    "title": "Learn Go"
}

Step 6 — Retrieve Tasks

Now retrieve all tasks using:

curl http://localhost:8080/tasks

You should receive:

[
    {
        "id": 1,
        "title": "Learn Go"
    }
]

What Happens When a Request Is Made?

Here's the flow:

The client sends an HTTP request
Go checks the request method
The correct code block runs
Tasks are created or retrieved
JSON responses are returned to the client

This is the foundation of many backend APIs.

Where to Go Next

Now that we have a simple task API, we could extend it by adding:

PUT requests
DELETE requests
route parameters
databases
request validation
authentication

This is where backend applications start becoming much more powerful and realistic.

Final Thoughts

We started with simple HTTP servers and gradually built a working task API.

Along the way, we learned about:

HTTP methods
JSON encoding
JSON decoding
slices
request handling
API design

These are the foundational backend development concepts that appear in many real-world applications.

Thanks for reading!

Happy coding!

Handling JSON Requests in Go

Steve Omollo — Sat, 23 May 2026 11:59:27 +0000

Previously, we learned how to return JSON responses from a Go server.

But APIs do not only send data — they also receive it.

Frontend applications, mobile apps, and clients commonly send JSON data to servers through HTTP requests.

In this tutorial, we will learn how to handle JSON requests in Go by decoding request bodies into structs using Go's standard library.

By the end, you will understand:

how JSON request bodies work
how to decode JSON in Go
how POST requests work
how to process incoming client data

Prerequisites

To follow along, you should have:

Go installed
basic familiarity with Go syntax
understanding of the net/http package
basic understanding of JSON responses

You can confirm if Go is installed by running:

go version

Step 1 — Create the Project

Create a new folder for the project:

mkdir go-json-requests
cd go-json-requests

Now initialize a Go module:

go mod init go-json-requests

This creates a go.mod file for managing project dependencies.

Step 2 — Create the Server File

Create a file called main.go.

Your project structure should now look like this:

go-json-requests/
├─ go.mod
└─ main.go

Step 3 — Write the Server

Open main.go and add the following code:

package main

import (
    "encoding/json"
    "fmt"
    "net/http"
)

type User struct {
    Name string `json:"name"`
}

func userHandler(w http.ResponseWriter, r *http.Request) {
    var user User

    err := json.NewDecoder(r.Body).Decode(&user)
    if err != nil {
        http.Error(w, "Invalid JSON", http.StatusBadRequest)
        return
    }

    fmt.Fprintf(w, "Hello, %s!\n", user.Name)
}

func main() {
    http.HandleFunc("/user", userHandler)

    fmt.Println("Server running on :8080")

    http.ListenAndServe(":8080", nil)
}

Now let's unpack what is happening.

Understanding POST Requests

In the previous examples, we mainly worked with routes that returned data.

This time, the client sends data to the server.

This commonly happens using a POST request.

POST requests are used when:

submitting forms
sending JSON data
creating resources
uploading information to a server

Understanding the Struct

This struct defines the shape of the JSON data we expect:

type User struct {
    Name string `json:"name"`
}

If the client sends:

{
  "name": "Steve"
}

Go can decode that JSON into the struct.

The json:"name" tag tells Go which JSON field maps to the struct field.

Understanding Request Bodies

When a client sends data to a server, the data is stored inside the request body.

In Go, we access it using:

r.Body

The Body contains the incoming JSON data from the client.

Decoding JSON Requests

This line is the heart of the server:

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

Here's what happens:

NewDecoder(r.Body) reads the incoming request body
Decode(&user) converts the JSON into the struct
&user passes a pointer so Go can modify the struct value

After decoding, the user variable contains the client data.

So Why Do We Use `&user`?

You may notice this part:

&user

The & symbol means:

"Use the memory address of this variable."

The decoder needs direct access to the struct so it can fill in the fields with incoming JSON data.

Without the pointer, decoding would not work correctly.

Understanding Error Handling

This section checks whether the JSON request is valid:

if err != nil {
    http.Error(w, "Invalid JSON", http.StatusBadRequest)
    return
}

If decoding fails:

the server sends an error response
the request stops processing

This helps prevent invalid client data from crashing the application.

Step 4 — Run the Server

Start the application:

go run main.go

You should see:

Server running on :8080

Step 5 — Test the API

This server expects a POST request containing JSON data.

We can test it using curl.

curl -X POST http://localhost:8080/user \
-H "Content-Type: application/json" \
-d '{"name":"Steve"}'

You should receive:

Hello, Steve!

What Happens When a Request Is Made?

Here's the flow:

The client sends a POST request
JSON data is placed inside the request body
Go reads the request body
The JSON is decoded into a struct
The server processes the data
A response is sent back to the client

This is the foundation of many real-world APIs.

Where to Go Next

Now that we can decode JSON requests, we could extend this server by adding:

multiple API endpoints
JSON responses
CRUD operations — again, because every backend journey eventually leads there
databases
request validation
authentication

This is where backend development starts becoming much more interactive and dynamic.

Final Thoughts

We started with a simple server that only returned data.

Now our server can also receive and process JSON requests from clients.

Along the way, we learned about:

POST requests
request bodies
JSON decoding
structs
pointers
error handling

These concepts are essential when building APIs in Go.

Thanks for reading!

Happy coding!

Returning JSON Responses in Go

Steve Omollo — Fri, 15 May 2026 20:10:30 +0000

In the previous tutorial, we built a simple HTTP server in Go that returned plain text responses.

While that works, most modern applications communicate using JSON.

Frontend applications, mobile apps, and APIs commonly exchange data in JSON format.

In this tutorial, we will learn how to return JSON responses from a Go server using Go's standard library.

By the end, you will understand:

how JSON responses work in Go
how to create structs
how to encode data into JSON
how to send JSON from an HTTP server

Prerequisites

To follow along, you should have:

Go installed
basic familiarity with Go syntax
understanding of the net/http package

You can confirm if Go is installed by running:

go version

Step 1 — Create the Project

Create a new folder for the project:

mkdir go-json-server
cd go-json-server

Now initialize a Go module:

go mod init go-json-server

This creates a go.mod file for managing project dependencies.

Step 2 — Create the Server File

Create a file called main.go.

Your project structure should now look like this:

go-json-server/
├── go.mod
└── main.go

Step 3 — Write the JSON Server

Open main.go and write this:

package main

import (
    "encoding/json"
    "net/http"
)

type Message struct {
    Text string `json:"text"`
}

func homeHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")

    response := Message{
        Text: "Hello from Go!",
    }

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

func main() {
    http.HandleFunc("/", homeHandler)

    http.ListenAndServe(":8080", nil)
}

Now let's unpack what is happening.

Understanding the Imports

import (
    "encoding/json"
    "net/http"
)

We imported two packages:

net/http — used for creating the HTTP server
encoding/json — used for converting Go data into JSON

The encoding/json package is part of Go's standard library, so we do not need to install anything extra.

Understanding Structs

This part:

type Message struct {
    Text string `json:"text"`
}

defines a struct.

Structs are used to group related data together.

In this example:

Message is the struct name
Text is a field inside the struct

We later use this struct to create JSON responses.

Why is `Text` Capitalized?

You may notice that Text starts with an uppercase letter.

In Go, fields must begin with uppercase letters to be exported.

The JSON encoder can only access exported fields.

For example, this would not work correctly:

type Message struct {
    text string
}

because text is unexported.

This is a very important concept when working with JSON in Go.

Understanding JSON Tags

This part:

`json:"text"`

is called a JSON tag.

JSON tags control how fields appear in the JSON response.

Our Go field is named:

Text

but the JSON output becomes:

{
  "text": "Hello from Go!"
}

This allows us to keep Go naming conventions while returning clean JSON responses.

Understanding Response Headers

Inside the handler, we set a response header:

w.Header().Set("Content-Type", "application/json")

Headers provide additional information about the HTTP response.

Here, we tell the client:

"This response contains JSON data."

This is standard practice when building APIs.

Creating the Response Data

Inside the handler, we create a struct value:

response := Message{
    Text: "Hello from Go!",
}

This creates the data we want to send back to the client.

Encoding JSON Responses

This line converts the Go struct into JSON:

json.NewEncoder(w).Encode(response)

Here's what happens:

NewEncoder(w) creates a JSON encoder
w represents the HTTP response
Encode(response) converts the struct into JSON and sends it to the client

This is one of the most common ways to return JSON in Go web servers.

Step 4 — Run the Server

Start the application:

go run main.go

The server should now be running on port 8080.

Step 5 — Test the Server

Open your browser and visit:

http://localhost:8080

You should see:

{
  "text": "Hello from Go!"
}

Testing with curl

You can also test the server from the terminal using curl:

curl localhost:8080

You should receive:

{
  "text": "Hello from Go!"
}

What Happens When a Request Is Made?

Here's the flow:

The client sends an HTTP request
Go matches the route
The handler function runs
A struct is created
The struct is converted into JSON
The JSON response is sent back to the client

This is the foundation of many backend APIs.

Where to Go Next

Now that we can return JSON responses, we could extend this server by adding:

multiple API routes
dynamic JSON responses
request body handling
JSON decoding
CRUD operations — because, you know, every backend journey eventually leads there
databases

This is where backend development starts becoming more interactive and powerful.

Final Thoughts

We started with a plain text HTTP server, evolved it into a simple JSON API.

Along the way, we learned about:

structs
JSON encoding
response headers
API responses

These concepts form the foundation of modern backend development in Go.

Thanks for reading!

Happy coding!

Building a Simple Web Server in Go

Steve Omollo — Wed, 13 May 2026 09:29:31 +0000

Have you ever wondered how web servers work behind the scenes?

One of the best things about Go is that you can create a working HTTP server with a few lines of code. The standard library already gives us everything we need to start serving web requests without installing any frameworks.

In this tutorial, we will be building a simple web server in Go that:

listens on port 8080
responds to browser requests
serves different routes
returns simple text responses

By the end, you will understand the basics of how Go handles HTTP requests and responses.

Prerequisites

To follow along, you should have:

Go installed
basic familiarity with the terminal
beginner-level Go syntax knowledge

You can confirm if Go is installed by running:

go version

Step 1 — Create the Project

Create a new folder for the project:

mkdir simple-go-server
cd simple-go-server

Now initialize a Go module:

go mod init simple-go-server

This creates a go.mod file that helps Go manage dependencies for the project.

Step 2 — Create the Server File

Create a file called main.go.

Your project should now look like this:

simple-go-server/
├── go.mod
└── main.go

Step 3 — Write the HTTP Server

Open main.go and add the following code:

package main

import (
    "fmt"
    "net/http"
)

func homeHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "Hello from Go!")
}

func aboutHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "This is the about page.")
}

func main() {
    http.HandleFunc("/", homeHandler)
    http.HandleFunc("/about", aboutHandler)

    fmt.Println("Server running on :8080")

    err := http.ListenAndServe(":8080", nil)
    if err != nil {
        fmt.Println("Error starting server:", err)
    }
}

Now let's unpack this.

Understanding the Imports

import (
    "fmt"
    "net/http"
)

We imported two packages:

fmt - is used for printing messages
net/http - is Go's built-in package for creating HTTP servers

The net/http package is part of Go's standard library, which means we don't need to install anything extra.

Understanding Handlers

This function:

func homeHandler(w http.ResponseWriter, r *http.Request)

is called a handler.

Handlers are functions that respond to incoming HTTP requests.

The parameters mean:

Parameter	Purpose
`http.ResponseWriter`	Used to send data back to the client
`*http.Request`	Contains information about the incoming request

Inside the handler, we write a response:

fmt.Fprintln(w, "Hello from Go!")

This sends text back to the browser.

Understanding Routes

Here:

http.HandleFunc("/", homeHandler)

we tell Go:

"When someone visits /, run the homeHandler function."

And here:

http.HandleFunc("/about", aboutHandler)

we register another route.

Now our server has two endpoints:

Route	Response
`/`	Hello from Go!
`/about`	This is the about page.

After registering routes, the final step is starting the server and listening for incoming requests.

Starting the Server

This line starts the web server:

http.ListenAndServe(":8080", nil)

The :8080 means:

"Listen for incoming requests on port 8080."

The nil tells Go to use the default request multiplexer.

Step 4 — Run the Server

Start the application:

go run main.go

You should see:

Server running on :8080

Step 5 — Test the Server

Open your browser and visit:

http://localhost:8080

You should see:

Hello from Go!

Now try:

http://localhost:8080/about

You should see:

This is the about page.

Testing with curl

You can also test the server from the terminal using curl.

For the home route:

curl localhost:8080

For the about route:

curl localhost:8080/about

Here's basically what happens when you visit a route:

Your browser sends an HTTP request
Go receives the request
Go checks which route matches
The correct handler runs
A response is sent back to the browser

This is the foundation of most backend web applications.

Where to Go Next

Our server is very simple, but from here you could add:

JSON responses
HTML templates
middleware
databases
REST APIs — because eventually, everyone builds one.

This is one reason many developers enjoy Go for backend development — you can start small and gradually build more complex systems while keeping the code readable.

Final Thoughts

Go makes it incredibly easy to get started with backend development.

With a few lines of code, we created a working HTTP server capable of handling multiple routes and serving responses to clients.

If you are learning backend development, understanding the net/http package is a great foundation before moving into larger frameworks and architectures.

Thanks for reading!

Happy coding!

DEV Community: Steve Omollo

I Chose Buffalo for a 48-Hour Hackathon. Then I Had to Figure Out How to Use It

From BSF farming to organic waste

Dividing the work

"You've chosen Buffalo? Then you guide us."

The framework makes things easier — until it doesn't

When Buffalo met Svelte

What RegenFeed actually did

The part we didn't solve

Three minutes

What I would do differently

What Buffalo taught me

Structuring Go Projects For Growth with Packages

Step 1 — Our Current Project

Step 2 — Create the Project Structure

Step 3 — Move the Task Struct

Step 4 — Create the Handler

What's different?

Understanding Import Paths

Step 5 — Update main.go

Understanding Exported Names

What Changed?

Step 6 — Run the Application

Building a CRUD API in Go

Prerequisites

Step 1 — Create the Project

Step 2 — Create the Server File

Step 3 — Write the CRUD API

Understanding CRUD Operations

Create and Read

Understanding Updates

Understanding Deletes

Understanding Slice Deletion

Step 4 — Run the Server

Step 5 — Create a Task

Step 6 — Retrieve Tasks

Step 7 — Update a Task

Step 8 — Delete a Task

What Happens When a Request Is Made?

Where to Go Next

Final Thoughts

Building a Simple Task API in Go

Prerequisites

Step 1 — Create the Project

Step 2 — Create the Server File

Step 3 — Write the API

Understanding the Struct

Understanding In-Memory Storage

Understanding HTTP Methods

Handling GET Requests

Handling POST Requests

Understanding append

Understanding Error Handling

Step 4 — Run the Server

Step 5 — Create a Task

Step 6 — Retrieve Tasks

What Happens When a Request Is Made?

Where to Go Next

Final Thoughts

Handling JSON Requests in Go

Prerequisites

Step 1 — Create the Project

Step 2 — Create the Server File

Step 3 — Write the Server

Understanding POST Requests

Understanding the Struct

Understanding Request Bodies

Decoding JSON Requests

So Why Do We Use &user?

Understanding Error Handling

Step 4 — Run the Server

Step 5 — Test the API

What Happens When a Request Is Made?

Where to Go Next

Final Thoughts

Returning JSON Responses in Go

Prerequisites

Step 1 — Create the Project

Step 2 — Create the Server File

Step 3 — Write the JSON Server

Understanding `append`

So Why Do We Use `&user`?

Why is `Text` Capitalized?