DEV Community: Collins Kipruto

🚀 Go Journey – Day 3: Accessing a Relational Database

Collins Kipruto — Wed, 29 Jul 2026 13:03:42 +0000

Today I wrapped up another milestone in my Go learning journey—connecting a Go application to a relational database.

Over the past few days, I've been building my backend fundamentals step by step. I started with RESTful APIs, moved on to web applications, and today I learned how to interact with a MySQL database.

One thing that stood out was how Go connects to a database. Instead of jumping straight into queries, you first configure the connection using the MySQL driver's Config struct and generate a DSN (Data Source Name) with FormatDSN(). After that, establishing the connection is surprisingly straightforward:

db, err := sql.Open(...)
if err != nil {
// handle error
}

This pattern has become very familiar to me. Whether I was building HTTP servers, writing REST APIs, or now working with databases, I keep seeing the same Go idiom:

Perform an operation.
Capture the result and err.
Check if err != nil.
Handle the error before moving on.

At first, I wondered why Go checks for errors so frequently. But the more I build with it, the more I appreciate the language's philosophy. By handling errors immediately, you're forced to think about what could go wrong and make your applications more reliable.

Another interesting observation was how similar querying multiple records and retrieving a single record by ID are. The structure is almost identical—the main difference is using Query() when expecting multiple rows and QueryRow() when expecting just one. That consistency made the concepts much easier to grasp.

Ironically, this was the topic I was most nervous about before starting. I expected databases to be the hardest part of the journey, but they turned out to be the smoothest so far. It's a reminder that sometimes the things we anticipate the most end up being the easiest once we dive in.

Looking forward to the next challenge as I continue building with Go.

🚀 Go Journey – Day 1: Building my first RESTful API with Gin

Collins Kipruto — Sun, 19 Jul 2026 10:47:36 +0000

Last week, I officially started learning how to build RESTful APIs in Go.
To keep things simple, I focused on the fundamentals before jumping into larger projects. My first API can:
✅ Retrieve all albums (GET /albums)
✅ Add a new album (POST /albums)
✅ Retrieve a specific album by its ID (GET /albums/:id)
Along the way, I learned what some of Gin's core features actually do instead of just copying code from tutorials.
A few concepts that finally clicked for me:
🔹 gin.Context
Carries information about the incoming HTTP request.
Helps read request data, validate input, and send responses back to the client.
🔹 Context.IndentedJSON()
Converts Go structs into properly formatted JSON.
Sends the JSON back to the client along with the appropriate HTTP status code.
🔹 BindJSON()
Reads the JSON sent in the request body.
Maps that data directly into a Go struct, making it easy to work with user input.
One thing I'm trying to do differently this time is document everything I learn instead of rushing to the next topic. I even created a README explaining what each function in my project does, because I want to understand the "why" behind the code—not just make it work.
This is only the beginning, but every endpoint I build is helping me understand how backend systems communicate with clients.
Next up:
Input validation
Better error handling
Connecting the API to a database
Authentication
I'm looking forward to seeing how much I improve over the next few months. 🚀

Go Journey – Day 2: Building My First Web Application in Go 🚀

Collins Kipruto — Sun, 19 Jul 2026 10:44:29 +0000

I shared my experience building my first RESTful API in Go. This week, I took the next step in my Go journey by learning how to build web applications.

The next milestone? Working with relational databases in Go.

My goal with this series is simple: learn Go one step at a time while documenting the journey. By the end, I want to have enough knowledge to build a complete web application—from the backend to the frontend—and I hope others who are learning Go can follow along too.

What I Learned This Week

This week was all about understanding how a web application works under the hood. Instead of just writing code, I focused on understanding the flow of a request and how different components fit together.

Here are some of the concepts I covered.

Storing Data with Structs

The first step was learning how to represent data using Go structs.

For the wiki application, each page was represented as a struct containing the page title and body.

type Page struct {
Title string
Body []byte
}

This became the foundation for everything else in the application.

Saving Data

After creating the struct, I learned how to save a page to disk.

Each page is stored as a text file, using the page title as the filename. This gave me a better understanding of how Go handles file operations and methods.

Loading Existing Pages

Saving data isn't enough—you also need to retrieve it.

I learned how to read the stored files back into memory so users can view pages that were previously created.

Although simple, this really helped me understand the flow of data in a web application.

Understanding net/http

One of the biggest topics this week was Go's net/http package.

I learned how HTTP requests move through the application and how Go uses handlers to respond to users.

Some of the things I explored included:

Creating routes
Handling requests and responses
Redirecting users when a page doesn't exist
Understanding http.ResponseWriter
Understanding *http.Request

Seeing how everything connects made the request-response cycle much clearer.

Template Caching

One of my favorite takeaways was learning about template caching.

At first, I was parsing HTML templates every single time a request came in.

func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
t, err := template.ParseFiles(tmpl + ".html")
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}

err = t.Execute(w, p)
if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
}

}

Then I learned there's a much better approach.

Instead of repeatedly reading template files from disk, you can parse them once when the application starts.

var templates = template.Must(
template.ParseFiles("edit.html", "view.html"),
)

This small change improves efficiency and is considered the better practice.

It was a great reminder that writing code isn't just about making it work—it's also about making it perform well.

Path Validation and Closures

Another interesting concept I encountered was path validation.

I learned how validating request paths prevents users from accessing invalid or unexpected routes.

While implementing this, I was introduced to closures in Go—something I had heard about before but hadn't used in a practical example.

That's definitely a topic I plan to explore further.

My Biggest Takeaway

This week taught me that building web applications is about much more than displaying pages.

It's about understanding:

