DEV Community: Harry Douglas

OverlayFS — The Magic Behind Docker

Harry Douglas — Mon, 29 Sep 2025 15:47:48 +0000

Docker’s efficiency comes from a Linux kernel feature called OverlayFS. It allows multiple directories (called layers) to be combined into a single merged view. This is how Docker can reuse common image layers (Ubuntu, Alpine, etc.) across many containers, while giving each container its own writable layer.

In this tutorial, we’ll recreate Docker’s storage trick with a few simple commands.

🔹 Step 1: Setup directories

Create a playground with 4 directories:

mkdir overlayfs
cd overlayfs
mkdir -p lower upper work merged

lower/ → base read-only layer (like Docker image layers)
upper/ → writable layer (container changes go here)
work/ → internal work area (needed by OverlayFS)
merged/ → final view (what the container “sees”)

🔹 Step 2: Add a file in the lower layer

echo "hello from lower" > lower/file1.txt

Check:

ls lower
# file1.txt

🔹 Step 3: Mount OverlayFS

Now mount the union filesystem:

sudo mount -t overlay overlay \
  -o lowerdir=./lower,upperdir=./upper,workdir=./work \
  ./merged

Check the merged view:

ls merged
# file1.txt
cat merged/file1.txt
# hello from lower

🔹 Step 4: Create a new file in the merged layer

echo "hello from upper" > merged/file2.txt

Now inspect:

ls lower    # still file1.txt
ls upper    # now has file2.txt
ls merged   # file1.txt + file2.txt

👉 New files go to upper.

🔹 Step 5: Modify an existing file (Copy-on-Write)

echo "changed in merged" > merged/file1.txt

Inspect again:

cat lower/file1.txt   # still "hello from lower"
cat upper/file1.txt   # now "changed in merged"

👉 The file was copied from lower to upper, then modified = copy-on-write.

🔹 Step 6: Delete a file

rm merged/file1.txt

Now:

ls merged   # only file2.txt
ls lower    # still has file1.txt
ls upper    # contains a "whiteout" marker

👉 OverlayFS hides lower’s file1.txt using a special whiteout file.

🔹 Step 7: Unmount

When done, unmount:

sudo umount merged

The merged view disappears, but the lower/upper directories still contain their raw files.

🔹 Key Takeaways

Lowerdir = base image layers (read-only)
Upperdir = writable container layer
Workdir = bookkeeping area for OverlayFS
Merged = what the container sees
Copy-on-Write = changes to lower files go into upper
Whiteouts = hide deleted files from lower

✅ And that’s it — you’ve just reproduced Docker’s storage mechanism by hand!

Centralized Error Handling in Go (Like Laravel)

Harry Douglas — Fri, 29 Aug 2025 08:53:42 +0000

When building an API in Go, you may notice you keep writing this kind of code everywhere:

if email == "" {
    validationError := responses.Response{
        Code:    422,
        Message: "Invalid email",
    }
    w.WriteHeader(http.StatusUnprocessableEntity)
    json.NewEncoder(w).Encode(validationError)
    return
}

This gets repetitive, messy, and hard to manage as your project grows.

If you're coming from Laravel, you're used to something like throw new Exception(...), and having Laravel automatically return a proper JSON response.

In Go, you can achieve the same thing using:

A custom error type
Middleware
panic() + recover()

Let’s build it together 👇

✅ Goal

Stop repeating the same error-handling code
Throw errors in one line
Always return a clean JSON response
Centralize the logic in one place

✅ Step 1: Define a Common Error Response Format

Create a file like responses/Response.go:

package responses

type Response struct {
    Code    int    `json:"code"`
    Message string `json:"message"`
}

This is what your API will return to the client.

✅ Step 2: Create Custom Error Types

In exceptions/ApiError.go, define your custom error structure:

package exceptions

import "net/http"

type APIError struct {
    Code    int
    Message string
}

func (e APIError) Error() string {
    return e.Message
}

Also add helper functions for common error types:

func NotFound(message string) APIError {
    return APIError{Code: http.StatusNotFound, Message: message}
}

func Unprocessable(message string) APIError {
    return APIError{Code: http.StatusUnprocessableEntity, Message: message}
}

Now, you can easily throw:

panic(exceptions.Unprocessable("Email is required"))

✅ Step 3: Global Middleware to Catch Panics and Return JSON

Create a recovery middleware:

package middleware

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

    "yourapp/exceptions"
    "yourapp/responses"
)

func RecoveryMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if rec := recover(); rec != nil {
                code := http.StatusInternalServerError
                message := "Internal Server Error"

                if apiErr, ok := rec.(exceptions.APIError); ok {
                    code = apiErr.Code
                    message = apiErr.Message
                }

                w.Header().Set("Content-Type", "application/json")
                w.WriteHeader(code)
                json.NewEncoder(w).Encode(responses.ErrorResponse{
                    Code:    code,
                    Message: message,
                })
            }
        }()

        next.ServeHTTP(w, r)
    })
}

Now, all panics will be caught and turned into clean JSON.

✅ Step 4: Use the Middleware in `main.go`

package main

import (
    "net/http"
    "yourapp/handlers/auth"
    "yourapp/middleware"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/auth/email", auth.EmailHandler)

    http.ListenAndServe(":8080", middleware.RecoveryMiddleware(mux))
}

✅ Step 5: Throw Errors in Your Handler Instead of Writing Response Code

Old way (repetitive):

if email == "" {
    w.WriteHeader(http.StatusUnprocessableEntity)
    json.NewEncoder(w).Encode(responses.ErrorResponse{
        Code: 422,
        Message: "Email is required",
    })
    return
}

New way (cleaner):

if email == "" {
    panic(exceptions.Unprocessable("Email is required"))
}

That’s it!

✅ Example Output

If the user submits an empty email, they will get:

{
  "code": 422,
  "message": "Email is required"
}

This approach gives you Laravel-style centralized error handling in Go.

Instead of repeating this everywhere:

w.WriteHeader(...)
json.NewEncoder(w).Encode(...)

You just call:

panic(exceptions.Unprocessable("message"))

And let your middleware handle the rest. Clean, consistent, and scalable.

Api Requests and Validators in Go

Harry Douglas — Sat, 12 Jul 2025 17:40:31 +0000

I know there are hundreds of ways to implement it better but for learning purposes I wrote a simple request and validator mechanism here in this commit:

https://github.com/hrrydgls/snug/commit/ca07cdfd38828de8901a6b7bdfdf0e35fa6e2d88

It is gonna be better for sure in future but for now I just wanted to keep it simple and clean.

What I did is simple. First I created a package named requests with this struct:

package requests 

type RegisterRequest struct {
    Email string `json:"email"`
    Name string `json:"name"`
    Password string `json:"password"`
}

Then another package named validators and a new validator inside it:

package validators

import (
    "net/mail"

    "github.com/hrrydgls/snug/exceptions"
    "github.com/hrrydgls/snug/requests"
)

func RegisterValidator (registerRequest *requests.RegisterRequest) error {
    if _, error := mail.ParseAddress(registerRequest.Email); error != nil {
        panic(exceptions.Unprocessable("Email is required!"))
    }

    if len(registerRequest.Name) < 3 {
        panic(exceptions.Unprocessable("Name should be at least 3 characters!"))
    }

    if len(registerRequest.Password) < 6 {
        panic(exceptions.Unprocessable("Password should be at least 6 characters!"))
    }

    return nil
}

And finally I used this request and validator in my handler like this:

package auth

import (
    "net/http"

    "github.com/hrrydgls/snug/requests"
    "github.com/hrrydgls/snug/validators"
)

func (handler *Handler) Register(w http.ResponseWriter, r *http.Request) {

    r.ParseForm()

    email := r.FormValue("email")
    name := r.FormValue("name")
    password := r.FormValue("password")


    registerRequest := requests.RegisterRequest {
        Email: email,
        Name: name,
        Password: password,
    }

    validators.RegisterValidator(&registerRequest)

}

I know there are better packages like go-playground/validator that I could use it but I wanted to suffer a bit before using these already working packages :)

As someone from PHP world, I feel better with Golang types... In Laravel we had Requests but while referencing them, you had no idea if this field exist in the request or not. It was not intelligence enough! Everytime I had to go back to request to see if the field exists or not.

I don't wanna complain more about PHP. It is a old language and still alive but I just feel better with this :)

Enjoy!

Centralized Error Handling in Go (Like Laravel)

Harry Douglas — Wed, 09 Jul 2025 08:50:51 +0000

When building an API in Go, you may notice you keep writing this kind of code everywhere:

if email == "" {
    validationError := responses.Response{
        Code:    422,
        Message: "Invalid email",
    }
    w.WriteHeader(http.StatusUnprocessableEntity)
    json.NewEncoder(w).Encode(validationError)
    return
}

This gets repetitive, messy, and hard to manage as your project grows.

If you're coming from Laravel, you're used to something like throw new Exception(...), and having Laravel automatically return a proper JSON response.

In Go, you can achieve the same thing using:

A custom error type
Middleware
panic() + recover()

Let’s build it together 👇

✅ Goal

Stop repeating the same error-handling code
Throw errors in one line
Always return a clean JSON response
Centralize the logic in one place

