Forem: Hillary Ombima

Git Commands You'll Actually Use

Hillary Ombima — Fri, 31 Oct 2025 09:20:13 +0000

You know that sinking feeling when you delete the wrong file? Or when you're trying to merge your teammate's code and suddenly everything's red and broken? Yeah, Git won't prevent those moments, but it'll definitely save you from them.

I used to think Git was just something you grudgingly learned because everyone else used it. Then I actually started using it properly, and honestly? It changed everything. Suddenly I could experiment without fear, collaborate without chaos, and actually understand what happened to my code last time.

This isn't going to be one of those boring Git tutorials that dumps 50 commands on you. Instead, we're covering the essentials: the commands you'll actually use daily, explained in plain English. Whether you're brand new to Git or you've been faking it with the same three commands for years, let's get you comfortable with version control.

So let's start with the basics, the commands that'll become muscle memory.

1.git init

This is how you tell Git "hey, start tracking this project." Run it once in your project folder and Git creates a hidden .git directory where it stores all your version history.

mkdir myApp
cd myApp
git init

Now your folder is a Git repository. That's it.

2.git add

Stages changes in the current directory and sub directories.

Think of this as preparing your changes for a snapshot. You're telling Git "these are the files I want to include in my next commit." Nothing's permanent yet, you're just staging things.

echo "# My firs App" > README.md
echo "Demo" >> README.md
git add README.md

Pro tip: Use git add . to stage everything at once, but be careful; you might accidentally include files you didn't mean to (like that secrets.env file you forgot about).

3.git commit

Now you're taking the snapshot. This saves all your staged changes with a message describing what you did. Think of commits like save points in a video game; you'll thank yourself later when you need to roll back.

git add README.md
git commit -m "Initial commit

The -m flag lets you add your message right in the command. Keep it short and descriptive: "Initial commit", "Fix login bug", "Add user dashboard", etc.

4.git push

You've made commits locally, but now you need to send them to GitHub (or wherever your remote repository lives). That's what push does, it uploads your local changes to the cloud.

git add .
git commit -m "feat: add a new feature"
git push

First time pushing to a new branch? Git will probably yell at you and tell you to use git push -u origin branch-name. Just do what it says, the -u sets up tracking so future pushes are easier.

5.git pull

Your teammate just pushed changes. Before you start working, you need to grab their updates and merge them into your local code. That's git pull, it downloads changes and automatically merges them.

git status
git pull origin main
git log --oneline

Warning: If you have uncommitted changes and you pull, Git might complain about conflicts. Commit or stash your work first to avoid headaches.

6.git remote
This connects your local repository to a remote one (like on GitHub). You'll usually do this once when setting up a project.

git remote add origin <url>
git remote -v
git remote rename origin myFirstApp

The origin name is just a convention: it's the default name for your main remote repository. You can call it whatever you want, but everyone uses origin so... just stick with that.

7.git branch

Branches let you work on features without touching your main code. Think of them as parallel universes for your project — experiment freely, then merge back when you're ready.

git branch
git branch feature-UI-layout
git branch

The first git branch lists all branches. The second creates a new one. The third confirms it was created. You're still on your original branch though — creating doesn't switch you to it.

8.git fetch

This downloads changes from the remote repository but doesn't merge them into your code. It's like checking what's new without actually integrating it yet.

git fetch origin

When to use it: When you want to see what others have done before deciding to merge. It's the cautious version of git pull.

9.git checkout

Switches you between branches. It's how you move from one parallel universe to another.

git branch
git checkout feature-UI-layout
git branch

You'll see an asterisk (*) next to the branch you're currently on. Modern Git also has git switch which does the same thing but is more explicit.

10.git merge

You finished your feature branch and now you want to bring those changes back into main. That's what merge does, it combines the histories of two branches.

git checkout main
git merge feature-UI-layout
git log --oneline

Merge conflicts are normal. When Git can't figure out how to combine changes automatically, it asks you to decide. Don't panic: just open the files, pick which changes to keep, and commit the result.

11.git status

Your best friend when you're confused. It shows what files have changed, what's staged, what's not, and which branch you're on.

git status
echo "Happy learning git" >> hello.txt
git status

Run this constantly. Seriously. Before commits, after pulls, when things feel weird — git status is your diagnostic tool.

12.git reset
Made a mistake? git reset lets you undo commits and move your branch pointer back in time. Be careful with this one.

git log --oneline
git reset --hard <commit-hash>
git status

The --hard flag is dangerous — it deletes your changes permanently. Use --soft if you want to keep the changes but undo the commit. And if you've already pushed, don't reset — use git revert instead.

Conclusion

These twelve commands will cover 90% of your daily Git usage. You don't need to memorize every flag or option, just understand what each command does and why you'd use it.

Git gets easier the more you use it. Yeah, you'll mess up sometimes (we all have). But that's fine, Git is designed to handle mistakes. Just keep committing, keep experimenting, and don't be afraid to Google when things get weird. Want to level up your Git skills? Try this interactive practice tool here.

Now go forth and version control with confidence. You've got this.

From Trust to Consensus: How Stellar Reaches Agreement Without Mining

Hillary Ombima — Mon, 29 Sep 2025 11:14:47 +0000

Consensus is what keeps Stellar’s decentralized payment network secure and synchronized. Instead of one central authority approving transactions, many independent nodes (validators) agree on the same version of the ledger. This prevents double-spending and ensures reliability.

