DEV Community: Abhishek Sharma

What Happens When Your API Has 10,000 Rows? I Added Pagination and Caching to Find Out

Abhishek Sharma — Tue, 21 Apr 2026 11:10:13 +0000

In Part 4, I finished full CRUD and wrote my first Go tests. The API worked — but I was the only user, hitting it from my terminal with 10 test entries.

Then I asked: what happens when there are 10,000 rows?

Two days, two features. Both taught me things I didn't expect.

Day 16: Pagination

GET /entries was returning every row in the database for a user. Fine when I have 10 test entries. A disaster with 10,000.

Pagination is simple in principle — you add ?page=1&limit=10 to the URL and only fetch that slice. The implementation taught me something about Go's "fail gracefully" philosophy:

page := 1   // default
limit := 10 // default

pageStr := r.URL.Query().Get("page")
if pageStr != "" {
    if p, err := strconv.Atoi(pageStr); err == nil && p > 0 {
        page = p
    }
}

limitStr := r.URL.Query().Get("limit")
if limitStr != "" {
    if l, err := strconv.Atoi(limitStr); err == nil && l > 0 && l <= 100 {
        limit = l
    }
}

Notice what's NOT there: no 400 Bad Request if you pass ?page=abc. Invalid params just silently fall back to defaults. I went back and forth on this — should I return an error?

Decided no. Pagination params are optional hints, not required inputs. If you pass garbage, you get the first page. The API keeps working. This feels more correct for a read endpoint.

The database query uses LIMIT and OFFSET:

SELECT * FROM entries 
WHERE user_id = $1 
ORDER BY created_at DESC 
LIMIT $2 OFFSET $3

Where OFFSET = (page - 1) * limit. The response now includes total, page, limit, and entries — so clients can calculate how many pages exist.

Day 17: In-Memory Caching

Pagination meant a COUNT query on every GET request to return the total. SELECT COUNT(*) FROM entries WHERE user_id = ? is cheap with 10 rows, expensive at scale.

I built a simple in-memory cache:

type CacheEntry struct {
    value      interface{}
    Expiration time.Time
}

type Cache struct {
    data map[string]CacheEntry
    mu   sync.RWMutex  // ← this is the key part
}

func (c *Cache) Get(key string) (interface{}, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()

    entry, exists := c.data[key]
    if !exists || time.Now().After(entry.Expiration) {
        return nil, false
    }
    return entry.value, true
}

The sync.RWMutex was new to me. Regular Mutex blocks everything — only one goroutine at a time. RWMutex is smarter: multiple goroutines can read simultaneously, but writing requires exclusive access.

For a cache that's read far more often than written, this matters.

Cache invalidation: when a user creates or deletes an entry, I delete their cached count:

cache.Delete(fmt.Sprintf("count:user:%d", userID))

The cache key includes the user ID so different users never see each other's counts. Simple, but it took me a few minutes to think through why I needed that.

What I Learned

Pagination defaults beat errors. For optional hints like page and limit, failing gracefully is better UX than returning a 400. Save strict validation for required inputs.

sync.RWMutex vs sync.Mutex. Read-heavy data structures should use RWMutex. Multiple goroutines can read simultaneously — only writes need exclusive access.

Cache keys need scope. count:user:42 not just count. Otherwise all users share the same cached value — a subtle bug that only shows up with multiple users.

The API Now

GET /entries?page=1&limit=10   → paginated, cached COUNT
POST /entries                  → creates entry, invalidates cache
DELETE /entries?id=X           → deletes entry, invalidates cache

The API no longer dumps every row on every request. The database isn't hit for the count on repeated reads. Small changes, but the kind that matter when traffic is real.

What's Next

In Part 6, I'll cover rate limiting and Redis — the week I started thinking about abuse prevention and why in-memory solutions break the moment you run more than one server instance.

This is Part 5 of the "Learning Go in Public" series. Part 1 | Part 2 | Part 3 | Part 4

Tests, UPDATE, DELETE — And the Refactor I Didn't Plan