✅ Step 1: Define a Common Error Response Format

Create a file like responses/Response.go:

package responses

type Response struct {
    Code    int    `json:"code"`
    Message string `json:"message"`
}

This is what your API will return to the client.

✅ Step 2: Create Custom Error Types

In exceptions/ApiError.go, define your custom error structure:

package exceptions

import "net/http"

type APIError struct {
    Code    int
    Message string
}

func (e APIError) Error() string {
    return e.Message
}

Also add helper functions for common error types:

func NotFound(message string) APIError {
    return APIError{Code: http.StatusNotFound, Message: message}
}

func Unprocessable(message string) APIError {
    return APIError{Code: http.StatusUnprocessableEntity, Message: message}
}

Now, you can easily throw:

panic(exceptions.Unprocessable("Email is required"))

✅ Step 3: Global Middleware to Catch Panics and Return JSON

Create a recovery middleware:

package middleware

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

    "yourapp/exceptions"
    "yourapp/responses"
)

func RecoveryMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if rec := recover(); rec != nil {
                code := http.StatusInternalServerError
                message := "Internal Server Error"

                if apiErr, ok := rec.(exceptions.APIError); ok {
                    code = apiErr.Code
                    message = apiErr.Message
                }

                w.Header().Set("Content-Type", "application/json")
                w.WriteHeader(code)
                json.NewEncoder(w).Encode(responses.ErrorResponse{
                    Code:    code,
                    Message: message,
                })
            }
        }()

        next.ServeHTTP(w, r)
    })
}

Now, all panics will be caught and turned into clean JSON.

✅ Step 4: Use the Middleware in `main.go`

package main

import (
    "net/http"
    "yourapp/handlers/auth"
    "yourapp/middleware"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/auth/email", auth.EmailHandler)

    http.ListenAndServe(":8080", middleware.RecoveryMiddleware(mux))
}

✅ Step 5: Throw Errors in Your Handler Instead of Writing Response Code

Old way (repetitive):

if email == "" {
    w.WriteHeader(http.StatusUnprocessableEntity)
    json.NewEncoder(w).Encode(responses.ErrorResponse{
        Code: 422,
        Message: "Email is required",
    })
    return
}

New way (cleaner):

if email == "" {
    panic(exceptions.Unprocessable("Email is required"))
}

That’s it!

✅ Example Output

If the user submits an empty email, they will get:

{
  "code": 422,
  "message": "Email is required"
}

This approach gives you Laravel-style centralized error handling in Go.

Instead of repeating this everywhere:

w.WriteHeader(...)
json.NewEncoder(w).Encode(...)

You just call:

panic(exceptions.Unprocessable("message"))

And let your middleware handle the rest. Clean, consistent, and scalable.

How OOP works in Golang

Harry Douglas — Wed, 02 Jul 2025 15:37:37 +0000

I'm quite beginner here in GO but I wanna share what I've learnt about it today! Lets start without losing time. If you are coming from another OOP friendly language, you already know what is a class.
In Go we have the same thing but a bit different:

type Animal struct {
    Name string
}

This is the most basic class we have. Then we can add methods to it:

func (Animal) fly(){
    fmt.Println("Flying...")
}

The syntax seems a bit complicate to me as someone from PHP world but not too bad!

Share your comments with me to feel that I am not alone here with this new stuff :)

DEV Community: Harry Douglas

OverlayFS — The Magic Behind Docker

🔹 Step 1: Setup directories

🔹 Step 2: Add a file in the lower layer

🔹 Step 3: Mount OverlayFS

🔹 Step 4: Create a new file in the merged layer

🔹 Step 5: Modify an existing file (Copy-on-Write)

🔹 Step 6: Delete a file

🔹 Step 7: Unmount

🔹 Key Takeaways

Centralized Error Handling in Go (Like Laravel)

✅ Goal

✅ Step 1: Define a Common Error Response Format

✅ Step 2: Create Custom Error Types

✅ Step 3: Global Middleware to Catch Panics and Return JSON

✅ Step 4: Use the Middleware in main.go

✅ Step 5: Throw Errors in Your Handler Instead of Writing Response Code

✅ Example Output

Api Requests and Validators in Go

Centralized Error Handling in Go (Like Laravel)

✅ Goal

✅ Step 1: Define a Common Error Response Format

✅ Step 2: Create Custom Error Types

✅ Step 3: Global Middleware to Catch Panics and Return JSON

✅ Step 4: Use the Middleware in main.go

✅ Step 5: Throw Errors in Your Handler Instead of Writing Response Code

✅ Example Output

How OOP works in Golang

✅ Step 4: Use the Middleware in `main.go`

✅ Step 4: Use the Middleware in `main.go`