Why SCP?

Unlike Proof of Work (Bitcoin) or Proof of Stake (Ethereum and others), Stellar’s SCP is based on Federated Byzantine Agreement (FBA). Each validator chooses a set of other validators it trusts (its quorum set). Agreement emerges when these trust choices overlap, giving SCP its open and decentralized nature.

No mining.
No staking.
Just trust-based agreement.

Key Terms

Quorum set → The list of nodes a validator trusts.
Threshold → Minimum number of nodes in that set that must agree.
Quorum slice → A smaller subset of the quorum set that’s enough to reach agreement.
Federated voting → Validators move from voting → accepting → confirming a statement.
Safety vs Liveness → SCP prioritizes safety (no conflicting ledgers) over liveness (progress may pause until consensus is reached).

How SCP Reaches Agreement

Nomination → Nodes propose transaction sets. Over time, they converge on the same candidate set.
Ballot protocol → Validators vote, prepare, and commit that candidate set until the network locks in a single, agreed ledger.

Why It Stands Out

Fast & energy-efficient → No mining required.
Decentralized trust → Each node defines who it trusts.
Resilient → Safety is guaranteed as long as quorum sets overlap correctly.

Takeaway

SCP is Stellar’s way of achieving global agreement without mining or staking. It’s lightweight, secure, and designed for payments. The trick is in quorum design: overlap ensures safety and keeps the network moving forward.

Next time you hear “consensus,” remember: on Stellar, it’s all about trust + overlap. That’s SCP in a nutshell.

The Evolution of the Web: From Static Pages to Decentralized Dreams 🌐

Hillary Ombima — Wed, 04 Jun 2025 11:21:07 +0000

Ever wondered how we went from simple HTML pages to owning digital assets on the blockchain? Let's take a journey through the three eras of the web and explore what makes Web3 so revolutionary.

The Cold War Origins

Before diving into the web evolution, here's a fun fact: the internet was born from Cold War paranoia!

In the 1960s, the U.S. Department of Defense's ARPA created ARPANET — a communication network designed to survive nuclear attacks. The irony? What started as a military defense system became the foundation for cat videos and memes.

💡 Did you know? The first ARPANET message was sent on October 29, 1969, between UCLA and Stanford. It was supposed to say "LOGIN" but crashed after "LO" — technically making the first internet message failed attempt!

🌍 Web 1.0: The Static Era

Timeline: Early 1990s - 2004
Core Traits: Read-only, static web pages, limited user interaction

What Was It Like?

Imagine opening a website and seeing... just text and maybe a few images. No comments, no likes, no sharing buttons. You were essentially reading a digital newspaper that never changed.

Web 1.0 brought global access to information, allowing anyone to publish content that could be viewed worldwide. It enabled real-time updates, with breaking news reaching millions instantly, and introduced multimedia elements like text, images, and simple audio or video.

However, it lacked interactivity, users couldn’t comment or engage with the content. Content creation was mostly limited to organizations, leaving everyday users as passive consumers rather than active participants.

Web 2.0: The Social Revolution

Timeline: ~2004 - Present
Core Traits: User-generated content, interactivity, community-building

Web2.0 emerged as a response to the static limitations of Web1.0. This new phase of the internet championed interactivity, collaboration, and user participation. It transformed the internet from a one-way information flow into a dynamic space where users could generate and share content freely.

The rise of blogs, forums, microblogs, and social media platforms like Facebook, Twitter, and TikTok defined this era, allowing people not only to consume content but to actively contribute and engage with global communities.

However, as user-generated content flourished, so did new challenges. One of the most pressing issues became data ownership—users created content, but platforms retained control over it. This led to increasing concerns about privacy breaches, as personal data became a commodity vulnerable to leaks and exploitation.

Moreover, filter bubbles began to shape user experience, with algorithms feeding individuals personalized content that often reinforced existing views rather than broadening perspectives.

On top of that, the creator economy—despite offering new monetization opportunities—was heavily skewed, with platforms taking significant portions of creators' earnings and maintaining dominance over distribution and discovery.

🔐 Web 3.0: The Decentralized Future

Timeline: 2015 - Present (Still Emerging)
Core Traits: User-generated content, interactivity, community-building.

Web3.0 emerged as a bold response to the pitfalls of Web2.0, proposing a radical reimagining of the internet—one where users don’t just consume or create, but truly own their digital lives. At the heart of this shift lies a vision of a more secure, transparent, and user-centric internet that minimizes reliance on centralized authorities like Google and Facebook.

Rather than entrusting tech giants with personal data, Web3.0 leverages blockchain technology to ensure transparency and security. Central to this are smart contracts, self-executing pieces of code that automate transactions and agreements without the need for intermediaries.

This foundation has given rise to Decentralized finance (DeFi), enabling financial transactions without banks, and Non-Fungible tokens (NFTs), which allow digital ownership of unique assets.

The ecosystem further expands with decentralized governance models, such as DAOs (Decentralized Autonomous Organizations), where users participate in decision-making processes, and with distributed storage systems like IPFS, reducing dependency on centralized servers.

A major milestone in the evolution of Web3.0 was the launch of Ethereum in 2015 by Vitalik Buterin and collaborators. Ethereum provided the first real platform for building decentralized applications (DApps), where logic could be embedded into money through programmable contracts.