Abhishek Sharma — Mon, 20 Apr 2026 11:04:33 +0000

In Part 3, I built authentication — JWT tokens, bcrypt hashing, middleware that wraps handlers like Russian dolls. The API had four endpoints and was fully protected.

But it could only create and read entries. No updating. No deleting. And zero tests.

This post is about the week I added the missing CRUD operations, wrote my first Go tests, and accidentally refactored the entire project structure — all because one test file exposed a design flaw I couldn't unsee.

UPDATE: Harder Than I Expected

Adding a PATCH endpoint sounded simple. It wasn't. The tricky part wasn't the database query — it was ownership validation.

When a user sends PATCH /entries?id=5, I can't just update entry 5. I need to verify that entry 5 belongs to this user. Otherwise any authenticated user could edit anyone's entries.

Here's the handler:

func UpdateEntry(w http.ResponseWriter, r *http.Request) {
    // Parse entry ID from query string
    entryId, err := strconv.Atoi(r.URL.Query().Get("id"))

    // Get user ID from context (set by AuthMiddleware)
    userID := r.Context().Value("user_id").(int64)

    // Validate all fields...
    if req.Text == "" { /* 400 */ }
    if req.Mood < 1 || req.Mood > 10 { /* 400 */ }

    // The key line — WHERE clause checks BOTH id AND user_id
    rowsAffected, err := db.UpdateEntry(ctx, entryId, userID, 
        req.Text, req.Mood, req.Category)

    if rowsAffected == 0 {
        // Entry doesn't exist OR doesn't belong to this user
        errorResponse(w, http.StatusNotFound, 
            "Entry not found or access denied")
        return
    }
}

The database query uses WHERE id = ? AND user_id = ?. If the entry exists but belongs to someone else, rowsAffected is 0. Same response as "entry doesn't exist." This is intentional — you don't want to leak information about other users' data.

I wrote an 8-test PowerShell script to verify every edge case: update your own entry, try to update someone else's, update with missing fields, update with mood out of range. All passing.

DELETE: The Same Pattern, Simpler

Once UPDATE worked, DELETE took 20 minutes. Same ownership pattern:

func DeleteEntry(w http.ResponseWriter, r *http.Request) {
    entryId, _ := strconv.Atoi(r.URL.Query().Get("id"))
    userID := r.Context().Value("user_id").(int64)

    rowsAffected, err := db.DeleteEntry(ctx, entryId, userID)

    if rowsAffected == 0 {
        errorResponse(w, http.StatusNotFound, 
            "Entry not found or access denied")
        return
    }

    respondJSON(w, http.StatusOK, CreateEntryResponse{
        Success: true,
        Message: "Entry deleted successfully",
    })
}

Same WHERE id = ? AND user_id = ?. Same ownership check. Same ambiguous error message. I didn't realize it at the time, but this was my first Go pattern — I was copying the structure from UPDATE and it just worked.

Seven tests. All green.

The Accidental Refactor

Here's where things got interesting. I was writing tests when I noticed something ugly: my models/entry.go had database functions mixed in with struct definitions. The Entry struct and InsertEntry() were in the same file.

models/
  entry.go    ← struct definitions AND database functions??
  models.go   ← more structs

This was wrong. The whole point of separating models/ from db/ is separation of concerns. Models define what data looks like. DB defines how it's stored and retrieved.

So I refactored:

models/
  models.go   ← ALL struct definitions (Entry, User, requests, responses)
db/
  db.go       ← ALL database operations (Insert, Update, Delete, Get)

I moved every database function from models/entry.go into db/db.go. Deleted the old file. Updated all imports.

This wasn't planned. It happened because writing tests forced me to think about where things belong. When you import a package for testing, messy boundaries become obvious.

My First Real Tests

I had been testing with PowerShell scripts — curl-style commands that hit a running server. Those are integration tests. Useful, but slow and fragile.

Go has testing and httptest built into the standard library. No Jest, no Mocha, no test runner to install. You just:

Create a file ending in _test.go
Write functions starting with Test
Run go test

Here's my first handler test:

func TestCreateEntry(t *testing.T) {
    body := strings.NewReader(
        `{"text":"feeling good","mood":8,"category":"mood"}`,
    )

    // Create a fake HTTP request
    req := httptest.NewRequest(http.MethodPost, "/entries", body)

    // Inject user_id into context (normally AuthMiddleware does this)
    ctx := context.WithValue(req.Context(), "user_id", int64(1))
    req = req.WithContext(ctx)

    // Record the response
    rec := httptest.NewRecorder()

    // Call the handler directly — no server needed
    CreateEntry(rec, req)

    // Assert
    if rec.Code != http.StatusCreated {
        t.Errorf("expected 201, got %d", rec.Code)
    }
}

Two things blew my mind:

httptest.NewRequest — you create a fake HTTP request with any method, URL, and body. No actual network call. No server running. It's just a struct.

httptest.NewRecorder — captures whatever the handler writes. Status code, headers, body. You inspect it after the handler returns.

The test for invalid input was almost as satisfying:

func TestCreateEntry_MissingText(t *testing.T) {
    body := strings.NewReader(`{"text":"","mood":8,"category":"mood"}`)
    req := httptest.NewRequest(http.MethodPost, "/entries", body)
    ctx := context.WithValue(req.Context(), "user_id", int64(1))
    req = req.WithContext(ctx)
    rec := httptest.NewRecorder()

    CreateEntry(rec, req)

    if rec.Code != http.StatusBadRequest {
        t.Errorf("expected 400, got %d", rec.Code)
    }
}

Empty text → 400. Invalid mood → 400. Missing auth → 401. Each scenario is three lines of setup, one function call, one assertion.

Coming from JavaScript testing where you install Jest, configure Babel, mock fetch, set up test databases... Go's approach felt almost too simple. But it works.

What I Learned This Week

The ownership pattern is reusable. WHERE id = ? AND user_id = ? with rowsAffected == 0 handles both "not found" and "not yours" in one query. I've used this pattern three times now (GET, UPDATE, DELETE) and it's always the same.

Refactoring happens when you test. I didn't plan to restructure the project. But the moment I tried to write a test that imported models, the messy boundaries became obvious. Tests are a design feedback tool, not just a verification tool.

Go testing is minimal and that's the point. No assertions library. No mocking framework. Just if got != want { t.Errorf() }. It forces you to write tests that are readable without any DSL knowledge.

Where the API Stands Now

POST   /register       → Create account (public)
POST   /login          → Get JWT token (public)
POST   /entries        → Create entry (protected)
GET    /entries        → List entries (protected)
PATCH  /entries?id=X   → Update entry (protected + ownership)
DELETE /entries?id=X   → Delete entry (protected + ownership)
GET    /health         → Health check (public)

Six real endpoints. Full CRUD. Authentication. Authorization with ownership validation. 18 tests passing. And a project structure that finally makes sense.

What's Next

In Part 5, I'll cover the week I added pagination, caching, and rate limiting — the features that made me think about what happens when this API isn't just me hitting it from PowerShell anymore.

This is Part 4 of the "Learning Go in Public" series. Part 1 | Part 2 | Part 3

Building Authentication From Scratch in Go — No Libraries, No Magic

Abhishek Sharma — Fri, 17 Apr 2026 13:18:54 +0000

In Part 2, I had a working REST API with two endpoints. You could create entries and query them. But anyone could hit the API — no login, no tokens, no protection.

This post is about the day I decided to build authentication from scratch, and the Go pattern that changed how I think about HTTP servers.

The Plan

I needed three things:

Register — hash a password, save the user
Login — verify credentials, return a JWT token
Middleware — block unauthenticated requests before they reach any handler

No auth libraries. No Passport.js equivalent. Just golang-jwt/jwt for token creation and golang.org/x/crypto/bcrypt for password hashing.

Registration: My First Time Hashing a Password

Here's what the register handler looked like:

func Register(w http.ResponseWriter, r *http.Request) {
    var req RegisterRequest
    json.NewDecoder(r.Body).Decode(&req)

    // Validate
    if req.Email == "" { /* 400 */ }
    if !strings.Contains(req.Email, "@") { /* 400 */ }
    if len(req.Password) < 6 { /* 400 */ }

    // Hash password — NEVER store plain text
    passwordHash, err := bcrypt.GenerateFromPassword(
        []byte(req.Password), bcrypt.DefaultCost,
    )

    // Save to database
    userID, err := db.CreateUser(req.Email, string(passwordHash))
}

Two things I learned here:

bcrypt.DefaultCost is 10. That means it runs the hashing algorithm 2^10 = 1,024 times. Slow on purpose — makes brute-force attacks impractical. I spent 20 minutes reading about why a slower hash function is a feature, not a bug.

[]byte() everywhere. bcrypt's functions take byte slices, not strings. Coming from JavaScript where everything is just a string, I kept forgetting to convert. Go makes you think about data types at every step.

Login: Creating My First JWT

The login flow taught me more about Go than any tutorial:

// 1. Get user from database
userID, passwordHash, err := db.GetUserByEmail(req.Email)

// 2. Compare password with stored hash
err = bcrypt.CompareHashAndPassword(
    []byte(passwordHash), []byte(req.Password),
)

// 3. Create JWT claims
claims := jwt.MapClaims{
    "user_id": userID,
    "exp":     time.Now().Add(24 * time.Hour).Unix(),
}

// 4. Sign the token
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
tokenString, err := token.SignedString([]byte(secret))

I left this comment in my code at the time:

// Why Unix()? JWT needs simple numbers, not complex Go time objects
// Example: time.Now().Unix() = 1736359530 (just a number)
// Add 24 hours = add 86400 seconds (24 * 60 * 60 = 86400)

Again — verbose, maybe obvious to experienced devs. But I was explaining JWT to myself while building it. That's the whole point of learning in public.

One security detail I got right: the error message for a wrong password is "Invalid email or password" — same as for a non-existent email. You never want to reveal whether an account exists.

The Middleware Pattern That Changed Everything

This is the part I'm most proud of from this phase. Go doesn't have middleware built in like Express. You build it yourself:

func AuthMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        // 1. Get token from "Authorization: Bearer <token>"
        authHeader := r.Header.Get("Authorization")
        tokenString := strings.TrimPrefix(authHeader, "Bearer ")

        // 2. Validate token
        claims, err := validateToken(tokenString)
        if err != nil {
            errorResponseAuth(w, http.StatusUnauthorized, "Invalid token")
            return
        }

        // 3. Extract user_id and add to request context
        userID := claims["user_id"].(float64)
        ctx := context.WithValue(r.Context(), "user_id", int64(userID))

        // 4. Call next handler with updated context
        next(w, r.WithContext(ctx))
    }
}

Read that again. A function that takes a handler and returns a new handler. The returned handler does the auth check first, and only calls the original handler if the token is valid.

In main.go, using it looks like this:

// Public routes — no protection
http.HandleFunc("/register", handlers.Register)
http.HandleFunc("/login", handlers.Login)

// Protected route — wrapped with AuthMiddleware
http.HandleFunc("/entries", handlers.AuthMiddleware(func(w http.ResponseWriter, r *http.Request) {
    if r.Method == http.MethodPost {
        handlers.CreateEntry(w, r)
    } else if r.Method == http.MethodGet {
        handlers.GetEntries(w, r)
    }
}))

AuthMiddleware(handler) — that's it. One wrapper function. No framework, no plugin system, no decorator syntax. Just a function wrapping another function.

This is the moment Go clicked for me at a deeper level. Functions are values. You can pass them around, wrap them, chain them. Middleware isn't a framework feature — it's just how functions work.

The `context.WithValue` Trick

The most clever part of Go's auth pattern: how you pass the user ID from middleware to the handler.

// Middleware sets it:
ctx := context.WithValue(r.Context(), "user_id", int64(userID))
next(w, r.WithContext(ctx))

// Handler reads it:
userID := r.Context().Value("user_id").(int64)