how data flows,
how requests are processed,
how files are managed,
how templates are rendered efficiently,
and how to build applications that are secure and maintainable.

Every chapter makes me appreciate Go's simplicity even more.

What's Next?

The next chapter of my journey is working with relational databases in Go.

Once I have that in place, I'll begin combining everything I've learned into a larger project instead of isolated tutorials.

If you're also learning Go, I'd love to hear what you're currently building or what topics you think I should explore next.

Thanks for reading, and see you in the next chapter!

Happy coding! 🚀

Series: Learning Go in Public

✅ Part 1: Building My First RESTful API
✅ Part 2: Building My First Web Application
🔜 Part 3: Working with Relational Databases in Go

Building a Go Payment API Library From Scratch

Collins Kipruto — Thu, 09 Jul 2026 13:03:30 +0000

description:

Insights on pointers, methods, resource management, and HTTP clients while building an open-source Go library.

tags:

golang, backend, webdev, learning

A few days ago, a couple of friends and I decided to take a detour from our usual routines to build something practical: a Go library for payment APIs.

The goal is simple. Instead of every Go developer writing custom, repetitive code to integrate payment gateways, they can just import our open-source library straight from GitHub.

Building a library forces you to think deeply about architecture, developer experience, and language fundamentals. Here is everything this project has taught me so far.

1. Client Structure and a Sharper Grip on Pointers

Setting up the base client structure required a lot of intentional data modeling. In doing so, I gained a much clearer understanding of pointers in Go. Deciding when to pass a struct by value versus passing a pointer to mutating states is a critical choice when designing an API client that other developers will rely on.

2. Deconstructing the Authentication Flow

Implementing authentication gave me a front-row seat to the full request-response lifecycle. I broke down the exact steps needed to establish a secure connection:

URL Construction: Building clean, dynamic endpoints.
Request Creation: Preparing payloads and setting secure headers.
Validation: Verifying our data before it leaves the application.
Transmission & Response: Sending the request to the admin server and handling the incoming payload cleanly.

3. Functions vs. Methods: The Concrete Difference

While the terms are often used interchangeably in other languages, Go draws a distinct line between functions and methods.

A Function is a standalone block of code used to execute a program routine.
A Method is simply a function that contains a receiver, meaning it belongs to a specific type.

// This is a standalone function
func ClearCache() {
    // logic here
}

// This is a method belonging to the 'User' struct type
func (u *User) DeactivateAccount() {
    // logic here
}

4. Resource Management: Why You Must `defer Body.Close()`

One of the biggest gotchas for newer Go developers is resource leakage via HTTP responses. When you make a network request, the server keeps the connection open until you explicitly close it.

Using defer response.Body.Close() right after checking for errors is mandatory.

Think of it like borrowing a book from a library. If you keep borrowing books and never return them, your state keeps looping on "borrowing." Eventually, the library runs out of space, and you cannot borrow anymore. In Go, failing to close the body will cause your application to run out of memory and file descriptors.

5. Staying Flexible with `http.Client.Do()`

When interacting with different payment endpoints, you encounter various HTTP verbs like POST, GET, PUT, and DELETE.

Instead of wrapping our client in strict, specialized helpers, we relied on Go's native http.Client.Do() method. Because .Do() accepts a completely custom *http.Request object, it accommodates any HTTP method seamlessly. If an upstream payment provider suddenly changes a route from a POST to a PUT, our underlying architecture remains intact and resilient.

Wrapping Up

This project is turning out to be an amazing engineering journey. By building this library, I am moving past just "using" payment APIs to truly understanding how they function under the hood.

I'll be sharing more updates as my team moves closer to our alpha release. If you have any tips on building clean SDKs in Go, let me know in the comments below!

What I Learned Building My First Go Project (go-reloaded)

Collins Kipruto — Wed, 17 Jun 2026 09:42:25 +0000

During my first week at Zone01 Kisumu, I worked on a project called go-reloaded. It was my first real hands-on experience using Go, and it helped me understand not just the language, but also how to think like a developer.

In this article, I’ll share what I learned, the challenges I faced, and the key concepts that made everything click.

What the Project Was About

The goal of the project was to build a small Go program that works with command-line arguments and processes input using Go’s standard libraries.

This was my first time interacting deeply with:

os package
command-line arguments (os.Args)
basic Go program structure

At first, it felt confusing, but step by step, things started to make sense.

What I Learned

How command-line arguments work in Go I learned that Go provides access to raw input from the terminal using: os.Args

This returns a slice of strings where:
os.Args[0] is the program name
os.Args[1:] are the actual inputs

Working with the os package The os package became one of the most important parts of the project.

I used it to:
Read input arguments
Handle program execution flow
Understand how programs interact with the system

This helped me realize that Go is very close to the system level compared to JavaScript.

Breaking problems into smaller steps One of the biggest lessons wasn’t about code—it was about thinking. Instead of trying to solve everything at once, I learned to:

Understand the problem first
Break it into smaller tasks
Solve each part step by step

This made debugging much easier.

Challenges I Faced

At the beginning, I struggled with:

Understanding how os.Args works
Knowing where to start in the code
Handling errors when inputs were missing

Sometimes I would get stuck just trying to figure out what the program was actually receiving.

But debugging helped me a lot. Printing values at each step made things clearer.

Key Takeaways

Go is very explicit compared to JavaScript
The os package is powerful for system-level interaction
Command-line arguments are simple but very useful
Problem-solving is more important than syntax
Debugging is part of learning, not a failure

Final Thoughts

This project was a big step in my learning journey. It helped me understand how Go works and how to approach programming problems more effectively.

I’m still learning, but each project is making things clearer.

Next, I’m looking forward to building more complex projects and improving my backend and DevOps skills.