With Ethereum, users could create and interact with apps that didn’t rely on central servers, ushering in a new era of programmable money, trustless execution, and global participation.

Web3.0 remains in its early stages and presents challenges such as usability, regulation, and accessibility. However, its underlying ethos—empowering individuals through ownership, privacy, and decentralization—continues to gain momentum, pointing toward an internet where control is truly in the hands of its users.

📊 The Evolution Summary

Era	Key Feature	You Could...	You Couldn't...
Web 1.0	Read-Only	Access information	Interact or create
Web 2.0	Read-Write	Create & share content	Own your data
Web 3.0	Read-Write-Own	Own digital assets	Avoid complexity (yet)

🔗 Connect & Continue Learning

If you enjoyed this deep dive, Let’s connect on GitHub / LinkedIn

Want to go deeper?

Ethereum Whitepaper — The document that started it all
Web3 Developer Roadmap — If you want to start building
DeFi Pulse — Track the decentralized finance ecosystem

What aspect of Web3 are you most curious about? Let me know in the comments, and I might write a deep dive on that topic next! 🚀

Tags: #Web3 #Blockchain #Ethereum #Technology #Internet #Decentralization #Cryptocurrency #Defi #NFTs #Development

Mastering Go's net/http Package: A Comprehensive Guide for Beginners

Hillary Ombima — Wed, 18 Sep 2024 13:26:39 +0000

The net/http(Hypertext Transfer Protocol) package in Go is a powerful and versatile tool for building web applications and APIs. Whether you're creating a RESTful API, a simple web server, or a more complex web application, understanding this package is essential. This guide will walk you through the basics of the net/http package, provide practical examples, and help you build a simple web application.

Introduction

Go's net/http package is the backbone of web development in Go. It provides the core functionality needed to build HTTP servers and clients, making it a fundamental skill for any Go developer. This guide aims to provide you with a solid foundation in using net/http, starting from the basics and moving towards more advanced topics.

Step 1: Understanding the Basics of `net/http`

The net/http package provides the core functionality for HTTP servers and clients in Go. Here's a quick overview of its components:

Overview of Key Components

1. http.HandleFunc

Purpose: Registers a handler function for a specific route or URL pattern.

How It Works:

This function maps a URL path to a handler function. The handler function is responsible for processing requests to that URL path.
It takes two arguments: the URL pattern and the handler function. The URL pattern specifies the route (e.g., /home, /api/data), and the handler function defines what happens when a request is made to that route.
Example: http.HandleFunc("/hello", helloHandler) registers the helloHandler function to handle requests to /hello.

2. Key Points:

The handler function should have the signature func(w http.ResponseWriter, r *http.Request).
http.HandleFunc is a convenient way to set up route handlers without needing to manually create a multiplexer.

3. http.ListenAndServe

Purpose: Starts an HTTP server and listens for incoming requests on a specified port.

How It Works:

This function takes two arguments: the address to listen on and a handler to process incoming requests. If the handler is nil, the default multiplexer (http.DefaultServeMux) is used.
The address is usually in the form of ":port", where port is the port number the server will listen to (e.g., ":8080").
Example: http.ListenAndServe(":8080", nil) starts an HTTP server on port 8080 and uses the default multiplexer to route requests.

4. Key Points:

This function blocks and runs indefinitely, handling requests until the server is stopped.
Errors returned by http.ListenAndServe (like http.ErrServerClosed) usually indicate issues with starting the server or running it.

5. http.Request and http.ResponseWriter

Purpose: Represent the HTTP request and response in the handler functions.

http.Request Details:

Contains information about the incoming request, such as the HTTP method (GET, POST, etc.), URL, headers, and body.
Provides methods for retrieving URL parameters, query strings, and form data.
Example: r.Method returns the HTTP method used in the request, and r.URL.Path gives the requested URL path.

6. http.ResponseWriter Details:

Used to construct the HTTP response sent back to the client.
Provides methods for setting headers, writing the response body, and setting the HTTP status code.
Example: w.Write([]byte("Hello World")) writes the string "Hello World" to the response body.

Understanding Multiplexers

A multiplexer (mux) is a fundamental component in handling HTTP requests in Go. It is responsible for routing incoming requests to the appropriate handler functions based on the URL path.

1. Default Multiplexer `(http.DefaultServeMux)`

Purpose: Handles routing using the built-in multiplexer provided by the net/http package.

How It Works:

http.HandleFunc registers handlers with the default multiplexer, which is created and managed internally by the Go standard library.
The default multiplexer routes requests based on the URL path and serves the corresponding registered handler.

2. Key Points:

It is simple and convenient for basic use cases and small applications.
The default multiplexer is used automatically if you pass nil to
http.ListenAndServe.

3. Custom Multiplexers

Purpose: Allows more advanced routing and middleware support.
How It Works:

You can create custom multiplexers using http.NewServeMux(). This gives you more control over routing and handler registration.
Custom multiplexers are useful for organizing routes and applying middleware across different parts of your application.

4. Example Usage:

Create a new multiplexer: mux := http.NewServeMux()
Register handlers with it: mux.HandleFunc("/home", homeHandler)
Pass it to http.ListenAndServe: http.ListenAndServe(":8080", mux)

5. Key Points:

Custom multiplexers are beneficial for larger applications or when you need specific routing logic that the default multiplexer does not support.
They allow you to set up more complex routing schemes and middleware pipelines.
Handling HTTP Requests and Responses
- A basic handler function might look like this:

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Request Method: %s", r.Method)
}