No global variables. No session objects. The user ID travels with the request itself. Every handler that needs to know who's making the request just reads it from the context.

Coming from Express where you'd do req.user = decoded, this felt more explicit and safer. The data is scoped to the request, not bolted onto a mutable object.

One Thing That Tripped Me Up

JWT numbers come back as float64, not int64. This line:

userID, ok := claims["user_id"].(float64)

I originally wrote .(int64) and couldn't figure out why it kept failing. Turns out JSON (which JWT uses internally) doesn't distinguish between integers and floats — everything is a number. Go's JSON decoder maps all numbers to float64.

Took me an hour of debugging. Now I'll never forget it.

What the API Looked Like After This

POST /register  → Create account (public)
POST /login     → Get JWT token (public)
POST /entries   → Create entry (protected)
GET  /entries   → List entries (protected)
GET  /health    → Health check (public)
GET  /ping      → Ping (public)

Four real endpoints. Authentication. Authorization. No frameworks. Just Go's standard library plus two packages for JWT and bcrypt.

What's Next

In Part 4, I'll cover the week I added testing, UPDATE, and DELETE — and why writing tests after the code changed how I thought about designing handlers.

This is Part 3 of the "Learning Go in Public" series. Part 1 | Part 2

I Stopped Watching Tutorials and Started Building a REST API in Go

Abhishek Sharma — Thu, 16 Apr 2026 13:32:21 +0000

In my last post, I talked about my first week learning Go — the confusion, the messy first commit, and why I picked Go over sticking with JavaScript.

This post is about the moment things changed: I stopped writing practice files and started building a real project.

The Decision

After a week of writing structs.go, maps-practice.go, and interfaces-tutorial.go, I was learning syntax but not learning to build. I could explain what a goroutine is but couldn't wire up an HTTP endpoint.

So I picked a project: a personal analytics backend. A REST API where I could log daily entries — mood, productivity notes, whatever — and query them later. Simple enough to be achievable, real enough to force me to learn.

Day 1: The Skeleton

My first backend commit had just 3 files that mattered:

cmd/server/main.go — the entry point:

func main() {
    err := godotenv.Load()
    if err != nil {
        log.Println("No .env file found")
    }

    dbPath := os.Getenv("DB_PATH")
    if dbPath == "" {
        dbPath = "./data.db"
    }
    err = db.InitDB(dbPath)
    if err != nil {
        log.Fatalf("Failed to initialize database: %v", err)
    }
    defer db.CloseDB()

    http.HandleFunc("/health", handlers.HealthHandler)
    http.HandleFunc("/ping", handlers.PingHandler)

    log.Printf("Server starting on port %s", port)
    http.ListenAndServe(":"+port, nil)
}

Two endpoints. /health returns "ok". /ping returns the current time. That's it. That was my entire backend.

But here's what I learned just from this:

http.HandleFunc registers a function to a URL path — Go's router is that simple
http.ListenAndServe blocks and listens forever — no framework needed
defer db.CloseDB() — Go's defer runs when the function exits, perfect for cleanup

internal/db/db.go — database connection:

I used SQLite because it's a single file — no Docker, no Postgres setup, no connection strings. Just ./data.db.

func InitDB(path string) error {
    var err error
    DB, err = sql.Open("sqlite", path)
    if err != nil {
        return fmt.Errorf("failed to open database: %w", err)
    }
    // Create tables
    _, err = DB.Exec(`CREATE TABLE IF NOT EXISTS entries (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        user_id INTEGER NOT NULL,
        text TEXT NOT NULL,
        mood INTEGER CHECK(mood >= 1 AND mood <= 10),
        created_at DATETIME DEFAULT CURRENT_TIMESTAMP
    )`)
    return err
}

The %w in fmt.Errorf wraps the original error — you can unwrap it later. I didn't understand why this mattered until weeks later when I needed to check error types.

Day 2: The First Real Endpoint

This is where it clicked. I wrote POST /entries — my first handler that actually does something:

func CreateEntry(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodPost {
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
        return
    }

    var req CreateEntryRequest
    err := json.NewDecoder(r.Body).Decode(&req)
    if err != nil {
        respondJSON(w, http.StatusBadRequest, CreateEntryResponse{
            Success: false,
            Message: "Invalid request body",
        })
        return
    }

    // Validate: user_id > 0, text not empty, mood 1-10
    if req.UserID <= 0 { /* return 400 */ }
    if req.Text == "" { /* return 400 */ }
    if req.Mood < 1 || req.Mood > 10 { /* return 400 */ }

    // Insert into database
    id, err := db.InsertEntry(req.UserID, req.Text, req.Mood)
    if err != nil {
        respondJSON(w, http.StatusInternalServerError, CreateEntryResponse{
            Success: false,
            Message: "Failed to create entry",
        })
        return
    }

    respondJSON(w, http.StatusCreated, CreateEntryResponse{
        Success: true,
        Message: "Entry created",
        ID:      id,
    })
}

Look at the pattern: validate → process → respond. Early returns everywhere. No nesting. No else blocks. If something's wrong, respond with an error and return immediately.

This is the Go way, and it's brilliant. Coming from JavaScript where I'd chain .then().catch() or wrap everything in try/catch, this felt refreshing. Every failure point is explicit.

What I Learned About `http.ResponseWriter` vs `*http.Request`

This confused me for days. Why is w not a pointer but r is?

*http.Request is a pointer to a struct — it's huge (headers, URL, cookies, body). Copying it would be wasteful.
http.ResponseWriter is an interface. In Go, interfaces are already a small wrapper that points to the real data. You don't need a pointer to a pointer.

The rule I learned: If you see a type without `` but you can still call methods that modify things, it's probably an interface.*

The Comments I Left for Myself

My code from this commit is packed with comments like:

// "Read the JSON data from the request and put it into our req variable."
// Step-by-step:
// r.Body = the data the client sent
// json.NewDecoder(r.Body) = create a JSON reader
// .Decode(&req) = convert JSON into our struct

These comments are verbose and probably "wrong" by clean code standards. But they're exactly what I needed at the time — explanations in my own words, written while the concept was clicking.

I'm keeping them. They're documentation of learning, not documentation of code.

The Moment It Felt Real

I ran go run cmd/server/main.go, opened another terminal, and typed:

curl -X POST http://localhost:8080/entries \
  -H "Content-Type: application/json" \
  -d '{"user_id": 1, "text": "First entry!", "mood": 8}'

And got back:

{"success": true, "message": "Entry created", "id": 1}

Data went into a real database. I could query it back with GET /entries. It was two endpoints and a SQLite file, but it was mine. I built it with zero frameworks, just Go's standard library.

That's when Go stopped being a language I was studying and became a tool I was building with.

What's Next

In Part 3, I'll cover the scariest part of this project: adding authentication from scratch. JWT tokens, bcrypt password hashing, and the middleware pattern that changed how I think about HTTP — all without a single auth library.

This is Part 2 of the "Learning Go in Public" series. Part 1 is here.

Why I Decided to Learn Go — And What My First Commit Looked Like

Abhishek Sharma — Fri, 03 Apr 2026 13:58:53 +0000

On November 5, 2025, I pushed my first commit to a repo called Go_learn.

The commit message: "Started learning Go lang scratch lessons."

54 files. 5,365 lines. Variables, loops, structs, maps, goroutines, interfaces — everything I'd learned in a week, all dumped into one massive push because I didn't know any better.

That repo is still public. The messy files are still there. And this is the first post in a series where I'm going to walk through every stage of what happened next.

Why Go?

I was coming from JavaScript and the MERN stack. I could build things. But I kept hitting a wall — I didn't truly understand what was happening under the hood. Express hides the HTTP details. Mongoose hides the database details. npm hides... everything.

I wanted a language that would force me to understand things, not abstract them away.

Go kept showing up. Backend roles I was interested in listed it. The standard library supposedly had everything you needed. No frameworks, no magic. And the syntax looked almost too simple to be real.