Creating Simple Handlers
- Define a handler for the /hello route:

http.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) { 
fmt.Fprintf(w, "Hello, %s!", r.URL.Path[1:]) 
})

Step 2: Setting Up Your Go Environment

Install Go

To get started, you need to have Go installed on your machine.

1. Visit the Official Go Website and download the installer for your operating system.

2. Follow the installation instructions specific to your OS.

Set Up a Code Editor

Choose a code editor that suits your workflow. Popular options include:

Visual Studio Code (VSCode): Install the Go extension from the extensions marketplace.
GoLand: A feature-rich IDE tailored for Go development.

Verify Installation

Open your terminal and run the following command to verify your Go installation:

go version

Run a Basic HTTP Server (with code example below)

Setup and Initialization:

The code starts by importing necessary packages:(eg fmt) for formatted I/O operations and net/http for building the HTTP server.

Defining the Main Function:
- The main function serves as the entry point of the application.
Understanding the Multiplexer:
- In the Go HTTP server context, the multiplexer is a core component responsible for routing incoming HTTP requests to the appropriate handler functions. It matches the URL path of the request to registered routes and directs the request accordingly.
- The http.HandleFunc function registers a route with a handler function in the multiplexer. When a request comes in, the multiplexer uses the URL path to find the correct handler.
Registering a Route:
- The server sets up a route using http.HandleFunc. This function associates a specific URL path (e.g., /) with a handler function.
- The handler function processes requests to this route and generates responses. In this case, it sends a plain text response back to the client with a welcome message.
Starting the Server:
- http.ListenAndServe is called to start the HTTP server on a specific port (e.g., port 8080). It initializes the server and starts listening for incoming requests.

This function also uses the multiplexer to route requests. It continuously listens for incoming HTTP requests and directs them to the appropriate handlers based on the URL path.

Handling Requests:
- When a request is made to the server, the multiplexer matches the URL path of the request to the registered routes.
- It then invokes the corresponding handler function, which processes the request and sends a response back to the client.
- Here’s an example implementation in code.
- Create a file named main.go with the following code:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Welcome to net/http guide web page")
    })

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

Step 3: Building a Basic Web Server

In this step, you will learn how to build a simple web server that can handle multiple routes. Here’s a detailed explanation of the key concepts involved:

1. Setting Up the Server

Concept: You need to set up an HTTP server that listens for incoming network requests. This involves defining how and where the server will listen for requests.

Explanation:

Initialization: Start the server by specifying the port on which it will listen for incoming connections. This port is part of the server's address and allows it to receive network traffic.
Execution: The server continues to run, waiting for requests from clients (like web browsers) and handling them according to the routes and handlers you define.

2. Defining Routes

Concept: Routes are URL paths that your server will respond to. You map these paths to specific functions that process the request and generate a response.

Explanation:

Route Mapping: Use routing functions to associate specific URL paths (e.g., /, /about) with handler functions. Each route corresponds to a different URL pattern that the server recognizes.
Route Handlers: Each route has an associated handler function that determines how requests to that URL should be processed. These handlers are responsible for generating the appropriate responses.

3. Creating Handler Functions

Concept: Handler functions define the logic for processing HTTP requests. They determine how to respond to a request based on the URL path and other request details.
Explanation:

Request Processing: The handler function receives an HTTP request and an HTTP response writer. It processes the request, performs any necessary operations (such as querying a database or computing a result), and writes the response back to the client.
Generating Responses: The function uses the response writer to send data (like HTML or plain text) back to the client. This is where you define what content the user will see in their web browser.

4. Sending Responses

Concept: After processing a request, your server must send a response back to the client. This response can include various types of content, such as plain text, HTML, or JSON.

Explanation:

Response Writing: Use the response writer to format and send the content of the response. This might include setting the HTTP status code (e.g., 200 for success) and writing the body of the response.
Content Types: The content can be as simple as a welcome message or as complex as dynamically generated HTML or JSON data.

Detailed Overview of a Simple HTTP Server with Multiple Routes

1. Server Setup:

Purpose: Initialize the server and specify the port to listen for incoming connections.
Logic: The server runs indefinitely, handling requests as they come in.

2. Route Definition:

Purpose: Define how the server should respond to different URL paths.
Logic: Map each URL path to a specific handler function using route registration methods.

3. Handler Functions:

Purpose: Process incoming requests and generate responses.
Logic: Each function handles a specific route, processes the request data, and writes a response to the client.

4. Response Handling:

Purpose: Send a response back to the client with appropriate content.
Logic: Write data to the response writer, which sends it to the client's web browser.

By understanding these components and their interactions, you can build a basic web server that handles multiple routes, processes requests, and sends responses, laying the groundwork for more complex web applications.

Implement a Simple HTTP Server
- Example server with multiple routes:

package main 
import ( 
   "fmt" 
   "net/http" 
) 
func main() { 
   http.HandleFunc("/", homeHandler) 
   http.HandleFunc("/about", aboutHandler) 
   http.ListenAndServe(":8080", nil) 
} 

func homeHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Welcome to the Home Page!") 
} 
func aboutHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "About net/http")             
}

Define Routes and Handlers
- Add more routes and handlers as needed for your application.
Test Your Server
- Use a web browser or tools like curl to test different routes.

4: Handling Different HTTP Methods