So I opened VS Code and typed:

package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

And immediately got confused.

The First Week: Where's My Semicolons?

Coming from JavaScript, Go felt alien. Some things that tripped me up in the first few days:

Exported vs unexported names. I spent an embarrassing amount of time wondering why myVariable in one file wasn't accessible from another. In Go, only names starting with a capital letter are exported. In JavaScript, everything is just... there.

No classes. Go has structs and methods, but no inheritance. I kept trying to think in OOP patterns and Go kept saying "no, just use composition." It took a while to stop fighting it.

Error handling everywhere. My first Go functions looked like this:

result, err := someFunction()
if err != nil {
    fmt.Println("something went wrong:", err)
    return
}

I wrote if err != nil about 200 times that first week. It felt tedious. (Spoiler for a future post: I now think it's one of Go's best features.)

No generics... then generics. I learned Go right after generics were added, but every tutorial and StackOverflow answer was from the pre-generics era. Confusing when you're starting out.

What My First Commit Actually Contained

I organized my learning into numbered folders:

01-basics/         → hello.go, types.go, functions.go
02-control-flow/   → loops.go, switch.go
03-data-structures → structs.go, maps.go, interfaces.go
05-concurrency/    → goroutines-basic.go, channels-basic.go, worker-pool.go
06-projects/       → number-guessing-game.go, todo-list.go
07-Pointers/       → pointers.go, nil-pointers-explained.go
08-errors/         → errors.go
09-packages/       → go modules guide

Yes, I skipped folder 04. No, I don't know why. It's still missing.

Every file is packed with comments — I was essentially writing tutorials for myself. Here's an actual snippet from structs.go:

// Structs are like blueprints for creating custom types
// Think of them like objects in JavaScript, but typed and explicit
type Person struct {
    Name string
    Age  int
}

These files are messy, verbose, and sometimes wrong. I'm keeping every single one of them in the repo. They're the proof that I started from zero.

The Moment It Clicked

By the end of week one, I built two small projects: a number guessing game and a CLI todo list. Neither is impressive. But writing them forced me to combine everything — structs, slices, loops, user input, error handling — into something that actually ran.

That's when Go stopped feeling like syntax to memorize and started feeling like a tool I could build with.

What's Coming Next

In the next post, I'll talk about the decision that accelerated everything: stopping the tutorials and building a real backend project. I started a personal analytics REST API using only Go's standard library — no gin, no fiber, no frameworks. Just net/http, database/sql, and a lot of if err != nil.

Follow along — I'll be posting each stage of this journey as its own article. The messy commits, the breakthroughs, the mistakes. All of it.

This is Part 1 of the "Learning Go in Public" series.

DEV Community: Abhishek Sharma

What Happens When Your API Has 10,000 Rows? I Added Pagination and Caching to Find Out

Day 16: Pagination

Day 17: In-Memory Caching

What I Learned

The API Now

What's Next

Tests, UPDATE, DELETE — And the Refactor I Didn't Plan

UPDATE: Harder Than I Expected

DELETE: The Same Pattern, Simpler

The Accidental Refactor

My First Real Tests

What I Learned This Week

Where the API Stands Now

What's Next

Building Authentication From Scratch in Go — No Libraries, No Magic

The Plan

Registration: My First Time Hashing a Password

Login: Creating My First JWT

The Middleware Pattern That Changed Everything

The context.WithValue Trick

One Thing That Tripped Me Up

What the API Looked Like After This

What's Next

I Stopped Watching Tutorials and Started Building a REST API in Go

The Decision

Day 1: The Skeleton

Day 2: The First Real Endpoint

What I Learned About http.ResponseWriter vs *http.Request

The Comments I Left for Myself

The Moment It Felt Real

What's Next

Why I Decided to Learn Go — And What My First Commit Looked Like

Why Go?

The First Week: Where's My Semicolons?

What My First Commit Actually Contained

The Moment It Clicked

What's Coming Next

The `context.WithValue` Trick

What I Learned About `http.ResponseWriter` vs `*http.Request`