Different HTTP methods (GET, POST, PUT, DELETE) are essential for RESTful APIs and web applications.

Understanding HTTP Methods for Web Development

HTTP methods are fundamental to how web applications and APIs interact with clients. Each method serves a specific purpose in handling requests and performing operations. Here’s a deeper dive into the most commonly used HTTP methods and how they are typically handled in web applications:

1. GET Method

Purpose:

Retrieval of Data: The GET method is used to request data from a specified resource. It is designed to retrieve information without making any modifications to the data on the server. Characteristics:
Idempotent: Multiple identical GET requests should have the same effect as a single request. They should not change any server state.
Safe: It should not cause any side effects on the server. The operation is read-only.

Usage:

Fetching Data: When a user requests a webpage or an API endpoint that provides information (e.g., retrieving a list of users or displaying a product's details), a GET request is typically used.

2. POST Method

Purpose:

Submitting Data: The POST method is used to submit data to be processed to a specified resource. This often involves creating or updating data on the server.
Characteristics:
Non-idempotent: Submitting the same data multiple times can result in different outcomes, such as creating multiple records or processing the same transaction multiple times.
Data Transmission: It often involves sending data in the request body, which is processed by the server to create or update a resource.

Usage:

Form Submissions: When users submit forms on a website (like signing up or posting a comment), the server uses POST requests to process and store the data.

3. PUT Method

Purpose:

Updating Data: The PUT method is used to update a resource with new data. It can also be used to create a resource if it doesn’t already exist.
Characteristics:
Idempotent: Multiple identical PUT requests should result in the same outcome as a single request. It replaces the resource's current state with the new data.
Complete Replacement: Typically, PUT requests replace the entire resource with the new data provided.
Usage:
- Resource Updates: When updating a resource (like editing a user's profile information or changing a product's details), the server uses PUT requests to apply these updates.

4. DELETE Method

Purpose:

Removing Data: The DELETE method is used to remove a specified resource from the server. Characteristics:
Idempotent: Multiple identical DELETE requests should have the same effect as a single request. Once a resource is deleted, further DELETE requests for the same resource should have no additional effect.
- Resource Deletion: It instructs the server to delete the specified resource. #### Usage:
- Removing Items: When deleting a resource (like removing a user account or deleting a product from an inventory), the server uses DELETE requests to carry out this action.

Handling GET and POST Requests

In a web application, handling GET and POST requests involves defining how your server should process these requests and generate responses. Here's a breakdown of how these methods are typically handled:

1. Handling GET Requests:

Define Endpoints: Set up routes that respond to GET requests by fetching and returning data from the server.
Retrieve Data: Access the requested resource or query the database to retrieve the necessary information.
Respond to Client: Send the retrieved data back to the client in the appropriate format (e.g., HTML, JSON).

2. Handling POST Requests:

Define Endpoints: Set up routes that respond to POST requests by accepting data submitted by the client.
Process Data: Parse and validate the data from the request body. Perform the necessary operations (e.g., saving data to a database).
Respond to Client: Provide a response indicating the result of the operation (e.g., success message, newly created resource details). By understanding and correctly implementing these HTTP methods, you can build robust web applications and APIs that effectively handle various types of interactions with clients.

Example of GET and POST in code implementation:

func handlePost(w http.ResponseWriter, r *http.Request) { if r.Method == http.MethodPost { 
// Handle POST request 
   fmt.Fprintf(w, "POST request received") 
} 
} 
// GET request handler 
func handleGet(w http.ResponseWriter, r *http.Request) { 
   if r.Method == http.MethodGet { 
// Handle GET request 
    fmt.Fprintf(w, "GET request received") 
  } 
}

Implementing Handlers for Each Method
- Example of handling a PUT request:

func handlePut(w http.ResponseWriter, r *http.Request) { 
   if r.Method == http.MethodPut { 
// Handle PUT request 
   fmt.Fprintf(w, "PUT request received") 
  } 
}

Step 5: Working with Request Parameters

Handling request parameters is crucial for building dynamic web applications, as it allows your server to interact with user input and customize responses based on that input. Here’s a detailed explanation of how query parameters work and how they are managed in web applications:

Understanding Query Parameters

Query Parameters: These are key-value pairs included in the URL of a request. They are used to pass additional data to the server in a flexible and user-friendly way.
Structure:

URL Format: Query parameters are appended to the end of the URL after a question mark (?). Multiple parameters are separated by an ampersand (&). This is an example:

http://example.com/page?key1=value1&key2=value2

Keys and Values: Each parameter consists of a key and a value, separated by an equals sign (=). The key is the name of the parameter, and the value is the data associated with that key.

How Query Parameters Are Handled

Extraction: When a client makes a request to a server, the server can extract query parameters from the URL to customize the response based on the provided data.
Decoding: Query parameters are usually URL-encoded, meaning special characters are replaced with percent-encoded values (e.g., spaces become %20). The server needs to decode these parameters to interpret them correctly.
Validation: Extracted query parameters should be validated to ensure they meet expected formats and constraints. This helps in preventing issues such as SQL injection or malformed data from causing errors.
Usage: Once validated, query parameters can be used to:
- Filter data (e.g., displaying search results based on a keyword).
- Customize content (e.g., displaying user-specific information).
- Control behavior (e.g., pagination in a list of items).

Example Workflow

Client Request: A user submits a form or clicks a link that includes query parameters in the URL. For example, a search for "Go programming" might result in a URL like:

http://example.com/search?q=Go+programming&sort=latest

1. Server Handling:

The server receives the request and extracts the query parameters from the URL.
It decodes the parameters and validates them.
Based on the parameters, the server performs the necessary operations, such as querying a database for results or generating a specific response.
- Finally, it sends back a response tailored to the query parameters.

Response: The server's response includes the requested data or performs the action based on the provided parameters. For instance, it might display search results ordered by the latest entries if the sort=latest parameter was provided.

Handling Query Parameters in Practice

Accessing Parameters: In many web frameworks, you can access query parameters through request objects. They provide methods or properties to retrieve parameter values.
Error Handling: Handle cases where parameters might be missing or invalid by providing default values or error messages.
Security Considerations: Be cautious with user input in query parameters. Always validate and sanitize input to avoid security vulnerabilities.
- Retrieve query parameters from the URL example with code:

func searchHandler(w http.ResponseWriter, r *http.Request) { 
    query := r.URL.Query().Get("q") 
    sort := r.URL.Query().Get("sort") 
    var response string

    if query == "" { 
        response = "No search query provided." 
    } else { 
        response = fmt.Sprintf("Searching for: %s", query) 
    }
    if sort != "" { 
        response += fmt.Sprintf(" | Sorted by: %s", sort) 
    }
    fmt.Fprintf(w, response)
}

How to Test:

Start the Server:
- Run the Go program to start the server on http://localhost:8080.
Test Different URLs:
- Access http://localhost:8080/ to see the welcome message.
- Access http://localhost:8080/search?q=golang&sort=date to see a message including the search query and sorting order.
- Access http://localhost:8080/search?q=golang to see a message with only the search query.
- Access http://localhost:8080/search` to see the message indicating that no search query was provided.

Form Data

Handling Form Submissions

Overview:

Handling form submissions involves processing data sent from an HTML form to the server.
This data is typically sent using the POST method and can be accessed and processed in the handler function.

Explanation:

1. Form Submission Method:

When a form is submitted using the POST method, the data is included in the body of the request.

2. Parsing Form Data:

The r.ParseForm() method is used to parse the form data. This method populates r.Form with the submitted form values.

3. Retrieving Form Values:

r.FormValue("name") retrieves the value of the form field named "name". It returns an empty string if the field is not present.

4. Sending a Response:

The response is generated based on the submitted form data. In this case, it simply acknowledges the submitted name.

Example Usage:

HTML Form Submission:

Handler Processing: The handler reads the form data and responds with a message indicating the submitted name.

URL Path Parameters

Overview: URL path parameters are dynamic segments in the URL path used to identify specific resources. They are extracted directly from the URL path.

Explanation:

1. Extracting Path Parameters:

Path parameters are part of the URL itself. For example, in the URL /items/123, 123 is a path parameter.

2. Processing Path Parameters:

To extract the parameter, you can use string manipulation methods like strings.TrimPrefix to remove the fixed part of the path (/items/ in this case) and retrieve the dynamic part (123).

3. Generating a Response:

The handler uses the extracted path parameter to generate a response. In this case, it simply displays the extracted item ID.

Example Usage:
Request URL: Accessing http://localhost:8080/items/123 would extract 123 as the item ID from the URL path.
Handler Processing: The handler reads the item ID from the path and responds with a message that includes the item ID.
- Handle form submissions example:

URL Path Parameters
- Extract parameters from the URL path:

Step 6: Creating a RESTful API

Creating a RESTful API involves several important steps, from defining the endpoints to handling the data sent and received. Here's a detailed explanation of the key elements involved:

1. Define API Endpoints

Endpoints are specific URLs through which clients interact with the API. They represent various resources and operations that the API provides.

Endpoints Overview:
- Resource Representation: Each endpoint typically corresponds to a resource or a collection of resources. For instance, if you’re building an API for managing books, you might have endpoints for retrieving a list of books, getting details of a single book, creating a new book, updating an existing book, and deleting a book.
HTTP Methods: Endpoints use HTTP methods to define operations on resources:
- GET: Retrieve information from the server. For example, GET /books retrieves a list of books.
- POST: Create a new resource on the server. For example, POST /books adds a new book.
- PUT: Update an existing resource. For example, PUT /books/123 updates the book with ID 123.
- DELETE: Remove a resource from the server. For example, DELETE /books/123 deletes the book with ID 123.
Designing Endpoints:
- Use Plural Nouns: Typically, use plural nouns for resource names to represent collections. For example, /books for a collection of books and /books/{id} for a single book.
- Resource Hierarchy: Reflect relationships between resources in your endpoint structure. For example, if books belong to authors, you might have endpoints like /authors/{id}/books to get all books by a specific author.
- Consistency: Maintain a consistent naming convention and endpoint structure throughout the API to ensure predictability and ease of use. ### 2. Handle JSON Data JSON (JavaScript Object Notation) is the most commonly used data format for APIs. It’s lightweight, easy to read, and simple to parse.
Handling JSON Requests:
- Parse JSON Data: When a client sends data to the server, it often comes in JSON format. The server needs to parse this JSON data to extract the information needed to process the request.
- Data Validation: Ensure that the incoming JSON data adheres to the expected format and contains all necessary fields. Validate the data to prevent errors and ensure consistency.
Handling JSON Responses:
- Format Responses: When responding to client requests, format the response data as JSON. This allows the client to easily parse and use the data.
- Include Status Codes: Use HTTP status codes to indicate the result of the request. For example, return a 200 OK status for successful requests, 404 Not Found for non-existent resources, and 500 Internal Server Error for unexpected issues.

3. Example Workflow

Here’s a simplified workflow of how a RESTful API handles a typical request and response cycle:

1. Client Request:

The client sends an HTTP request to the API endpoint. For example, a GET request to /books/123 to retrieve details of a specific book.

2. Server Processing:

Extracting Data: The server extracts information from the request URL and any query parameters or request body.
Performing Operations: The server performs the necessary operations, such as querying the database or performing business logic.

3. Server Response:

Formatting Data: The server formats the response data as JSON.
Sending Response: The server sends the JSON data back to the client along with an appropriate HTTP status code.

4. Client Handling:

The client receives the JSON response, processes the data, and updates the user interface or performs other actions based on the response.
- Define your API endpoints:

Handle JSON Requests and Responses
- Parse JSON request body:

Implement CRUD Operations
- Create, Read, Update, Delete operations for managing resources. To implement the CRUD (Create, Read, Update, Delete) operations in your Go application using the net/http package, you typically define these operations in your handlers. These handlers will be associated with specific routes to manage your resources (e.g., books, users).

1. Create Operation (POST)

Where to Implement: In a handler function that is associated with a POST request to a specific route.
- Example:

2. Update Operation (PUT)

Where to Implement: In a handler function that is associated with a PUT request to update an existing resource.
- Example in code:

3. Delete Operation (DELETE)

Where to Implement: In a handler function that is associated with a DELETE request to remove a resource.
- Example in code:

Where to Add These Handlers

1. Routing Configuration:

Add these handler functions to your routing configuration in the main.go or a separate file where you define your routes.

Example:

Organizing Your Code

Create a Separate File: Consider creating a file like handlers.go to keep your handler functions organized.
Refactor for Reusability: If your CRUD operations involve a lot of common code (e.g., error handling, database connections), you can refactor them into helper functions or middleware.

By implementing the CRUD operations in this manner, you'll build a fully functional API that handles creating, reading, updating, and deleting resources.

Step 7: Error Handling and Logging

Error Handling

Error handling involves managing different kinds of issues that might arise during the execution of your application. In the context of HTTP servers, this usually involves:

Detecting Errors: Identifying when something goes wrong, such as invalid input, missing resources, or server issues.
Returning Error Responses: Sending appropriate HTTP status codes and messages to the client to indicate what went wrong. This helps the client understand the nature of the problem.
Providing User-Friendly Messages: Offering clear and helpful messages to users so they know what actions to take.

Custom Error Handlers

A custom error handler is a function that processes errors and generates appropriate responses. Implementing a custom error handler involves:

Defining an Error Handler Function: This function is responsible for generating error responses in a consistent format. It takes the http.ResponseWriter and http.Request as parameters, processes the error, and writes a response to the client.
Using Middleware: In more complex applications, you might use middleware to centralize error handling. Middleware functions wrap around your route handlers and handle errors that occur during request processing.
1. Logging Errors: Logging errors is important for debugging and understanding application issues. It involves recording detailed information about the error (like stack traces, request details, etc.) to a log file or monitoring system.

Example of Implementing Custom Error Handlers

To implement a custom error handler, you need to:

Create a Function: Define a function that generates a structured error response. This function might format the error message, set the appropriate HTTP status code, and log the error.
Integrate the Error Handler: Use this function in your route handlers to handle and respond to errors.

Here’s a high-level explanation of how you would implement this:

1. Define an Error Handler Function:

This function takes the http.ResponseWriter, http.Request, and an error message or status code.
It formats the error message, sets the response status code, and writes the response.

2. Modify Route Handlers:

In your route handlers, use the error handler function when an error occurs. ○ Instead of directly writing the error response in the handler, call the custom error handler function.

Example Overview

Suppose you want to handle errors for invalid item IDs and bad request formats. You could:

Create an Error Handler Function: Define a function to handle errors, which formats the error message and sets the HTTP status code.
Use the Error Handler in Route Handlers:
- In your route handlers, if an error condition is met (e.g., invalid ID or decoding failure), call the custom error handler function.
- Ensure that all error responses are consistent and provide useful information to the client.

Benefits of Custom Error Handlers

Consistency: Ensures that error responses are uniform across the application, making it easier for clients to handle errors.
Maintainability: Simplifies updating error handling logic in one place, rather than modifying individual route handlers.
Debugging: Provides detailed logging and error messages that are crucial for diagnosing and fixing issues in your application.

Implementing Custom Error Handlers

Create a custom error handler:

Logging Requests and Errors

Log request details:

Step 8: Testing Your HTTP Server

Testing your HTTP server involves creating tests that verify whether your server's routes, handlers, and functionalities work correctly. There are different types of tests you might write, but for HTTP servers, unit tests and integration tests are most common.

1. Writing Unit Tests for Handlers

Unit tests for HTTP handlers focus on testing individual route handlers in isolation. They check if the handlers process requests correctly and generate the expected responses. Here's a deeper dive into writing unit tests for handlers using Go's httptest package:

a. What is httptest?

httptest is a package in Go that provides utilities for testing HTTP handlers. It allows you to create mock HTTP requests and responses and to test how your handlers handle these requests.

b. Key Components

httptest.NewRequest: Creates a new HTTP request for testing purposes. You can set the URL, method, and body of the request.
httptest.NewRecorder: Records the HTTP response generated by a handler. It captures the status code, headers, and body so you can assert on them.

c. Writing a Test

Create a Test Function: Define a function with a name starting with Test and accepting a *testing.T parameter. This function will contain your test logic.
Set Up the Request: Use httptest.NewRequest to create a request that simulates a real HTTP request. This includes specifying the method (e.g., GET, POST), URL, and any necessary request body or headers.
Record the Response: Use httptest.NewRecorder to create a response recorder that will capture the output of your handler.
Invoke the Handler: Call your handler function with the request and response recorder. This simulates the request being processed by your server.
Check the Results: Assert that the recorded response matches your expectations. This includes checking the status code, response headers, and body content.

d. Example of a Unit Test

For an HTTP handler that processes GET requests to return a list of items, you would:

Set Up the Test Request: Create a mock GET request to the appropriate URL.
Record the Response: Initialize a response recorder to capture the handler's output.
Invoke the Handler: Pass the mock request and response recorder to your handler
Assert the Response: Check that the response status code and body match your expectations.

Example Overview

Assume you have a handler getItemsHandler that should return a list of items in JSON format:

Create a Request: You simulate a GET request to the /items endpoint.
Record the Response: You capture the response using a recorder.
Invoke the Handler: Call getItemsHandler with the mock request and recorder.
Assert the Results: Verify that the response status code is 200 OK, and the response body contains the expected JSON data.

Benefits of Testing

Reliability: Ensures that your handlers work as intended and handle edge cases correctly.
Catch Bugs Early: Identifies issues during development before they affect users.
Refactoring Safety: Provides confidence that changes to your code do not introduce new bugs.
Documentation: Tests can serve as documentation for how your handlers are expected to behave.

Best Practices

Write Testable Code: Ensure that your handlers are modular and testable.
Use Table-Driven Tests: Structure tests in tables for different input scenarios and expected outcomes
Isolate Tests: Each test should focus on a single aspect of the handler's behavior.
Clean Up: Ensure that your tests do not rely on external systems or mutable state.

Testing your HTTP server thoroughly helps in maintaining a robust application and ensures that your server's functionalities work as expected.

Example on how to write Unit Tests for Handlers using httptest:

Using the httptest Package
- Utilize httptest to create mock requests and responses for testing.

Conclusion

By now, you should have a solid understanding of Go's net/http package and how to use it to build web applications and APIs. Whether you're creating a simple web server or a complex API, the concepts covered in this guide will serve as a foundation for your Go web development journey.

For a complete implementation and additional examples, you can explore the full code in the GitHub repository: net-http-guide on GitHub.

Feel free to clone the repository, experiment with the code, and adapt it for your needs. If you have any questions or feedback, don’t hesitate to reach out!

Follow me on GitHub: https://github.com/ombima56

Forem: Hillary Ombima

Git Commands You'll Actually Use

Conclusion

From Trust to Consensus: How Stellar Reaches Agreement Without Mining

Why SCP?

Key Terms

How SCP Reaches Agreement

Why It Stands Out

Takeaway

The Evolution of the Web: From Static Pages to Decentralized Dreams 🌐

The Cold War Origins

🌍 Web 1.0: The Static Era

What Was It Like?

Web 2.0: The Social Revolution

🔐 Web 3.0: The Decentralized Future

📊 The Evolution Summary

🔗 Connect & Continue Learning

Want to go deeper?

Mastering Go's net/http Package: A Comprehensive Guide for Beginners

Introduction

Step 1: Understanding the Basics of net/http

Overview of Key Components

1. http.HandleFunc

How It Works:

2. Key Points:

3. http.ListenAndServe

How It Works:

4. Key Points:

5. http.Request and http.ResponseWriter

http.Request Details:

6. http.ResponseWriter Details:

Understanding Multiplexers

1. Default Multiplexer (http.DefaultServeMux)

How It Works:

2. Key Points:

3. Custom Multiplexers

4. Example Usage:

5. Key Points:

Step 2: Setting Up Your Go Environment

Install Go

1. Visit the Official Go Website and download the installer for your operating system.

2. Follow the installation instructions specific to your OS.

Set Up a Code Editor

Verify Installation

Setup and Initialization:

Step 3: Building a Basic Web Server

1. Setting Up the Server

2. Defining Routes

3. Creating Handler Functions

4. Sending Responses

Detailed Overview of a Simple HTTP Server with Multiple Routes

1. Server Setup:

2. Route Definition:

3. Handler Functions:

4. Response Handling:

4: Handling Different HTTP Methods

Understanding HTTP Methods for Web Development

1. GET Method

Usage:

2. POST Method

3. PUT Method

4. DELETE Method

Handling GET and POST Requests

1. Handling GET Requests:

2. Handling POST Requests:

Step 5: Working with Request Parameters

Understanding Query Parameters

How Query Parameters Are Handled

Example Workflow

1. Server Handling:

Handling Query Parameters in Practice

How to Test:

Form Data

Handling Form Submissions

Explanation:

1. Form Submission Method:

2. Parsing Form Data:

3. Retrieving Form Values:

4. Sending a Response:

Example Usage:

Step 1: Understanding the Basics of `net/http`

1. Default Multiplexer `(http.DefaultServeMux)`