DEV Community: mihir mohapatra

FastAPI Crash Course: Build a CRUD REST API in ~40 Lines of Python

mihir mohapatra — Sun, 28 Jun 2026 09:38:51 +0000

I spend most of my days writing Java and Kotlin for FinTech systems at scale. But every now and then, Python pulls me back in — and FastAPI is exactly the reason why. This is a hands-on crash course based on a project I published on GitHub.

👉 View the full source on GitHub

Why FastAPI?

Coming from a Spring Boot background, my first instinct was scepticism. Another Python framework? But FastAPI is genuinely different:

Automatic interactive docs via Swagger UI — no extra config needed
Request validation powered by Pydantic — think of it as @Valid + @RequestBody baked in
Type hints as the source of truth — Python's type system does the heavy lifting
Async-ready from the ground up — ASGI all the way

The best part? You can build a fully working REST API in under 50 lines.

What We're Building

A Tea CRUD API — simple, but covers every REST pattern:

Method	Endpoint	What It Does
GET	`/`	Health / welcome message
GET	`/teas`	List all teas
POST	`/teas`	Add a new tea
PUT	`/teas/{tea_id}`	Update an existing tea
DELETE	`/teas/{tea_id}`	Remove a tea

No database — we're using an in-memory list to keep the focus on FastAPI itself.

Prerequisites

Python 3.10+
pip

Verify:

python --version
pip --version

Setup

Create and activate a virtual environment:

# Windows (PowerShell)
python -m venv venv
.\venv\Scripts\Activate

# macOS / Linux
python3 -m venv venv
source venv/bin/activate

Install dependencies:

pip install "fastapi[standard]"

This single command installs FastAPI, Uvicorn (the ASGI server), and all optional extras — all you need to get running.

The Full Code

Create a file called main.py and drop this in:

from fastapi import FastAPI
from pydantic import BaseModel
from typing import List

app = FastAPI()

class Tea(BaseModel):
    id: int
    name: str
    origin: str

teas: List[Tea] = []

@app.get("/")
def read_root():
    return {"message": "Welcome to chai code"}

@app.get("/teas")
def get_teas():
    return teas

@app.post("/teas")
def add_teas(tea: Tea):
    teas.append(tea)
    return tea

@app.put("/teas/{tea_id}")
def update_tea(tea_id: int, update_tea: Tea):
    for index, tea in enumerate(teas):
        if tea.id == tea_id:
            teas[index] = update_tea
            return update_tea
    return {"error": "Tea not found"}

@app.delete("/teas/{tea_id}")
def delete_tea(tea_id: int):
    for index, tea in enumerate(teas):
        if tea.id == tea_id:
            deleted = teas.pop(index)
            return deleted
    return {"error": "Tea not found"}

That's it. 43 lines. Let's break it down.

Code Walkthrough

1. The App Instance

app = FastAPI()

This is your application object — equivalent to new SpringApplication() in Spring Boot, but in one line with no annotations, XML, or config files.

2. The Pydantic Model

class Tea(BaseModel):
    id: int
    name: str
    origin: str

BaseModel from Pydantic is the magic here. Any class that extends it automatically gets:

Request body parsing — FastAPI reads the incoming JSON and maps it to this class
Type validation — if id isn't an integer, FastAPI returns a 422 Unprocessable Entity with a clear error message
Serialization — returning a Tea instance automatically serializes it to JSON

For Java developers: think @Data + @Valid + Jackson — except it's one import and zero annotations on your fields.

3. The In-Memory Store

teas: List[Tea] = []

Just a Python list typed with List[Tea]. It acts as our database for this example. Doesn't survive restarts — but that's intentional for a learning project. You'd swap this with SQLAlchemy + PostgreSQL in a production setup.

4. GET — List All Teas

@app.get("/teas")
def get_teas():
    return teas

Return the list directly. FastAPI serializes List[Tea] to a JSON array automatically. No ResponseEntity, no @ResponseBody, no boilerplate.

5. POST — Add a Tea

@app.post("/teas")
def add_teas(tea: Tea):
    teas.append(tea)
    return tea

The function parameter tea: Tea tells FastAPI: "expect a JSON body matching the Tea schema." Pydantic validates it. If validation fails, FastAPI returns a detailed 422 error before your function is even called.

6. PUT — Update by ID

@app.put("/teas/{tea_id}")
def update_tea(tea_id: int, update_tea: Tea):
    for index, tea in enumerate(teas):
        if tea.id == tea_id:
            teas[index] = update_tea
            return update_tea
    return {"error": "Tea not found"}

{tea_id} in the path is a path parameter — FastAPI extracts it and coerces it to int automatically. You get both a path param (tea_id) and a request body (update_tea) from a single function signature. Clean.

7. DELETE — Remove by ID

@app.delete("/teas/{tea_id}")
def delete_tea(tea_id: int):
    for index, tea in enumerate(teas):
        if tea.id == tea_id:
            deleted = teas.pop(index)
            return deleted
    return {"error": "Tea not found"}

Linear scan through our in-memory list — fine for learning, but you'd index by ID with a dict or use a database in production.

Run It

python -m uvicorn main:app --reload

Expected output:

INFO:     Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
INFO:     Started reloader process

The --reload flag means the server restarts automatically on every file save — great for development.

Interactive API Docs (Free!)

This is FastAPI's killer feature. Open your browser:

URL	What You Get
`http://127.0.0.1:8000/docs`	Swagger UI — test every endpoint interactively
`http://127.0.0.1:8000/redoc`	ReDoc — clean, readable API reference

No extra setup. No Postman required for a quick test. The docs are generated directly from your type hints and Pydantic models.

Quick Test via Swagger UI

Go to http://127.0.0.1:8000/docs
Click POST /teas → Try it out
Paste this body:

{
  "id": 1,
  "name": "Assam Tea",
  "origin": "India"
}

Click Execute
Now hit GET /teas — you'll see your tea in the list

What's Next (Production Roadmap)

This in-memory app is intentionally minimal. Here's how you'd evolve it toward production:

Concern	Tool
Persistent storage	SQLAlchemy + PostgreSQL or SQLite
Migrations	Alembic
Auth	JWT via `python-jose` + `passlib`
Dependency Injection	FastAPI's built-in `Depends()` system
Environment config	`pydantic-settings`
Containerization	Docker + `uvicorn` in production mode
Testing	`pytest` + `httpx` (async test client)
Async DB	`asyncpg` + SQLAlchemy async sessions

Java/Kotlin Developer Take

Having spent years with Spring Boot, here's my honest comparison:

FastAPI wins on:

Speed of prototyping — no boilerplate ceremony
Auto-generated docs that are actually useful
Cleaner validation without annotation overload

Spring Boot still wins on:

Enterprise ecosystem maturity
Structured DI with complex bean graphs
Mature monitoring (Actuator, Micrometer)

FastAPI fills a real gap: it's the right tool when you want Python's data ecosystem (ML, data pipelines) behind a production-quality HTTP API. The two aren't in competition — they're tools for different contexts.

Source Code

Everything in this post is available here:

github.com/MihirMohapatra/fast-api-example

Drop a ⭐ if it helped you get started.

Building toward senior remote roles at US/EU companies. Follow along as I explore FastAPI, Rust, Go, and AI infrastructure — writing from the perspective of a practising backend engineer, not a tutorial blog.

From Learning to Shipping — Docker, Graceful Shutdown & ECS Fargate

mihir mohapatra — Thu, 25 Jun 2026 05:13:15 +0000

From Learning to Shipping — Docker, Graceful Shutdown & ECS Fargate

This is the final post in the series. In part 6 I covered testing — table-driven tests, httptest, benchmarks. Now I'm taking everything built across the last six posts and shipping it: a multi-stage Docker build, graceful shutdown wired into the Gin server, and deployment to AWS ECS Fargate using Terraform — the same stack I used for rust-ai-gateway.

If you've followed along, this is where the learning project becomes something you can actually point a recruiter at.

Multi-Stage Docker Build

The biggest Go deployment win over the JVM is binary size. A Go service compiles to a single self-contained binary with no runtime dependency — no JVM to install, no classpath to assemble. That means the production image can be built in two stages: a full Go toolchain image to compile, then a minimal scratch or distroless image to run.

# ---- build stage ----
FROM golang:1.22-alpine AS builder

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download

COPY . .

RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
    go build -ldflags="-s -w" -o orders-api ./cmd/main.go

# ---- run stage ----
FROM gcr.io/distroless/static-debian12

WORKDIR /app
COPY --from=builder /app/orders-api .

EXPOSE 8080
USER nonroot:nonroot

ENTRYPOINT ["/app/orders-api"]

Three things worth unpacking here. CGO_ENABLED=0 disables C bindings, which is required for a fully static binary that works in distroless. The -ldflags="-s -w" strip the debug symbol table and DWARF info, shaving 20–30% off the binary size for free. And distroless/static is the production choice over scratch — it has no shell (good for security) but includes timezone data and SSL certificates that your service will almost certainly need.

The resulting image typically comes in under 20MB. The equivalent Spring Boot fat jar with a JRE base image usually lands somewhere north of 300MB.

Graceful Shutdown

Out of the box, r.Run(":8080") in Gin blocks forever and stops immediately on SIGTERM — mid-request, no cleanup, no connection draining. In a containerised environment where ECS sends SIGTERM before terminating a task, that's dropped requests on every deployment. The fix is to run the server in a goroutine and listen for the OS signal yourself:

// cmd/main.go
package main

import (
    "context"
    "log"
    "net/http"
    "os"
    "os/signal"
    "syscall"
    "time"

    "orders-api/handler"
    "orders-api/middleware"
    "orders-api/store"

    "github.com/gin-gonic/gin"
)

func main() {
    s := store.NewInMemoryStore()
    h := handler.NewOrderHandler(s)

    r := gin.New()
    r.Use(middleware.Logger())

    api := r.Group("/api/v1")
    {
        orders := api.Group("/orders")
        orders.POST("", h.Create)
        orders.GET("", h.List)
        orders.GET("/:id", h.GetByID)
    }

    srv := &http.Server{
        Addr:    ":8080",
        Handler: r,
    }

    // start server in background goroutine
    go func() {
        log.Println("server listening on :8080")
        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            log.Fatalf("listen error: %v", err)
        }
    }()

    // block until SIGINT or SIGTERM
    quit := make(chan os.Signal, 1)
    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
    <-quit

    log.Println("shutdown signal received, draining connections...")

    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    if err := srv.Shutdown(ctx); err != nil {
        log.Fatalf("forced shutdown: %v", err)
    }

    log.Println("server exited cleanly")
}

srv.Shutdown(ctx) tells the HTTP server to stop accepting new connections and wait for in-flight requests to finish, up to the 30-second deadline. This is the goroutine and channel pattern from part 3 applied directly to real production code — quit is a channel, <-quit blocks until a signal arrives, and then the shutdown sequence runs. No framework magic, just the primitives we've been using all along.

Health Check Endpoint

ECS needs a health check to know when a task is ready for traffic and when it's gone unhealthy. Two lines in the router:

r.GET("/health", func(c *gin.Context) {
    c.JSON(http.StatusOK, gin.H{"status": "ok"})
})

r.GET("/ready", func(c *gin.Context) {
    // in a real service: check DB connectivity here
    c.JSON(http.StatusOK, gin.H{"status": "ready"})
})

/health is the liveness probe — is the process running. /ready is the readiness probe — is the service ready to serve traffic (database connected, caches warm). Keeping them separate lets ECS restart an unhealthy container without pulling it from the load balancer unnecessarily during a slow startup.

Terraform: ECS Fargate

The infrastructure follows the same pattern as rust-ai-gateway — ECR for the image, ECS Fargate for the task, an ALB in front. The key pieces:

# ecr.tf
resource "aws_ecr_repository" "orders_api" {
  name                 = "orders-api"
  image_tag_mutability = "MUTABLE"

  image_scanning_configuration {
    scan_on_push = true
  }
}

# ecs.tf
resource "aws_ecs_task_definition" "orders_api" {
  family                   = "orders-api"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = "256"
  memory                   = "512"
  execution_role_arn       = aws_iam_role.ecs_task_execution.arn

  container_definitions = jsonencode([{
    name      = "orders-api"
    image     = "${aws_ecr_repository.orders_api.repository_url}:latest"
    essential = true

    portMappings = [{
      containerPort = 8080
      protocol      = "tcp"
    }]

    healthCheck = {
      command     = ["CMD-SHELL", "wget -qO- http://localhost:8080/health || exit 1"]
      interval    = 30
      timeout     = 5
      retries     = 3
      startPeriod = 10
    }

    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"         = "/ecs/orders-api"
        "awslogs-region"        = var.aws_region
        "awslogs-stream-prefix" = "ecs"
      }
    }
  }])
}

resource "aws_ecs_service" "orders_api" {
  name            = "orders-api"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.orders_api.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = var.private_subnet_ids
    security_groups  = [aws_security_group.ecs_tasks.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.orders_api.arn
    container_name   = "orders-api"
    container_port   = 8080
  }

  deployment_minimum_healthy_percent = 100
  deployment_maximum_percent         = 200
}

desired_count = 2 with deployment_minimum_healthy_percent = 100 means ECS will never take both tasks down simultaneously during a deployment — new tasks must become healthy before old ones are stopped, which combined with the graceful shutdown above gives zero-downtime deploys.

CI/CD: GitHub Actions

The deploy pipeline that ties it together — build, push to ECR, force a new ECS deployment:

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Login to ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build, tag and push image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $ECR_REGISTRY/orders-api:$IMAGE_TAG .
          docker push $ECR_REGISTRY/orders-api:$IMAGE_TAG
          docker tag $ECR_REGISTRY/orders-api:$IMAGE_TAG $ECR_REGISTRY/orders-api:latest
          docker push $ECR_REGISTRY/orders-api:latest

      - name: Force ECS deployment
        run: |
          aws ecs update-service \
            --cluster main \
            --service orders-api \
            --force-new-deployment

Using github.sha as the image tag means every deploy is traceable — you can look at a running ECS task, find the image tag, and map it back to an exact commit. Tagging latest separately lets Terraform and the task definition reference a stable name, while the SHA tag is there for auditability.

What This Series Built

Seven posts ago I was explaining why I was picking up Go. Here's what actually got built:

A type system that composes instead of inheriting, with interfaces that match on shape rather than declaration
A concurrency model that puts goroutines and channels in reach by default
Error handling that makes failure visible at every call site
A Gin REST API with middleware, request validation, and clean handler separation
A full test suite: table-driven unit tests, httptest handler tests, and benchmarks
A production deployment: multi-stage Docker under 20MB, graceful shutdown, ECS Fargate behind an ALB, GitHub Actions CI/CD

The thing I didn't expect: Go's simplicity compounds. Every new piece — a new handler, a new test, a new middleware — follows the same small set of patterns. There's less to remember, and the code that comes out of it is easier to read six months later than Java or Kotlin at comparable complexity. I get why teams that care about maintainability and onboarding speed keep reaching for it.

Next on my list for this codebase: swapping the in-memory store for pgx and PostgreSQL, adding OpenTelemetry tracing, and wiring in a real secrets manager. That might become another series, or it might just end up in the GitHub repo.

If you've followed along from part 1 — thanks for reading. And if you're just landing here and want the whole project, the full source is at github.com/MihirMohapatra/go-orders-api once I push it.

What should the next series be? Another Go deep-dive, or something at the intersection of Go and AI infrastructure?

Testing in Go — Table-Driven Tests, Benchmarks, and go test Habits

mihir mohapatra — Tue, 23 Jun 2026 11:27:55 +0000

Testing in Go — Table-Driven Tests, Benchmarks, and go test Habits

In part 5 I built a working Orders API with Gin — routes, middleware, an in-memory store, and proper error handling. This time I'm writing tests for it, and the story here is one of the things I've genuinely liked about Go from the start: testing is a first-class citizen with zero framework ceremony. No JUnit, no Mockito, no Spring Boot test context to spin up. Just go test and the standard library.

The go test Mental Model

Every _test.go file in a Go package is compiled and run by go test. Test functions follow one convention — they take a single *testing.T argument and start with Test:

func TestSomething(t *testing.T) {
    // ...
}

That's the entire contract. No annotations, no base classes, no test runner configuration file. Running go test ./... from the project root picks up every test across every package recursively. Running with -v shows each test name and its pass/fail. Running with -race enables the data race detector we talked about in part 3. These three invocations cover 90% of what I reach for day to day:

go test ./...                  # run everything
go test -v ./handler/...       # verbose, one package
go test -race ./...            # race detector on
go test -run TestCreateOrder . # run one test by name

Table-Driven Tests: The Go Idiom

The single most important testing pattern in Go is the table-driven test. Instead of writing one test function per scenario, you define a slice of cases as a struct, loop over them, and let the test framework tell you exactly which case failed. Coming from JUnit's @ParameterizedTest, it's the same idea — except it's just a for loop, no framework required:

// store/order_test.go
package store_test

import (
    "testing"

    "orders-api/model"
    "orders-api/store"
)

func TestCreateOrder(t *testing.T) {
    cases := []struct {
        name      string
        input     model.CreateOrderRequest
        wantErr   bool
    }{
        {
            name:    "valid order",
            input:   model.CreateOrderRequest{Customer: "Alice", Amount: 99.99},
            wantErr: false,
        },
        {
            name:    "zero amount",
            input:   model.CreateOrderRequest{Customer: "Bob", Amount: 0},
            wantErr: false, // store doesn't validate, handler does
        },
        {
            name:    "empty customer",
            input:   model.CreateOrderRequest{Customer: "", Amount: 50.0},
            wantErr: false,
        },
    }

    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            s := store.NewInMemoryStore()
            order, err := s.Create(tc.input)

            if tc.wantErr && err == nil {
                t.Errorf("expected error, got nil")
            }
            if !tc.wantErr && err != nil {
                t.Errorf("unexpected error: %v", err)
            }
            if !tc.wantErr && order.ID == "" {
                t.Errorf("expected non-empty order ID, got empty string")
            }
        })
    }
}

t.Run creates a named sub-test for each case. When a sub-test fails, Go prints the full path — TestCreateOrder/zero_amount — so you know instantly which case broke without digging through output. This is the pattern the entire Go standard library uses internally, and it's the first habit worth locking in.

Testing the Store: ErrNotFound

The GetByID path needs its own table — specifically the not-found branch we wired into the handler in part 5:

func TestGetByID(t *testing.T) {
    s := store.NewInMemoryStore()

    // seed one order
    created, _ := s.Create(model.CreateOrderRequest{
        Customer: "Alice",
        Amount:   49.99,
    })

    cases := []struct {
        name    string
        id      string
        wantErr error
    }{
        {"existing order", created.ID, nil},
        {"missing order", "does-not-exist", store.ErrNotFound},
        {"empty id", "", store.ErrNotFound},
    }

    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            _, err := s.GetByID(tc.id)
            if !errors.Is(err, tc.wantErr) {
                t.Errorf("got err %v, want %v", err, tc.wantErr)
            }
        })
    }
}

errors.Is in the test assertion mirrors exactly how the handler checks errors — the sentinel defined in the store package is the contract, and we're verifying both sides of it honour it.

Handler Tests with httptest

Testing the handler layer without spinning up a real server is where Go's net/http/httptest package earns its place. It gives you a fake ResponseRecorder that captures everything the handler writes — status code, headers, body — without any network involvement:

// handler/order_test.go
package handler_test

import (
    "bytes"
    "encoding/json"
    "net/http"
    "net/http/httptest"
    "testing"

    "orders-api/handler"
    "orders-api/model"
    "orders-api/store"

    "github.com/gin-gonic/gin"
)

func setupRouter(h *handler.OrderHandler) *gin.Engine {
    gin.SetMode(gin.TestMode)
    r := gin.New()
    r.POST("/orders", h.Create)
    r.GET("/orders/:id", h.GetByID)
    r.GET("/orders", h.List)
    return r
}

func TestCreateOrderHandler(t *testing.T) {
    cases := []struct {
        name       string
        body       any
        wantStatus int
    }{
        {
            name:       "valid request",
            body:       model.CreateOrderRequest{Customer: "Alice", Amount: 99.99},
            wantStatus: http.StatusCreated,
        },
        {
            name:       "missing customer",
            body:       map[string]any{"amount": 49.99},
            wantStatus: http.StatusBadRequest,
        },
        {
            name:       "negative amount",
            body:       map[string]any{"customer": "Bob", "amount": -10},
            wantStatus: http.StatusBadRequest,
        },
    }

    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            s := store.NewInMemoryStore()
            h := handler.NewOrderHandler(s)
            r := setupRouter(h)

            bodyBytes, _ := json.Marshal(tc.body)
            req := httptest.NewRequest(http.MethodPost, "/orders", bytes.NewReader(bodyBytes))
            req.Header.Set("Content-Type", "application/json")
            w := httptest.NewRecorder()

            r.ServeHTTP(w, req)

            if w.Code != tc.wantStatus {
                t.Errorf("status: got %d, want %d — body: %s",
                    w.Code, tc.wantStatus, w.Body.String())
            }
        })
    }
}

gin.SetMode(gin.TestMode) suppresses the debug output Gin prints during tests. Each case builds a fresh store and handler so tests are fully isolated — no shared state leaking between cases. The w.Body.String() in the error message means a failing test prints the actual response body, which cuts debug time significantly.

Benchmarks: Built Right In

Benchmarks follow the same file and naming conventions as tests, but use *testing.B and prefix with Benchmark. The runner calls your function repeatedly, adjusting iteration count until the timing is stable:

func BenchmarkStoreList(b *testing.B) {
    s := store.NewInMemoryStore()

    // seed 1000 orders
    for i := 0; i < 1000; i++ {
        s.Create(model.CreateOrderRequest{
            Customer: fmt.Sprintf("customer-%d", i),
            Amount:   float64(i) * 1.5,
        })
    }

    b.ResetTimer() // don't count seeding time

    for i := 0; i < b.N; i++ {
        _, err := s.List()
        if err != nil {
            b.Fatal(err)
        }
    }
}

Running go test -bench=. -benchmem ./store/... gives you nanoseconds per operation and allocations per operation:

BenchmarkStoreList-8    42361    28204 ns/op    24576 B/op    3 allocs/op

b.ResetTimer() after the seeding step is the habit that matters most here — you want to measure List, not Create × 1000. The -benchmem flag surfacing allocations per operation is the other one: in a hot path, allocation count matters as much as raw speed.

The go test Habits Worth Locking In

After a few weeks of writing Go tests, these are the ones I've made automatic:

Always use t.Run for multi-case scenarios. Even two cases. The named sub-test output pays for the extra line immediately when something breaks.

t.Parallel() for independent tests. Adding t.Parallel() at the top of a test (or sub-test) tells the runner it can execute concurrently with other parallel tests, cutting total test time on multi-core machines with no other changes.

-race in CI, always. Data races in Go are silent in normal test runs and catastrophic in production. The race detector adds overhead but catches things that would otherwise survive code review and only surface under load.

testify/assert if your team agrees, testing if they don't. The standard testing package requires writing your own error messages for every assertion. testify/assert gives you assert.Equal, assert.NoError, and friends with good default messages. Both are valid choices — the important thing is consistency within a codebase.

Up Next

Part 7 is the finish line: multi-stage Docker build, graceful shutdown, and getting this service onto ECS Fargate — the same deployment target I used for rust-ai-gateway. The testing patterns from this post will feed directly into the CI pipeline we wire up there.

Do you have a preferred Go testing library — pure testing, testify, or something else? Curious whether the standard library alone is enough once the projects get bigger.

Building My First Real API in Go — with Gin

mihir mohapatra — Mon, 22 Jun 2026 07:40:08 +0000

Building My First Real API in Go — with Gin

In part 4 I worked through Go's error handling model and came around on if err != nil. This is the post where everything from the last four parts — structs, interfaces, goroutines, error wrapping — stops being theoretical and actually gets wired into something that runs, accepts requests, and talks to a database.

I'm building a small Orders API: create an order, fetch one by ID, list all of them. Simple enough that the routing and middleware patterns are clear, complex enough that the error handling and concurrency patterns from earlier posts actually matter.

Why Gin

The Go standard library's net/http package is genuinely capable — you can write a production API with nothing else. But Gin adds three things that make it worth reaching for immediately: a clean router with path parameters and route groups, a middleware chain that composes nicely, and response helpers (c.JSON, c.AbortWithStatusJSON) that remove a lot of boilerplate. It's the closest thing Go has to a lightweight Express or Axum — fast, minimal, and doesn't try to own your entire architecture.

go mod init orders-api
go get github.com/gin-gonic/gin

Project Structure

Before a single line of code, here's the layout I settled on:

orders-api/
├── main.go
├── handler/
│   └── order.go
├── model/
│   └── order.go
├── store/
│   └── order.go
└── middleware/
    └── logger.go

This is the standard Go flat-package layout — no src/, no deep nesting, no framework-imposed folders. handler owns HTTP concerns, model owns data shapes, store owns persistence logic. The separation means each layer depends on the one below it, and none of them import each other in circles.

The Model

// model/order.go
package model

import "time"

type Order struct {
    ID        string    `json:"id"`
    Customer  string    `json:"customer"`
    Amount    float64   `json:"amount"`
    Status    string    `json:"status"`
    CreatedAt time.Time `json:"created_at"`
}

type CreateOrderRequest struct {
    Customer string  `json:"customer" binding:"required"`
    Amount   float64 `json:"amount"   binding:"required,gt=0"`
}

Two things worth noting here. The struct tags (json:"id") control serialisation — without them Gin would use the field name as-is, so CreatedAt would become CreatedAt in JSON rather than created_at. The binding tags on CreateOrderRequest are Gin's built-in validation: binding:"required" rejects blank fields, gt=0 rejects zero or negative amounts. This is the closest Go gets to Java Bean Validation annotations, except it's enforced at the handler layer rather than the model layer — I'll show how in a moment.

The Store

For now the store is in-memory — a map behind a sync.RWMutex. Part 7 will swap this for pgx. The interface is the important part:

// store/order.go
package store

import (
    "errors"
    "sync"
    "time"

    "orders-api/model"

    "github.com/google/uuid"
)

var ErrNotFound = errors.New("order not found")

type OrderStore interface {
    Create(req model.CreateOrderRequest) (model.Order, error)
    GetByID(id string) (model.Order, error)
    List() ([]model.Order, error)
}

type inMemoryStore struct {
    mu     sync.RWMutex
    orders map[string]model.Order
}

func NewInMemoryStore() OrderStore {
    return &inMemoryStore{orders: make(map[string]model.Order)}
}

func (s *inMemoryStore) Create(req model.CreateOrderRequest) (model.Order, error) {
    order := model.Order{
        ID:        uuid.New().String(),
        Customer:  req.Customer,
        Amount:    req.Amount,
        Status:    "pending",
        CreatedAt: time.Now(),
    }
    s.mu.Lock()
    s.orders[order.ID] = order
    s.mu.Unlock()
    return order, nil
}

func (s *inMemoryStore) GetByID(id string) (model.Order, error) {
    s.mu.RLock()
    defer s.mu.RUnlock()
    order, ok := s.orders[id]
    if !ok {
        return model.Order{}, ErrNotFound
    }
    return order, nil
}

func (s *inMemoryStore) List() ([]model.Order, error) {
    s.mu.RLock()
    defer s.mu.RUnlock()
    orders := make([]model.Order, 0, len(s.orders))
    for _, o := range s.orders {
        orders = append(orders, o)
    }
    return orders, nil
}

sync.RWMutex lets multiple concurrent reads proceed at the same time but serialises writes — the right primitive for a read-heavy in-memory store. The OrderStore interface is defined here, in the store package, but that's just for organisation — the handler depends on the interface, not the concrete type, which means swapping in a real database later is a one-line change in main.go.

The Handler

// handler/order.go
package handler

import (
    "errors"
    "net/http"

    "orders-api/model"
    "orders-api/store"

    "github.com/gin-gonic/gin"
)

type OrderHandler struct {
    store store.OrderStore
}

func NewOrderHandler(s store.OrderStore) *OrderHandler {
    return &OrderHandler{store: s}
}

func (h *OrderHandler) Create(c *gin.Context) {
    var req model.CreateOrderRequest
    if err := c.ShouldBindJSON(&req); err != nil {
        c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": err.Error()})
        return
    }

    order, err := h.store.Create(req)
    if err != nil {
        c.AbortWithStatusJSON(http.StatusInternalServerError, gin.H{"error": "could not create order"})
        return
    }

    c.JSON(http.StatusCreated, order)
}

func (h *OrderHandler) GetByID(c *gin.Context) {
    id := c.Param("id")

    order, err := h.store.GetByID(id)
    if err != nil {
        if errors.Is(err, store.ErrNotFound) {
            c.AbortWithStatusJSON(http.StatusNotFound, gin.H{"error": "order not found"})
            return
        }
        c.AbortWithStatusJSON(http.StatusInternalServerError, gin.H{"error": "could not fetch order"})
        return
    }

    c.JSON(http.StatusOK, order)
}

func (h *OrderHandler) List(c *gin.Context) {
    orders, err := h.store.List()
    if err != nil {
        c.AbortWithStatusJSON(http.StatusInternalServerError, gin.H{"error": "could not list orders"})
        return
    }
    c.JSON(http.StatusOK, orders)
}

ShouldBindJSON is where the binding tags from the model earn their keep — it validates and decodes the request body in one call, returning a descriptive error if anything fails. errors.Is(err, store.ErrNotFound) is the same pattern from part 4: unwrap through layers and match the sentinel. The handler doesn't know or care whether the store is in-memory or PostgreSQL — it just speaks to the interface.

Middleware: Request Logging

// middleware/logger.go
package middleware

import (
    "fmt"
    "time"

    "github.com/gin-gonic/gin"
)

func Logger() gin.HandlerFunc {
    return func(c *gin.Context) {
        start := time.Now()
        c.Next()
        fmt.Printf("[%s] %s %s %d (%s)\n",
            start.Format("15:04:05"),
            c.Request.Method,
            c.Request.URL.Path,
            c.Writer.Status(),
            time.Since(start),
        )
    }
}

c.Next() hands control to the next handler in the chain, then execution returns here after the response is written — which is why time.Since(start) gives you the actual request duration. This is the middleware pattern in every Gin-based service: wrap, call Next(), do something with what happened after.

Wiring It Together

// main.go
package main

import (
    "orders-api/handler"
    "orders-api/middleware"
    "orders-api/store"

    "github.com/gin-gonic/gin"
)

func main() {
    s := store.NewInMemoryStore()
    h := handler.NewOrderHandler(s)

    r := gin.New()
    r.Use(middleware.Logger())

    api := r.Group("/api/v1")
    {
        orders := api.Group("/orders")
        orders.POST("", h.Create)
        orders.GET("", h.List)
        orders.GET("/:id", h.GetByID)
    }

    r.Run(":8080")
}

gin.New() instead of gin.Default() gives a blank engine — no Gin's built-in logger or recovery middleware added automatically, since we're providing our own. The r.Group nesting gives every orders route the /api/v1/orders prefix without repeating it on each registration. Running this and hitting POST /api/v1/orders with a JSON body gets you a real response, with validation, error handling, and request logging, in about 120 lines across all files.

What This Draws On From Earlier Posts

Part 2's interfaces: OrderStore is exactly the kind of single-responsibility interface Go favours — three methods, defined by the consumer (the handler), satisfied implicitly by the concrete store.

Part 3's concurrency: sync.RWMutex in the store is the in-memory safe concurrency answer. In part 7 when this becomes a real database, the connection pool handles this instead.

Part 4's error handling: errors.Is(err, store.ErrNotFound) translating a store-layer sentinel into an HTTP 404 is the wrapping pattern paying off at the HTTP boundary.

Up Next

Part 6 is testing — table-driven tests, the httptest package for handler tests without spinning up a real server, and the benchmarking habits that will matter once we push toward production in part 7.

What's your preferred approach to structuring Go API projects — flat packages like this, or a domain-driven layout with more nesting? Genuinely curious how people land on this one.

Error Handling — Learning to Love `if err != nil`

mihir mohapatra — Sun, 21 Jun 2026 09:48:23 +0000

Error Handling — Learning to Love `if err != nil`

In part 3 I covered goroutines and channels, and how Go's concurrency model sidesteps a lot of the ceremony I was used to from the JVM. This time I'm tackling the thing I complained about in part 1 of this series before I'd even really tried it: error handling. I called if err != nil repetitive back then. A few weeks and a lot of real code later, I owe Go a partial apology.

No Exceptions, On Purpose

Coming from Java, the absence of try/catch is the first thing that feels like a missing feature. It isn't — it's a deliberate design choice. In Go, errors are just values. A function that can fail returns an error as its last return value, and the caller decides what to do with it, right there, inline:

func divide(a, b float64) (float64, error) {
    if b == 0 {
        return 0, errors.New("division by zero")
    }
    return a / b, nil
}

func main() {
    result, err := divide(10, 0)
    if err != nil {
        fmt.Println("error:", err)
        return
    }
    fmt.Println("result:", result)
}

That's the pattern you'll write hundreds of times in Go: call a function, check err, handle it or bail out, move on. No hidden control flow jumping up the call stack to whichever catch block happens to match. No checked-exception signatures cluttering method declarations. No RuntimeException quietly skipping past five layers of code that had no idea it could happen. Whatever can fail is sitting right there in the function signature, and you're forced to look at it.

Why the Repetition Is the Point

My part 1 complaint was that if err != nil everywhere feels manual. It is manual — and that's exactly the trade Go is making. In Java, an exception thrown deep in a call stack can silently propagate through layers of code that never declared they might fail, and you only find out where things actually break by reading a stack trace after the fact. In Go, every single point where something can go wrong is visible in the source, in order, as you read top to bottom:

func processOrder(id string) error {
    order, err := fetchOrder(id)
    if err != nil {
        return fmt.Errorf("fetching order: %w", err)
    }

    if err := validateOrder(order); err != nil {
        return fmt.Errorf("validating order: %w", err)
    }

    if err := chargePayment(order); err != nil {
        return fmt.Errorf("charging payment: %w", err)
    }

    return nil
}

Three things can fail here, and you can see all three without jumping anywhere. That %w verb in fmt.Errorf is doing something specific — it's wrapping the original error rather than discarding it, which means the caller can still inspect what actually went wrong underneath your added context. It's the closest thing Go has to a stack trace, except you control exactly how much context gets added at each layer instead of getting a wall of frames you have to parse yourself.

errors.Is and errors.As: Inspecting Wrapped Errors

Once you're wrapping errors as they bubble up, you need a way to check what's actually inside the wrapping. That's what errors.Is and errors.As are for:

var ErrNotFound = errors.New("order not found")

func fetchOrder(id string) (Order, error) {
    if id == "" {
        return Order{}, ErrNotFound
    }
    return Order{ID: id}, nil
}

func main() {
    err := processOrder("")
    if errors.Is(err, ErrNotFound) {
        fmt.Println("order doesn't exist, returning 404")
        return
    }
    fmt.Println("unexpected error:", err)
}

Even though processOrder wrapped the original error with fmt.Errorf("fetching order: %w", err), errors.Is can still see through the wrapping and match it against the sentinel ErrNotFound. This is the Go equivalent of catch (OrderNotFoundException e) — except instead of a type hierarchy of custom exception classes, you define a handful of sentinel error values (or custom error types, when you need to carry extra data) and compare against them explicitly wherever the distinction matters.

errors.As does the same thing but for pulling out a specific error type rather than matching a specific value — useful when you've defined a custom struct that implements the error interface and carries extra fields:

type ValidationError struct {
    Field string
    Msg   string
}

func (e *ValidationError) Error() string {
    return fmt.Sprintf("%s: %s", e.Field, e.Msg)
}

func main() {
    err := processOrder("123")
    var valErr *ValidationError
    if errors.As(err, &valErr) {
        fmt.Println("invalid field:", valErr.Field)
    }
}

Any type with an Error() string method satisfies the error interface — same implicit-satisfaction rule from part 2, just applied to errors specifically.

panic and recover: Not Your Exception Mechanism

Go does have panic and recover, and the instinct coming from Java is to treat them like throw and catch. That's a mistake that took me a minute to unlearn. panic is reserved for genuinely unrecoverable situations — a programming bug, a nil pointer you should never have dereferenced, an invariant that's been violated so badly that continuing execution would be worse than crashing:

func mustParseConfig(raw string) Config {
    cfg, err := parseConfig(raw)
    if err != nil {
        panic(fmt.Sprintf("invalid config, cannot start: %v", err))
    }
    return cfg
}

Notice the must prefix — that's a real Go convention signaling "this panics instead of returning an error, use it only when failure should be impossible or fatal." You'll see it on things like regexp.MustCompile, used for regex patterns that are hardcoded at compile time and should never actually fail to parse. If a function can fail in a way the caller might reasonably want to handle, it returns an error. panic is for "this program cannot continue," not "this operation didn't work."

Where I've Landed

A few weeks in, the repetition stopped bothering me, for a specific reason: I always know exactly where my code can fail, just by reading it. No exception is escaping from three function calls deep and surfacing somewhere I didn't expect. The trade-off is real — Go code has more visible lines dedicated to error checking than the equivalent Java would — but every one of those lines is telling me something true about the function I'm calling, instead of trusting that a try/catch block somewhere upstream will catch what I forgot to handle.

What still isn't fully natural yet: remembering to wrap errors with enough context every single time (it's easy to return a bare err and lose the "where did this happen" information), and resisting the urge to define a sprawling hierarchy of custom error types out of old OOP habits when a couple of sentinel errors would do.

Up Next

With types, concurrency, and error handling covered, part 5 is where this series gets concrete: building a real REST API with Gin, including the error-handling and concurrency patterns from the last two posts actually wired into request handlers.

If you've made the jump from exceptions to Go's explicit error returns, did the repetition bother you at first the way it bothered me — and did it fade the same way?

Goroutines & Channels — Concurrency Without the JVM's Baggage

mihir mohapatra — Sat, 20 Jun 2026 08:44:14 +0000

Goroutines & Channels — Concurrency Without the JVM's Baggage

In part 2 I went through Go's type system — structs, implicit interfaces, and composition replacing inheritance entirely. This time I'm tackling the thing that actually pulled me toward Go in the first place: concurrency.

If you've spent years on the JVM like I have, "concurrency" usually means a mental checklist — ExecutorService, thread pool sizing, Future<T>, maybe CompletableFuture chains, and more recently virtual threads if you're on a modern JDK. It's powerful, but it's also a lot of ceremony for what's often a simple idea: "do these things at the same time, then collect the results." Go strips almost all of that ceremony away, and that's been the most genuinely refreshing part of this whole learning process.

Goroutines: Threads, But Cheap

A goroutine is Go's unit of concurrent execution. The syntax is almost suspiciously simple — you put go in front of a function call, and it runs concurrently:

func main() {
    go sayHello("world")
    time.Sleep(50 * time.Millisecond) // give it time to run
}

func sayHello(name string) {
    fmt.Println("Hello,", name)
}

That time.Sleep hack is the first lesson everyone learns the hard way: main doesn't wait for goroutines to finish. If main exits, every goroutine it spawned just gets cut off mid-flight. We'll fix that properly in a moment with sync.WaitGroup, but the sleep hack is worth seeing once because it makes the "goroutines don't block their caller" behavior concrete.

What makes goroutines genuinely different from JVM threads isn't the syntax — it's the cost. A JVM thread typically reserves around a megabyte of stack space and is managed by the OS scheduler. A goroutine starts with a stack of about 2KB that grows as needed, and Go's own runtime scheduler multiplexes thousands of them onto a small number of OS threads. Spinning up 100,000 goroutines is a normal thing to do in Go. Spinning up 100,000 JVM platform threads will bring most systems to their knees — which is exactly the problem virtual threads were introduced to solve in recent JDKs. Go just had this answer from day one.

WaitGroups: The Right Way to Wait

Instead of sleeping and hoping, sync.WaitGroup lets you wait for a known number of goroutines to actually finish:

func main() {
    var wg sync.WaitGroup

    services := []string{"orders", "payments", "inventory"}

    for _, name := range services {
        wg.Add(1)
        go func(s string) {
            defer wg.Done()
            fetchFromService(s)
        }(name)
    }

    wg.Wait()
    fmt.Println("all services responded")
}

func fetchFromService(name string) {
    time.Sleep(100 * time.Millisecond)
    fmt.Println(name, "done")
}

wg.Add(1) registers one goroutine to wait for, defer wg.Done() marks it complete when the function returns, and wg.Wait() blocks until the count hits zero. Notice the name is passed as a parameter into the closure rather than captured directly — that's intentional. Capturing the loop variable directly is a classic Go footgun (pre-1.22, every closure would share the same variable and you'd get the last value for everything). Passing it as an argument sidesteps that entirely, and is still good practice to know even on newer Go versions where the loop variable semantics changed.

Channels: Goroutines Talking to Each Other

WaitGroups tell you when things are done. Channels let goroutines actually communicate — passing data between them safely, without manual locks:

func main() {
    results := make(chan string, 3)

    go fetchAndSend("orders", results)
    go fetchAndSend("payments", results)
    go fetchAndSend("inventory", results)

    for i := 0; i < 3; i++ {
        fmt.Println(<-results)
    }
    close(results)
}

func fetchAndSend(name string, results chan<- string) {
    time.Sleep(100 * time.Millisecond)
    results <- fmt.Sprintf("%s: 200 OK", name)
}

A channel is a typed pipe. results <- value sends, <-results receives, and both block until someone's on the other end (unless the channel is buffered, like the make(chan string, 3) above, which allows up to 3 sends before blocking). The chan<- string parameter type is a send-only channel — a nice bit of compiler-enforced documentation saying "this function only writes here, it never reads."

This is the part that reframes concurrency entirely coming from Java. The Go proverb is "don't communicate by sharing memory, share memory by communicating" — instead of multiple threads fighting over a synchronized block or a ConcurrentHashMap, you pass ownership of data through a channel, one direction at a time. There's no lock to forget, because there's nothing shared to protect.

select: Handling Multiple Channels at Once

Once you have more than one channel, select lets you react to whichever one is ready first — it's the concurrency equivalent of a switch statement:

func main() {
    payments := make(chan string)
    timeout := time.After(2 * time.Second)

    go processPayment(payments)

    select {
    case result := <-payments:
        fmt.Println("payment result:", result)
    case <-timeout:
        fmt.Println("payment timed out")
    }
}

func processPayment(payments chan<- string) {
    time.Sleep(3 * time.Second) // simulate a slow downstream call
    payments <- "success"
}

This pattern — racing a real channel against time.After — is how Go handles timeouts idiomatically. No Future.get(timeout, unit) with a checked TimeoutException to catch. Just two channels and a select.

Where This Actually Bites You

I don't want to oversell this as friction-free, because it isn't. A few things I've already tripped over:

Goroutine leaks are real and easy to cause. If a goroutine is blocked sending on a channel that nobody's ever going to read from again, it just sits there forever, leaking memory. Unlike a thread pool with bounded size, there's no natural backpressure unless you design it in yourself — usually with buffered channels, context.Context cancellation, or both.

Deadlocks look different than JVM deadlocks. Instead of two threads each holding a lock the other wants, a Go deadlock is more often "every goroutine is blocked waiting on a channel, and nothing's left to unblock them." The runtime is actually good at detecting this for the simplest cases (fatal error: all goroutines are asleep - deadlock!), which is more help than the JVM ever gave me.

Unbuffered channels make ordering subtle. An unbuffered channel send blocks until a receiver is ready, which means the timing of goroutines relative to each other isn't always obvious from reading the code top to bottom. It took a few go run experiments with print statements before the mental model clicked.

go vet and the race detector are not optional. Running go run -race during development catches data races that would otherwise be silent and only show up under load in production. I now run it by default the way I'd run a linter.

Why This Matters for the Series

This concurrency model is going to show up constantly once I build a real API in part 5 — handling concurrent requests, fanning out to multiple downstream services, and managing timeouts cleanly are exactly what channels and select are built for. It's also a big part of why Go shows up so often in infra and backend tooling: the concurrency primitives are cheap enough that you reach for them by default, not just when you've hit a performance wall.

Next up in part 4: error handling. I promised in part 1 that if err != nil would get its own post, and after spending real time with goroutines that return errors over channels, I have a lot more sympathy for Go's approach than I expected to.

If you've worked with both JVM threads and goroutines, I'd like to know — did the "share memory by communicating" mental shift come naturally, or did you find yourself reaching for locks out of habit at first?

Go's Type System — Structs, Interfaces, and Life Without Inheritance

mihir mohapatra — Fri, 19 Jun 2026 06:53:06 +0000

Go's Type System — Structs, Interfaces, and Life Without Inheritance

In part 1 of this series I talked about why I'm picking up Go after six years of Java and Kotlin, plus a recent deep dive into Rust. This time I want to get into the part that actually changed how I think about designing code: Go has no class inheritance at all.

Coming from the JVM world, that sentence sounded alarming the first time I read it. No extends. No abstract classes. No polymorphism through a class hierarchy. And yet Go backends at companies running serious scale seem to do just fine without it. After a few weeks living inside Go's type system, I get why.

Structs: Data, Nothing More

A Go struct is just a typed bag of fields. No constructors, no access modifiers in the Java sense, no inheritance:

type Order struct {
    ID       string
    Customer string
    Amount   float64
    Status   string
}

func NewOrder(id, customer string, amount float64) Order {
    return Order{
        ID:       id,
        Customer: customer,
        Amount:   amount,
        Status:   "pending",
    }
}

That NewOrder function is doing the job a constructor would do in Java — it's just a plain function by convention, not a language feature. Nothing stops you from building an Order{} directly with zero values either, which takes some adjusting to if you're used to constructors enforcing invariants.

Methods attach to structs separately, outside the type definition:

func (o Order) Total() float64 {
    return o.Amount
}

func (o *Order) MarkPaid() {
    o.Status = "paid"
}

That (o Order) vs (o *Order) distinction is the receiver type, and it trips up a lot of newcomers. A value receiver gets a copy of the struct; a pointer receiver can mutate the original. MarkPaid has to use a pointer receiver, or the status change would vanish the moment the method returns.

No Inheritance, So What Replaces It?

This is the part that took the most rewiring. In Java, if PremiumOrder needed everything Order had plus more, you'd write class PremiumOrder extends Order. Go simply doesn't have that mechanism. Instead, you embed:

type PremiumOrder struct {
    Order
    Priority int
}

Embedding Order inside PremiumOrder promotes its fields and methods up to the outer struct. So premiumOrder.Total() and premiumOrder.Status just work, as if they were defined directly on PremiumOrder. It looks like inheritance from the outside, but it's composition under the hood — PremiumOrder has an Order, it doesn't become one. That distinction matters the moment you need polymorphism, which is where interfaces take over.

Interfaces: The Part That Actually Surprised Me

Here's the genuinely different idea in Go's type system. In Java or Kotlin, a class declares upfront which interfaces it implements — class PaymentProcessor implements Refundable. The relationship is explicit and lives at the definition site.

In Go, interfaces are satisfied implicitly. There's no implements keyword at all:

type Refundable interface {
    Refund(amount float64) error
}

type CardPayment struct {
    TransactionID string
}

func (c CardPayment) Refund(amount float64) error {
    fmt.Printf("Refunding %.2f for transaction %s\n", amount, c.TransactionID)
    return nil
}

CardPayment never mentions Refundable anywhere. It just happens to have a Refund(amount float64) error method, so it satisfies the interface automatically. Any type, anywhere in the codebase — even one you didn't write — can satisfy an interface it never knew existed:

func processRefund(r Refundable, amount float64) error {
    return r.Refund(amount)
}

processRefund(CardPayment{TransactionID: "txn_123"}, 49.99)

The first time I saw this, it felt like it would lead to chaos — how do you know what implements what? But in practice it flips the design direction in a useful way. Interfaces in Go tend to be small and defined by the consumer, not the producer. You don't design a sprawling PaymentProcessor interface upfront and force every payment type to conform to it. You write the function that needs a Refund method, declare a one-method interface for exactly that, and let any matching type plug in. The standard library leans hard into this — io.Reader and io.Writer are each a single method, and half of Go's ecosystem is built by composing those tiny interfaces together.

Putting It Together: Composition Over Inheritance, For Real

The Java-world mantra "favor composition over inheritance" is something I nodded along to for years while still reaching for extends out of habit. Go doesn't give you the option to reach for it — composition is the only tool on the table, so you actually use it.

A small example of how this plays out: instead of a BasePaymentHandler abstract class with CardHandler and BankTransferHandler subclasses overriding behavior, you'd define the shape you need as an interface and write independent structs that satisfy it:

type PaymentHandler interface {
    Process(amount float64) error
}

type CardHandler struct{}
func (CardHandler) Process(amount float64) error {
    fmt.Println("Processing card payment:", amount)
    return nil
}

type BankTransferHandler struct{}
func (BankTransferHandler) Process(amount float64) error {
    fmt.Println("Processing bank transfer:", amount)
    return nil
}

func charge(h PaymentHandler, amount float64) error {
    return h.Process(amount)
}

No shared base class, no super.Process() calls, no fragile hierarchy to untangle later when a new payment type doesn't quite fit the existing tree. Each handler is independent; the interface is just a contract describing what charge needs.

Where This Still Feels Unfamiliar

A few things haven't fully clicked yet, and I'd rather be honest about that than pretend the transition was seamless:

Implicit satisfaction makes "what implements this?" harder to answer. In an IDE-heavy Java workflow, "find implementations" is one click. In Go, you're often grepping for method signatures, since there's no declared relationship to search for. Tooling helps, but it's a different mental habit.

Embedding isn't inheritance, and pretending otherwise causes bugs. It's tempting to treat PremiumOrder embedding Order as "PremiumOrder is an Order," but method promotion doesn't give you real polymorphism — you can't pass a PremiumOrder somewhere that explicitly expects an Order type. It works at the field/method-access level only.

Zero values mean "uninitialized" can silently look valid. A struct field you forgot to set isn't null and isn't an error — it's just the zero value ("", 0, false). That's elegant in some ways and a quiet source of bugs in others, especially coming from a world where constructors enforce required fields.

Up Next

This composition-first, implicit-interface design is going to matter a lot once concurrency enters the picture, since goroutines and channels lean on small interfaces too. In part 3, I'm digging into goroutines and channels — and where Go's concurrency model genuinely outperforms the thread-pool mental model I'm used to from the JVM, plus where it bites if you're not careful.

If you've made the jump from Java, Kotlin, or another OOP-heavy language to Go, I'm curious — did implicit interfaces feel natural to you immediately, or did it take a few weeks to stop reaching for implements?

Why I'm Learning Go in 2026 (A Java/Kotlin/Rust Engineer's Take)

mihir mohapatra — Thu, 18 Jun 2026 11:07:12 +0000

Why I'm Learning Go in 2026 (A Java/Kotlin/Rust Engineer's Take)

I've spent the better part of six years writing Java and Kotlin in production — FinTech systems, logistics platforms, EdTech backends. Somewhere in the last year I also went deep on Rust, building an AI gateway and a RAG server from scratch. So the obvious question is: why pick up another language?

Short answer: because every team I want to work for in 2026 is either already running Go in production, or wishes they were.

This post kicks off a series where I document learning Go properly — not "hello world and a for loop" learning, but the kind that ends with a real, production-grade service. If you're a backend engineer coming from the JVM world (or from Rust, or anywhere else) and curious whether Go is worth the detour, this series is for you.

The Itch That Started This

Most of my recent work has been in Rust, and I love it — the type system catches entire categories of bugs before they ship, and the performance ceiling is hard to beat. But Rust also makes you pay for that safety in compile times, borrow-checker fights, and a learning curve that scares away a chunk of teams who'd otherwise want those benefits.

Go takes a different bet: give up some of that compile-time rigor, and in exchange get a language so simple you can read a stranger's codebase on day one. After enough job descriptions and system design conversations mentioning Go in the same breath as "we need to move fast and onboard people quickly," I stopped arguing with the trend and decided to just learn it properly.

What Go Actually Optimizes For

Coming from Java and Kotlin, the first thing that struck me wasn't a feature — it was an absence. No class hierarchies to design upfront. No generics-heavy abstractions to reach for by default. No build tool wars (Maven vs Gradle vs whatever). Go's design philosophy is almost stubbornly opinionated: there's one way to format code (gofmt decides, not you), one way to manage dependencies (Go modules), and a standard library that already does most of what you'd otherwise reach for a framework to do.

A quick side-by-side of what's missing compared to the JVM world tells you a lot about Go's priorities:

JVM World	Go World
Class inheritance	Composition + interfaces
Checked/unchecked exceptions	Explicit `error` return values
Threads + thread pools	Goroutines + channels
Maven/Gradle build config	`go.mod`, almost no config
Annotations for DI, validation, etc.	Plain functions, explicit wiring

None of this means Go is "Java but simpler" — it's a genuinely different way of thinking about structuring a backend service. The interface system in particular is going to get its own post, because it inverts how I'm used to designing for abstraction.

Concurrency Was the Real Hook

If I'm honest, goroutines are why I stopped procrastinating on this. In Java, concurrency means thinking about thread pools, ExecutorService, and increasingly, virtual threads if you're on a recent JDK. In Go, concurrency is baked into the language itself:

func main() {
    results := make(chan string)

    go fetchFromService("orders", results)
    go fetchFromService("payments", results)
    go fetchFromService("inventory", results)

    for i := 0; i < 3; i++ {
        fmt.Println(<-results)
    }
}

func fetchFromService(name string, results chan<- string) {
    // simulate a network call
    time.Sleep(100 * time.Millisecond)
    results <- fmt.Sprintf("%s: done", name)
}

Three goroutines, a channel to coordinate them, no thread pool configuration, no Future<T> wrapping. That's the entire concurrency model for a huge percentage of real-world backend use cases. I'll go deeper into goroutines and channels — including where they bite you — in part 3.

Where I Think Go Will Push Back

I don't want this series to read like a sales pitch, so here's what's already bothering me a few weeks in:

Error handling feels repetitive. Coming from exceptions, writing if err != nil { return err } after every single call feels almost aggressively manual. I know there are good reasons for it (explicit control flow, no hidden stack unwinding), but my fingers haven't agreed yet.

No generics-first mindset (still adjusting). Generics arrived in Go 1.18, but the standard library and most idiomatic code still leans on interfaces and any in ways that feel like a step back from Kotlin's type system or Rust's traits.

Smaller batteries-included story for some things. No built-in ORM, no Spring-style dependency injection container, no Rocket/Axum-style ergonomic web framework baked into std (though Gin and Echo close that gap fast).

I expect most of these complaints to soften as I get further in — they usually do.

What This Series Will Actually Build

Rather than a string of disconnected toy examples, this series builds toward one real artifact: a production-grade Go backend service, the same way I approached rust-ai-gateway and BlazeRAG. Here's the planned route:

Part 2 — Go's type system: structs, interfaces, and composition over inheritance
Part 3 — Goroutines and channels, and where naive concurrency breaks
Part 4 — Error handling patterns that don't make your code unreadable
Part 5 — Building a real REST API with Gin
Part 6 — Testing: table-driven tests, benchmarks, and go test habits
Part 7 — Turning all of it into a production-grade service, ready to ship

If you're also coming from Java, Kotlin, or Rust and weighing whether Go is worth the time, follow along — I'll be honest about what's genuinely better, what's just different, and what I still miss from the languages I came from.

What's been your experience picking up Go from a JVM or Rust background? I'd genuinely like to know what surprised you, good or bad.

I Built a Production-Grade AI Gateway in Rust — Here's What I Learned

mihir mohapatra — Wed, 10 Jun 2026 07:45:28 +0000

TL;DR — I built a production-ready, distributed API gateway in Rust that routes traffic to OpenAI, Anthropic (Claude), and Ollama with auth, Redis rate limiting, PostgreSQL usage tracking, Prometheus metrics, and AWS Terraform deployment. Gateway overhead is ~1.2ms P99. Here's why and how.

👉 GitHub: MihirMohapatra/rust-ai-gateway

The Problem I Kept Running Into

Six months ago, my team was using OpenAI directly in every service. Then we wanted to test Claude 3.5 Sonnet for some tasks. Then our compliance team asked: "Can you show me every AI request we've ever made?" Then someone ran a batch job and we got a surprise invoice.

Sound familiar?

The real problem wasn't any single API — it was that we had no control plane for our AI traffic. No unified auth, no rate limiting per team, no cost visibility, no ability to swap providers without touching application code.

I looked at existing solutions. Most are Python-based (LiteLLM), or Go-based (Kong), or SaaS (Portkey). Nothing was Rust. Nothing had the full stack I wanted in a single deployable binary — auth, rate limiting, observability, multi-provider routing, and cloud IaC — without a subscription.

So I built one.

What It Does (10-Second Version)

Your App  →  AI Gateway  →  OpenAI (GPT-4, o1, o3)
                         →  Anthropic (Claude 3.5 Sonnet, Opus, Haiku)
                         →  Ollama (Llama3, Mistral, local models)

It's an OpenAI-compatible drop-in replacement. Change one line in your existing code — the base_url — and you instantly get:

Per-key API authentication (Argon2id hashed)
Redis sliding window rate limiting
Full request/token audit trail in PostgreSQL
Prometheus metrics + pre-built Grafana dashboards
Distributed tracing via X-Request-ID
Docker + AWS ECS Fargate deployment with Terraform

Why Rust? (The Real Answer)

I've shipped services in Java, Kotlin, Python, and Go. The honest answer to "why Rust" isn't idealism — it's that this specific problem punishes GC pauses.

An AI gateway sits in the hot path of every LLM call. When your app fires 50 concurrent requests, the gateway's tail latency becomes your app's tail latency. GC-induced pauses at P99 compound badly in this scenario.

Here's what I measured after building the Rust version:

Metric	Rust (This Project)	Typical Node.js	Typical Go
Memory (idle)	12 MB	80–150 MB	20–30 MB
Memory (10k connections)	45 MB	500+ MB	100–150 MB
P99 latency (gateway overhead)	1.2 ms	8–15 ms	2–4 ms
Startup time	50 ms	2–5 seconds	200 ms
Binary size	8 MB	200+ MB (node_modules)	15 MB

The 12 MB idle footprint means I can run this on the cheapest ECS Fargate task (0.5 vCPU / 1 GB RAM) and still have headroom for hundreds of concurrent requests.

But the real win was correctness under concurrency. The rate limiter touches Redis on every request across multiple gateway nodes. In Go or Node I'd be paranoid about races. In Rust, the compiler simply won't compile a race condition. That's not a cliché — it meant I could build the distributed rate limiter without a single Mutex in the business logic, because the ownership model forced me into the right design.

Architecture Deep Dive

The Request Pipeline

Every request flows through a layered middleware stack before hitting a provider:

Client Request
     │
     ▼
1. Request ID         ── Assigns UUID, injects X-Request-ID header
2. Tracing Layer      ── Structured span for each request
3. Compression        ── gzip on responses
4. 60s Timeout        ── Hard stop, prevents hung connections
5. Auth Middleware    ── Validates API key with Argon2id
6. Rate Limiter       ── Redis sliding window per key
7. Provider Router    ── Routes by model name → OpenAI/Anthropic/Ollama
8. Proxy Request      ── Forwards to upstream
9. Usage Logging      ── Async insert to PostgreSQL
10. Metrics Update    ── Prometheus counters + histograms

Step 5 and 6 are the interesting ones.

Authentication: Why Argon2id?

The industry standard for password hashing is Argon2id — it won the Password Hashing Competition for a reason. But for API keys, most people just use bcrypt or, worse, store a plain SHA256 hash. Here I used Argon2id because:

Memory-hard — GPU-based brute force is expensive
Configurable parallelism and memory cost
The argon2 crate is excellent in the Rust ecosystem

On key creation, only the hash is stored. On every request, the presented key is verified with argon2::verify_encoded(). The raw key never hits the database — not even once.

// Key creation: hash and store
let salt = SaltString::generate(&mut OsRng);
let argon2 = Argon2::default();
let hash = argon2.hash_password(raw_key.as_bytes(), &salt)?.to_string();
sqlx::query!(
    "INSERT INTO api_keys (user_id, key_hash, prefix, name) VALUES ($1, $2, $3, $4)",
    user_id, hash, &prefix, key_name
).execute(&pool).await?;

// Verification on every request — no raw key ever touches the DB
let is_valid = argon2::verify_encoded(&stored_hash, presented_key.as_bytes())?;

Rate Limiting: Redis Sliding Window

Fixed window rate limiting has an edge case that'll bite you: a burst of 2× the limit can happen right across a window boundary. Sliding window fixes this.

The implementation uses a Redis sorted set per API key. On each request:

Remove all entries older than the window (currently 60 seconds)
Count remaining entries
If count ≥ limit → reject with 429
Otherwise add current timestamp and continue

let now = SystemTime::now()
    .duration_since(UNIX_EPOCH)?
    .as_millis() as f64;
let window_start = now - (window_seconds * 1000) as f64;

let (count,): (i64,) = redis::pipe()
    .zrembyscore(&key, 0.0, window_start)   // evict old entries
    .ignore()
    .zcard(&key)                              // count current
    .query_async(&mut conn)
    .await?;

if count >= limit as i64 {
    return Err(AppError::RateLimitExceeded { limit, window_seconds });
}

// Add current request timestamp
conn.zadd(&key, now, now).await?;
conn.expire(&key, window_seconds as usize + 1).await?;

All of this runs atomically per request. Because multiple gateway nodes share the same Redis, rate limiting is globally consistent across horizontal replicas.

Multi-Provider Routing

Provider selection is purely model-name-driven — no configuration per-request:

pub fn select_provider(model: &str) -> Provider {
    if model.starts_with("gpt-") || model.starts_with("o1") || model.starts_with("o3") {
        Provider::OpenAI
    } else if model.starts_with("claude-") {
        Provider::Anthropic
    } else {
        Provider::Ollama  // default: local
    }
}

This means you can A/B test gpt-4 vs claude-3-5-sonnet vs llama3 from a single endpoint — just change the model field. No infrastructure changes, no redeploys.

The Workspace Architecture

The project is a Cargo workspace with three crates:

crates/
├── gateway/      # Main binary — routes, middleware, HTTP server
├── shared/       # Library — domain models, provider clients, errors
└── dashboard/    # HTMX metrics dashboard (separate binary)

Splitting shared out was intentional. The provider clients (OpenAI, Anthropic, Ollama) are pure reqwest + serde with no web framework dependency. This means I can test provider logic without spinning up an HTTP server. It also means the dashboard can import usage stats without duplicating types.

The gateway crate's state is a single AppState struct passed through Axum's Extension:

#[derive(Clone)]
pub struct AppState {
    pub db: PgPool,
    pub redis: ConnectionManager,
    pub config: Arc<Config>,
}

Clone is Arc under the hood for the pool and connection manager — cheap shared ownership across async tasks, zero allocation per request.

Observability: What I Actually Instrument

Every production service eventually asks: "Why was that request slow?" You want to answer that without waking anyone up.

Structured logging — In production, every request emits a JSON log line:

{
  "timestamp": "2026-05-31T10:30:00.000Z",
  "level": "INFO",
  "message": "Chat completion completed",
  "model": "gpt-4",
  "provider": "openai",
  "latency_ms": 1250,
  "prompt_tokens": 45,
  "completion_tokens": 120,
  "request_id": "550e8400-e29b-41d4-a716-446655440000"
}

That request_id is injected by the first middleware and propagated through the upstream provider call. When something goes wrong, you grep by request_id and get the full trace across logs.

Prometheus metrics — Four metrics I actually care about for an AI gateway:

Metric	Why It Matters
`gateway_requests_total{model,provider,status}`	Per-model error rates
`gateway_request_duration_ms` (histogram)	P50/P99 latency breakdown
`gateway_tokens_total{model}`	Cost attribution
Rate limit rejection rate	Detect runaway clients

Grafana comes pre-provisioned via monitoring/grafana/provisioning/. One docker-compose up and you have a live dashboard. No manual datasource setup.

Health Probes: Liveness vs Readiness

This distinction matters in Kubernetes and ECS, and most tutorials get it wrong.

GET /health/live — Returns 200 as long as the process is running. Never checks external deps. This is what your orchestrator uses to decide whether to kill and restart the task.

GET /health/ready — Returns 200 only if the database is reachable. This is what your load balancer uses to decide whether to send traffic. If the DB connection pool is exhausted, this fails and the LB stops routing to that instance.

// Readiness: check DB before accepting traffic
async fn health_ready(State(state): State<AppState>) -> impl IntoResponse {
    match sqlx::query("SELECT 1").fetch_one(&state.db).await {
        Ok(_) => StatusCode::OK,
        Err(_) => StatusCode::SERVICE_UNAVAILABLE,
    }
}

AWS Deployment (Terraform)

The infrastructure is fully defined in infra/main.tf:

Internet → ALB → ECS Fargate (2+ tasks) → RDS PostgreSQL
                                         → ElastiCache Redis

A few decisions worth calling out:

ECS Fargate over EC2 — No instance management, no capacity reservations. The gateway is stateless, so horizontal scaling is just bumping the desired task count. The Rust binary's 50ms cold start means new tasks are ready quickly.

RDS over self-managed Postgres — The usage logs table will grow. Automated backups, point-in-time recovery, and Multi-AZ are worth the cost for a service where audit trails matter.

ElastiCache Redis over self-managed — The rate limiter's correctness depends on Redis. Managed Redis with automatic failover means a Redis restart doesn't briefly disable rate limiting for all keys.

Testing: The Three Layers

The test suite has a clear pyramid:

Unit tests      — Zero I/O. Config parsing, provider routing logic,
                  request/response serialization.

Mock tests      — Wiremock HTTP server standing in for OpenAI/Ollama.
                  Provider clients tested in isolation.

Integration     — Real PostgreSQL + Redis (via Docker Compose).
                  Full auth, rate limit, stats endpoint flows.

The mock tests were the most valuable. I caught a bug where the Anthropic client was sending the max_tokens field in the wrong position for the Messages API. Unit tests wouldn't have caught it. Integration tests against the real Anthropic API would've been slow and flaky. Wiremock was the right tool.

# Run the full suite
./scripts/test.sh all

# Or just the mocks (fast, no external deps)
cargo test --package gateway --test provider_test

Performance Benchmarks

Gateway overhead only (not provider latency):

Metric	Value
Throughput (health endpoint)	~45,000 req/s
P50 latency	0.3 ms
P99 latency	1.2 ms
Memory at idle	12 MB
Memory at 10k concurrent	45 MB
Binary startup	< 50 ms

The 45 MB at 10k connections is the number that keeps surprising people. Node.js would be well past 500 MB at that concurrency. The difference isn't algorithmic — it's that Rust async tasks have a few hundred bytes of stack per task vs megabytes in thread-per-connection models.

What I'd Add Next

The project is production-ready today, but a few things are on the roadmap:

Streaming support — The current implementation buffers the full response before returning. For long Claude/GPT outputs, you want text/event-stream SSE forwarding so the client sees tokens as they arrive.

Token budget enforcement — Right now rate limiting is request-based. A more useful primitive for AI gateways is token-based budgets: "this key can spend 1M tokens/day."

Retry with fallback — If OpenAI returns a 503, automatically retry with Ollama. The provider abstraction is already in place; it just needs a retry policy layer.

Prompt caching metrics — Anthropic and OpenAI both have prompt caching. Tracking cache hit rates per key would give teams actionable cost reduction data.

Quick Start

git clone https://github.com/MihirMohapatra/rust-ai-gateway
cd rust-ai-gateway
cp .env.example .env
# Add your OPENAI_API_KEY and ANTHROPIC_API_KEY (both optional)
docker-compose up -d
curl http://localhost:3000/health

Grafana dashboard at http://localhost:3002 (admin/admin).

curl -X POST http://localhost:3000/auth/register \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com", "password": "secure-pass"}'

curl -X POST http://localhost:3000/auth/keys \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com", "password": "secure-pass", "key_name": "dev"}'

Point your existing OpenAI SDK at it:

from openai import OpenAI

client = OpenAI(
    api_key="aig_your_key_here",
    base_url="http://localhost:3000/v1"  # ← Only this line changes
)
# Everything else stays the same

Closing Thoughts

Building this forced me to think seriously about what "production-grade" actually means for infrastructure software. It's not just "it works." It's:

Observability first — You need to know what it's doing before it fails, not after
Failure modes are designed, not discovered — Graceful shutdown, circuit breaking, liveness vs readiness
Security is structural — Argon2id isn't a detail; it's the only defensible choice
Benchmarks are hypotheses — The 45 MB memory number is only meaningful relative to alternatives

If you're building AI-powered products and you're hitting the "which provider do I use and how do I track it" question, I hope this gives you a usable starting point.

Star the repo if it's useful, open issues if you find gaps, and PRs are welcome — especially for the streaming feature.

I'm a Senior Backend Engineer with a background in FinTech (HSBC, Westpac, FedEx) currently building AI/ML infrastructure in Rust and Go. Open to senior backend and AI infra roles with US/EU remote companies.

Find me on GitHub or LinkedIn.

I Built a Production-Oriented Multi-Provider AI Chatbot in Rust — Here's How

mihir mohapatra — Sun, 31 May 2026 05:49:53 +0000

Most AI chatbot tutorials reach for Python. FastAPI, LangChain, a quick requests.post — done in 20 minutes. And that's fine for prototyping. But when I wanted to build something I'd actually put behind a real API — something with proper async concurrency, typed errors, and zero GC pauses — I reached for Rust instead.

This is a writeup of chatbot, a production-oriented Rust backend that unifies Claude, OpenAI, and Ollama behind a single interface — with a Web UI, CLI mode, and Docker support baked in.

Why Rust for an AI Backend?

It's a fair question. LLM API calls are network-bound, so why does the backend language even matter?

A few reasons:

Predictable latency. No GC pauses under load means P99 response times stay stable when you're handling dozens of concurrent conversations.
Memory efficiency. Each async task in Tokio is dramatically cheaper than a Python thread. You serve more users per instance.
Type safety. Rust's ownership model makes API contracts explicit. You can't accidentally share mutable conversation state across requests — the compiler enforces it.
Long-term maintainability. Explicit types and explicit error handling make the code self-documenting.

For LLM apps specifically: yes, 95% of your wall-clock time is waiting for the model to respond. But the other 5% — routing, state management, provider selection, connection handling — is all yours to control. Rust makes that part bulletproof.

What It Does

Connects to Claude (Anthropic), OpenAI, or Ollama (local) via a unified chat interface
Serves a Web UI at http://localhost:8080 by default, or runs in CLI mode
Maintains per-session conversation history in memory
Supports runtime provider switching via a connect-first flow
Ships with a Dockerfile for containerized deployment
Supports OpenRouter as an OpenAI-compatible provider

Architecture Overview

User (Browser or CLI)
        │
        ▼
  Axum HTTP Server (web.rs)
        │
        ├──▶ Conversation State (Arc<Mutex<Vec<Message>>>)
        │
        └──▶ Runtime Config (config.rs)
                    │
                    ▼
            ChatClient (client.rs)
                    │
           ┌────────┼────────┐
           ▼        ▼        ▼
        Claude   OpenAI   Ollama
         API      API      API

The project has a clean five-module layout in src/:

src/
├── main.rs          # Startup routing + CLI loop
├── config.rs        # Provider enum + env/runtime config
├── client.rs        # Provider-specific HTTP clients
├── conversation.rs  # In-memory chat state model
└── web.rs           # Axum routes, connect flow, chat API

Each module has exactly one responsibility. No god objects, no tangled imports.

The Provider Abstraction

The heart of the project is client.rs. Instead of sprinkling provider-specific logic everywhere, all outbound AI calls go through a single ChatClient that dispatches based on the active provider.

The key insight: Claude uses the Anthropic native API format, while OpenAI and Ollama both speak the OpenAI-compatible schema. Separating these two code paths keeps the provider logic honest — you're not faking compatibility where there isn't any.

// Simplified concept from client.rs
pub enum Provider {
    Claude,
    OpenAI,
    Ollama,
}

pub struct ChatClient {
    pub provider: Provider,
    pub model: String,
    pub base_url: String,
    pub api_key: Option<String>,
    pub max_tokens: u32,
    pub system_prompt: String,
    pub http: reqwest::Client,
}

When you send a message, the client picks the right HTTP contract:

pub async fn send(&self, messages: &[Message]) -> Result<String> {
    match self.provider {
        Provider::Claude => self.send_claude(messages).await,
        Provider::OpenAI | Provider::Ollama => self.send_openai_compat(messages).await,
    }
}

This means adding a new provider (Gemini, Cohere, etc.) in the future is a matter of adding one arm and one method — the rest of the application stays untouched.

Shared Conversation State

Multi-turn chat requires persistent message history. In Rust's async model, sharing state across request handlers requires explicit synchronization. The project does this with Arc<Mutex<...>>, Rust's standard pattern for shared mutable state:

// conversation.rs - shared across all handlers
pub type SharedConversation = Arc<Mutex<Vec<Message>>>;

#[derive(Clone, Debug, Serialize, Deserialize)]
pub struct Message {
    pub role: String,    // "user" or "assistant"
    pub content: String,
}

The Arc makes the conversation cloneable across Axum handlers (each handler runs in its own async task), and the Mutex ensures only one handler touches the history at a time. No race conditions, guaranteed by the type system.

Dual-Mode: Web UI + CLI

The app launches in Web UI mode by default, but also supports a terminal workflow:

# Default: serves Web UI at http://localhost:8080
cargo run

# CLI mode: interactive terminal chat
cargo run -- cli

# Explicit web mode on a custom port
PORT=3000 cargo run -- web

This is useful in different contexts — the Web UI for demos and sharing, the CLI for scripting and piping into other tools.

Quick Start

Option A: No Rust Required

Download the prebuilt Windows executable (v1.0.1) and run it:

.\chatbot.exe
# Opens http://localhost:8080

Option B: From Source

# 1. Install Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# 2. Clone and configure
git clone https://github.com/MihirMohapatra/chatbot.git
cd chatbot
cp .env.example .env

# 3. Run
cargo run

Provider Configuration

Set your provider in .env:

Claude (Anthropic)

PROVIDER=claude
ANTHROPIC_API_KEY=sk-ant-...

OpenAI

PROVIDER=openai
OPENAI_API_KEY=sk-...

Ollama (Local — no API key needed)

# Pull a model first
ollama pull llama3.2

PROVIDER=ollama
MODEL=llama3.2

OpenRouter (access any model via OpenAI-compatible API)

PROVIDER=openai
OPENAI_API_KEY=sk-or-...
BASE_URL=https://openrouter.ai/api
MODEL=anthropic/claude-sonnet-4

All environment variables:

Variable	Default	Description
`PROVIDER`	`claude`	`claude`, `openai`, `ollama`
`ANTHROPIC_API_KEY`	—	Required for Claude
`OPENAI_API_KEY`	—	Required for OpenAI
`MODEL`	provider default	Override the model name
`BASE_URL`	provider default	Override the API endpoint
`MAX_TOKENS`	`1024`	Response token cap
`SYSTEM_PROMPT`	built-in	Custom assistant behavior

Docker

docker build -t chatbot .
docker run -it --rm -v .env:/data/.env chatbot

For Ollama with host networking:

docker run -it --rm --network host -v .env:/data/.env chatbot

Rust vs Python: Backend Performance Perspective

For backend workloads like this (concurrent HTTP + JSON + state management), Rust consistently outperforms Python across the metrics that matter in production:

Metric	Rust	Python	Why It Matters
Throughput (req/sec)	Higher	Lower	More concurrent users per instance
P95/P99 latency	Lower under load	Higher under load	More stable response times
Memory per worker	Lower	Higher	Better infra cost and density
CPU efficiency	Higher	Lower	More headroom before scaling out

Note: For LLM apps, model/API network time dominates total latency. But Rust still wins on concurrency behavior, memory footprint, and server efficiency — which directly impacts cost and reliability at scale.

What's Next (Roadmap)

Streamed responses — token-by-token streaming via SSE
Persistent chat history — SQLite or Postgres backend
Metrics + tracing — tracing crate + OpenTelemetry integration
Integration tests for provider adapters

Try It / Contribute

The project is open source and MIT licensed:

👉 github.com/MihirMohapatra/chatbot

If you're exploring Rust for backend systems, or building something that needs to talk to multiple AI providers without writing boilerplate for each one, this is a good starting point. Issues and PRs welcome.

Built with Rust 1.80+, Tokio, Axum, reqwest, serde, and anyhow.

Rust Concepts: Serde, Error Handling, Benchmarking & Workspaces (Part 6)

mihir mohapatra — Mon, 25 May 2026 06:16:23 +0000

This is Part 6 — the final part of the Core Rust Concepts series.

Part 1 — Ownership, Borrowing, Lifetimes, Traits, Result/Option, Pattern Matching

Part 2 — Closures, Iterators, Generics, Enums, Smart Pointers, Async/Await

Part 3 — Macros, Modules, Testing, Unsafe Rust, FFI

Part 4 — Threads, Channels, Send/Sync, Mutex, Atomics, clap

Part 5 — dyn Trait, Deref, Drop, Custom Iterators, Axum REST API

Serde — Serialization Deep Dive
Error Handling with thiserror and anyhow
Benchmarking with Criterion
Workspaces & Multi-Crate Projects
Writing a Real-World CLI + Library Crate

30. Serde — Serialization Deep Dive

serde is Rust's de-facto serialization framework. It supports JSON, TOML, YAML, MessagePack, Bincode, and dozens of other formats — all from the same #[derive] annotations.

Setup

[dependencies]
serde       = { version = "1", features = ["derive"] }
serde_json  = "1"
toml        = "0.8"

Basic serialize / deserialize

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct User {
    id: u32,
    name: String,
    email: String,
    active: bool,
}

fn main() {
    let user = User {
        id: 1,
        name: String::from("Alice"),
        email: String::from("alice@example.com"),
        active: true,
    };

    // Struct → JSON string
    let json = serde_json::to_string_pretty(&user).unwrap();
    println!("{json}");

    // JSON string → Struct
    let json_str = r#"{"id":2,"name":"Bob","email":"bob@example.com","active":false}"#;
    let parsed: User = serde_json::from_str(json_str).unwrap();
    println!("{:?}", parsed);
}

Output:

{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com",
  "active": true
}

Field attributes

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct Article {
    #[serde(rename = "article_id")]
    id: u32,

    title: String,

    #[serde(skip_serializing_if = "Option::is_none")]
    subtitle: Option<String>,

    #[serde(default)]
    published: bool,

    #[serde(skip)]
    internal_notes: String, // never included in JSON

    #[serde(rename = "created_at")]
    created: String,
}

fn main() {
    let article = Article {
        id: 42,
        title: String::from("Learning Rust"),
        subtitle: None,             // skipped in output
        published: true,
        internal_notes: String::from("draft"), // skipped
        created: String::from("2026-01-01"),
    };

    println!("{}", serde_json::to_string_pretty(&article).unwrap());
}

Output:

{
  "article_id": 42,
  "title": "Learning Rust",
  "published": true,
  "created_at": "2026-01-01"
}

Enums with serde

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
#[serde(tag = "type", content = "data")]
enum Event {
    UserCreated { user_id: u32, name: String },
    OrderPlaced { order_id: u32, total: f64 },
    PageViewed(String),
}

fn main() {
    let events = vec![
        Event::UserCreated { user_id: 1, name: String::from("Alice") },
        Event::OrderPlaced { order_id: 99, total: 49.95 },
        Event::PageViewed(String::from("/home")),
    ];

    for e in &events {
        println!("{}", serde_json::to_string(e).unwrap());
    }
}

Output:

{"type":"UserCreated","data":{"user_id":1,"name":"Alice"}}
{"type":"OrderPlaced","data":{"order_id":99,"total":49.95}}
{"type":"PageViewed","data":"/home"}

Custom serialize / deserialize

use serde::{Deserialize, Deserializer, Serialize, Serializer};

#[derive(Debug)]
struct Rgb(u8, u8, u8);

impl Serialize for Rgb {
    fn serialize<S: Serializer>(&self, s: S) -> Result<S::Ok, S::Error> {
        s.serialize_str(&format!("#{:02X}{:02X}{:02X}", self.0, self.1, self.2))
    }
}

impl<'de> Deserialize<'de> for Rgb {
    fn deserialize<D: Deserializer<'de>>(d: D) -> Result<Self, D::Error> {
        let s = String::deserialize(d)?;
        let hex = s.trim_start_matches('#');
        let r = u8::from_str_radix(&hex[0..2], 16).map_err(serde::de::Error::custom)?;
        let g = u8::from_str_radix(&hex[2..4], 16).map_err(serde::de::Error::custom)?;
        let b = u8::from_str_radix(&hex[4..6], 16).map_err(serde::de::Error::custom)?;
        Ok(Rgb(r, g, b))
    }
}

fn main() {
    let color = Rgb(255, 128, 0);
    let json = serde_json::to_string(&color).unwrap();
    println!("{json}"); // "#FF8000"

    let back: Rgb = serde_json::from_str(&json).unwrap();
    println!("{:?}", back); // Rgb(255, 128, 0)
}

Working with dynamic JSON (`serde_json::Value`)

use serde_json::{json, Value};

fn main() {
    // Build JSON with the json! macro
    let payload = json!({
        "name": "Alice",
        "scores": [98, 87, 95],
        "meta": { "verified": true }
    });

    // Navigate dynamically
    println!("{}", payload["name"]);             // "Alice"
    println!("{}", payload["scores"][0]);         // 98
    println!("{}", payload["meta"]["verified"]);  // true

    // Merge two JSON objects
    let mut base: Value = json!({ "a": 1, "b": 2 });
    let extra: Value    = json!({ "b": 99, "c": 3 });

    if let (Value::Object(base_map), Value::Object(extra_map)) = (&mut base, extra) {
        base_map.extend(extra_map);
    }

    println!("{}", serde_json::to_string_pretty(&base).unwrap());
    // { "a": 1, "b": 99, "c": 3 }
}

31. Error Handling with thiserror and anyhow

Rust's Result<T, E> is powerful but verbose when you have many error types. Two crates solve this cleanly — thiserror for library authors, anyhow for application code.

[dependencies]
thiserror = "1"
anyhow    = "1"

thiserror — define your own error types

use thiserror::Error;

#[derive(Debug, Error)]
enum AppError {
    #[error("user not found: id={0}")]
    UserNotFound(u32),

    #[error("database error: {0}")]
    Database(#[from] std::io::Error),

    #[error("invalid email: {email}")]
    InvalidEmail { email: String },

    #[error("permission denied for user {user_id} on resource {resource}")]
    PermissionDenied { user_id: u32, resource: String },
}

fn find_user(id: u32) -> Result<String, AppError> {
    if id == 0 {
        return Err(AppError::UserNotFound(id));
    }
    Ok(format!("user_{id}"))
}

fn validate_email(email: &str) -> Result<(), AppError> {
    if !email.contains('@') {
        return Err(AppError::InvalidEmail { email: email.to_string() });
    }
    Ok(())
}

fn main() {
    match find_user(0) {
        Ok(u)  => println!("found: {u}"),
        Err(e) => println!("error: {e}"), // "error: user not found: id=0"
    }

    if let Err(e) = validate_email("notanemail") {
        println!("{e}"); // "invalid email: notanemail"
    }
}

anyhow — ergonomic error handling in applications

use anyhow::{anyhow, bail, Context, Result};
use std::fs;

fn read_config(path: &str) -> Result<String> {
    let content = fs::read_to_string(path)
        .with_context(|| format!("failed to read config from '{path}'"))?;

    if content.is_empty() {
        bail!("config file '{path}' is empty");
    }

    Ok(content)
}

fn parse_port(s: &str) -> Result<u16> {
    s.parse::<u16>()
        .map_err(|_| anyhow!("'{}' is not a valid port number (0–65535)", s))
}

fn main() -> Result<()> {
    // anyhow::Result as the return type of main — shows a clean error message
    let config = read_config("config.toml")
        .context("startup failed")?;

    println!("config loaded: {} bytes", config.len());

    let port = parse_port("8080")?;
    println!("listening on port {port}");

    Ok(())
}

thiserror vs anyhow — when to use which

	`thiserror`	`anyhow`
Best for	Libraries	Applications / binaries
Error type	Typed, structured `enum`	Opaque `anyhow::Error`
Callers can match on variants	✅	❌
Context chaining	Manual	`.context()` built-in
Boilerplate	Low	Minimal

Combining both

// In your library: typed errors with thiserror
#[derive(Debug, thiserror::Error)]
pub enum DbError {
    #[error("connection failed: {0}")]
    Connection(String),
    #[error("query failed: {0}")]
    Query(String),
}

// In your binary: use anyhow to wrap everything
fn run() -> anyhow::Result<()> {
    let result: Result<(), DbError> = Err(DbError::Connection("timeout".into()));
    result?; // DbError converts into anyhow::Error automatically
    Ok(())
}

32. Benchmarking with Criterion

criterion is the standard Rust benchmarking library. It runs each benchmark many times, measures variance, detects regressions, and generates HTML reports.

[dev-dependencies]
criterion = { version = "0.5", features = ["html_reports"] }

[[bench]]
name    = "my_benchmark"
harness = false

Basic benchmark

// benches/my_benchmark.rs
use criterion::{black_box, criterion_group, criterion_main, Criterion};

fn fibonacci(n: u64) -> u64 {
    match n {
        0 => 0,
        1 => 1,
        n => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

fn fibonacci_iter(n: u64) -> u64 {
    let (mut a, mut b) = (0u64, 1u64);
    for _ in 0..n { (a, b) = (b, a + b); }
    a
}

fn bench_fibonacci(c: &mut Criterion) {
    let mut group = c.benchmark_group("fibonacci");

    group.bench_function("recursive n=20", |b| {
        b.iter(|| fibonacci(black_box(20)))
    });

    group.bench_function("iterative n=20", |b| {
        b.iter(|| fibonacci_iter(black_box(20)))
    });

    group.finish();
}

criterion_group!(benches, bench_fibonacci);
criterion_main!(benches);

cargo bench

Sample output:

fibonacci/recursive n=20  time: [123.45 µs 124.12 µs 124.89 µs]
fibonacci/iterative n=20  time: [  1.23 ns   1.24 ns   1.25 ns]

Performance has improved: iterative is 100000x faster.

Benchmarking with input sizes

use criterion::{black_box, criterion_group, criterion_main, BenchmarkId, Criterion};

fn sum_vec(v: &[i32]) -> i32 { v.iter().sum() }

fn bench_sum(c: &mut Criterion) {
    let mut group = c.benchmark_group("vec_sum");

    for size in [100, 1_000, 10_000, 100_000] {
        let data: Vec<i32> = (0..size).collect();

        group.bench_with_input(
            BenchmarkId::new("sum", size),
            &data,
            |b, v| b.iter(|| sum_vec(black_box(v))),
        );
    }

    group.finish();
}

criterion_group!(benches, bench_sum);
criterion_main!(benches);

What `black_box` does

black_box(x) prevents the compiler from optimizing away the computation. Without it, the compiler might realize the result is unused and eliminate the benchmark entirely, giving you falsely fast timings.

// ❌ Compiler may optimize this to nothing
b.iter(|| fibonacci(20));

// ✅ Forces the computation to actually run
b.iter(|| fibonacci(black_box(20)));

33. Workspaces & Multi-Crate Projects

As projects grow, you split them into multiple crates in a Cargo workspace. All crates share one Cargo.lock and one target/ directory — so they share compiled dependencies and build faster.

Workspace layout

my_project/
├── Cargo.toml          ← workspace root
├── crates/
│   ├── core/           ← shared library
│   │   ├── Cargo.toml
│   │   └── src/
│   │       └── lib.rs
│   ├── cli/            ← binary using core
│   │   ├── Cargo.toml
│   │   └── src/
│   │       └── main.rs
│   └── api/            ← web server using core
│       ├── Cargo.toml
│       └── src/
│           └── main.rs

Root Cargo.toml

# Cargo.toml (workspace root)
[workspace]
members = [
    "crates/core",
    "crates/cli",
    "crates/api",
]
resolver = "2"

# Shared dependency versions across all crates
[workspace.dependencies]
serde     = { version = "1", features = ["derive"] }
tokio     = { version = "1", features = ["full"] }
anyhow    = "1"
thiserror = "1"

core/Cargo.toml

[package]
name    = "core"
version = "0.1.0"
edition = "2021"

[dependencies]
serde     = { workspace = true }
thiserror = { workspace = true }

cli/Cargo.toml

[package]
name    = "cli"
version = "0.1.0"
edition = "2021"

[dependencies]
core   = { path = "../core" }
anyhow = { workspace = true }
clap   = { version = "4", features = ["derive"] }

Sharing types across crates

// crates/core/src/lib.rs
use serde::{Deserialize, Serialize};
use thiserror::Error;

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct User {
    pub id: u32,
    pub name: String,
    pub email: String,
}

#[derive(Debug, Error)]
pub enum CoreError {
    #[error("user not found: {0}")]
    NotFound(u32),
    #[error("invalid input: {0}")]
    InvalidInput(String),
}

pub fn find_user(id: u32) -> Result<User, CoreError> {
    if id == 0 {
        return Err(CoreError::NotFound(id));
    }
    Ok(User { id, name: format!("user_{id}"), email: format!("user{id}@example.com") })
}

// crates/cli/src/main.rs
use clap::Parser;
use core::{find_user, CoreError};

#[derive(Parser)]
struct Cli {
    #[arg(short, long)]
    id: u32,
}

fn main() {
    let cli = Cli::parse();
    match find_user(cli.id) {
        Ok(user)  => println!("Found: {} <{}>", user.name, user.email),
        Err(CoreError::NotFound(id)) => eprintln!("No user with id {id}"),
        Err(e)    => eprintln!("Error: {e}"),
    }
}

Useful workspace commands

# Build all crates
cargo build --workspace

# Test all crates
cargo test --workspace

# Run a specific crate's binary
cargo run -p cli -- --id 42

# Check all without building
cargo check --workspace

# Lint everything
cargo clippy --workspace

# Format everything
cargo fmt --all

34. Writing a Real-World CLI + Library Crate

Putting it all together — a filestat tool that analyzes text files and exposes its logic as a reusable library.

Library: `crates/filestat-core/src/lib.rs`

use serde::Serialize;
use std::collections::HashMap;
use thiserror::Error;

#[derive(Debug, Error)]
pub enum StatError {
    #[error("could not read file '{path}': {source}")]
    Io { path: String, #[source] source: std::io::Error },
    #[error("file '{0}' is empty")]
    Empty(String),
}

#[derive(Debug, Serialize)]
pub struct FileStats {
    pub path: String,
    pub lines: usize,
    pub words: usize,
    pub chars: usize,
    pub unique_words: usize,
    pub top_words: Vec<(String, usize)>,
}

pub fn analyze(path: &str) -> Result<FileStats, StatError> {
    let content = std::fs::read_to_string(path)
        .map_err(|e| StatError::Io { path: path.to_string(), source: e })?;

    if content.trim().is_empty() {
        return Err(StatError::Empty(path.to_string()));
    }

    let lines = content.lines().count();
    let chars = content.chars().count();

    let words: Vec<&str> = content
        .split_whitespace()
        .collect();

    let word_count = words.len();

    let mut freq: HashMap<String, usize> = HashMap::new();
    for word in &words {
        let clean = word.to_lowercase()
            .trim_matches(|c: char| !c.is_alphanumeric())
            .to_string();
        if !clean.is_empty() {
            *freq.entry(clean).or_insert(0) += 1;
        }
    }

    let unique_words = freq.len();

    let mut top_words: Vec<(String, usize)> = freq.into_iter().collect();
    top_words.sort_by(|a, b| b.1.cmp(&a.1));
    top_words.truncate(5);

    Ok(FileStats {
        path: path.to_string(),
        lines,
        words: word_count,
        chars,
        unique_words,
        top_words,
    })
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_basic_stats() {
        use std::io::Write;
        let mut f = tempfile::NamedTempFile::new().unwrap();
        writeln!(f, "hello world hello rust world world").unwrap();
        let stats = analyze(f.path().to_str().unwrap()).unwrap();
        assert_eq!(stats.lines, 1);
        assert_eq!(stats.words, 6);
        assert_eq!(stats.unique_words, 3);
        assert_eq!(stats.top_words[0].0, "world");
        assert_eq!(stats.top_words[0].1, 3);
    }
}

CLI: `crates/filestat-cli/src/main.rs`

use anyhow::{Context, Result};
use clap::{Parser, ValueEnum};
use filestat_core::{analyze, StatError};

#[derive(ValueEnum, Clone, Debug)]
enum OutputFormat {
    Text,
    Json,
}

#[derive(Parser)]
#[command(name = "filestat", about = "Analyze text file statistics")]
struct Cli {
    /// Files to analyze
    files: Vec<String>,

    /// Output format
    #[arg(short, long, value_enum, default_value = "text")]
    format: OutputFormat,

    /// Show top N words (default: 5)
    #[arg(long, default_value_t = 5)]
    top: usize,
}

fn main() -> Result<()> {
    let cli = Cli::parse();

    if cli.files.is_empty() {
        anyhow::bail!("no files provided. Use: filestat <file1> [file2 ...]");
    }

    for path in &cli.files {
        match analyze(path) {
            Ok(stats) => match cli.format {
                OutputFormat::Json => {
                    println!("{}", serde_json::to_string_pretty(&stats)
                        .context("failed to serialize stats")?);
                }
                OutputFormat::Text => {
                    println!("── {} ──", stats.path);
                    println!("  Lines:        {}", stats.lines);
                    println!("  Words:        {}", stats.words);
                    println!("  Characters:   {}", stats.chars);
                    println!("  Unique words: {}", stats.unique_words);
                    println!("  Top {} words:", cli.top);
                    for (word, count) in stats.top_words.iter().take(cli.top) {
                        println!("    {:20} {}", word, count);
                    }
                }
            },
            Err(StatError::Empty(p)) => eprintln!("skipping '{p}': file is empty"),
            Err(e) => eprintln!("error: {e}"),
        }
    }

    Ok(())
}

Running it:

$ cargo run -p filestat-cli -- README.md --format text
── README.md ──
  Lines:        42
  Words:        381
  Characters:   2104
  Unique words: 198
  Top 5 words:
    the                  24
    rust                 18
    and                  15
    a                    12
    to                   11

$ cargo run -p filestat-cli -- README.md --format json
{
  "path": "README.md",
  "lines": 42,
  "words": 381,
  ...
}

Wrapping Up Part 6

Concept	What it gives you
serde	Zero-boilerplate serialization to any format
thiserror	Typed, ergonomic library error enums
anyhow	Context-rich error propagation in apps
criterion	Statistical, regression-detecting benchmarks
Workspaces	Multi-crate projects with shared dependencies
CLI + Library	Separation of logic and interface, reusable core

The Complete Series

Part	Topics
Part 1	Ownership, Borrowing, Lifetimes, Traits, Result/Option, Pattern Matching
Part 2	Closures, Iterators, Generics, Enums, Smart Pointers, Async/Await
Part 3	Macros, Modules, Cargo, Testing, Unsafe, FFI
Part 4	Threads, Channels, Send/Sync, Mutex, Atomics, clap
Part 5	dyn Trait, Deref, Drop, Custom Iterators, Axum REST API
Part 6	Serde, thiserror, anyhow, Criterion, Workspaces, CLI + Library

Where to Go Next

You've covered the full breadth of Rust — here's what to explore next:

The Rust Book — the official, free, comprehensive reference
Rustlings — hands-on exercises
Rust by Example — example-driven learning
Jon Gjengset on YouTube — deep dives into advanced Rust
Blessed.rs — curated list of recommended crates
This Week in Rust — weekly newsletter

Thanks for following the entire series! If it helped you, drop a ❤️ on each part and share with someone learning Rust. See you in the next one! 🦀

Building a Real-Time Collaborative Task Board: How Gemini Helped Me Build for the Google I/O Challenge 2026 🚀

mihir mohapatra — Sat, 23 May 2026 20:20:23 +0000

🚀 Google I/O Challenge 2026: Collaborative Task Board

Managing workflows in modern remote-first teams demands highly fluid, non-blocking digital hubs. For the Google I/O Challenge 2026, I wanted to design and build a Collaborative Task Board that replicates the rich interactive experiences of industry-standard visual workspaces—built in record time under the guidance of Google Gemini in AI Studio.

🔗 Try the Live App Here: Collaborative Task Board Live Link

(Tip: Open the URL in two separate windows or share it with a teammate to watch cursors sync live!)

🎨 Creative Vision & Application Features

The Collaborative Task Board is designed on top of a comfortable, premium, high-contrast Slate Indigo theme utilizing precise typography pairs: Space Grotesk display headings alongside JetBrains Mono for live status elements.

Key Capabilities Included:

👥 Real-Time User Presence: Teammates onboard instantly with customized nicknames and color identity themes, forming an active avatar stack representing who is inside the room.
🖱️ Adaptive Cursor Trails: Witness low-latency mouse tracking broadcasts complete with custom colors and labels matching each coworker's cursor.
🔒 Intelligent Focus Locks (Anti-Collision): If a teammate is editing cards, configuring properties, or appending discussions, the card is locked system-wide with a glowing visual banner to prevent editing collisions.
📦 Express-WebSocket State Machine: High-performance socket pipelines sync all structural change actions—creation, descriptions, priority shifts, comment additions, and drag motions—globally.
💬 Integrated Chat Forums: Each room coordinates an isolated workspace chat to talk in real-time alongside Kanban columns.
🔑 Dynamic Room Routing: Simply change the ?room= link query or inputs to create isolated spaces for separate teams.

🤖 Co-Architecting with Gemini on AI Studio

Building a truly real-time interactive coordinate tracking space is notoriously tricky to scale and refine. Gemini acted as a world-class senior developer, helper, and designer at every stage:

Architecture Design: Gemini drafted the structured type interfaces and strict client/server communication state schemas, ensuring that backend events maps to the unified source of truth.
WebSocket Integration: Gemini successfully avoided the classic React WebSocket footprint trap (re-instantiating connections on state changes) by leveraging persistent useRef handlers, combining robust fallback backoff reconnection logic.
Performance Optimization: To keep cursor broadcast packets lightweight, Gemini suggested a 45ms throttle on pointer updates, reducing websocket server load by up to 80% while maintaining premium human-eye fluidity.
No Mock Infrastructure: Guided by AI Studio's architectural guidelines, Gemini crafted a real Node/Express backend on disk instead of simple mockup timeouts, giving us live server and client synchronizations dynamically served on Cloud Run.

🛠️ Tech Stack & Implementation Details

Frontend: React 19, Tailwind CSS, Lucide icons, and motion (Framer) for fluid task rearrangements.
Backend: Node.js/TypeScript running an Express server bound with robust memory states, hosted on Google's scalable Cloud Run container environment.
Persistence & Sync: Raw ws WebSocket servers combined with robust JSON snapshots saved automatically to local data volumes matching active operations.

💭 Reflection & Google I/O Appreciation

Developing this project using AI Studio Build has been an incredible experience. The ability to express intent naturally and immediately receive clean TypeScript modules, matching proper bundler builds and actual socket integrations, makes it incredibly fun to take products from simple sketches to live, ready-to-test systems.

Let me know what you think by jumping into my collaborative workspace room! Let's build together. 🤖

Built with ♥ for the Google I/O Challenge 2026.

DEV Community: mihir mohapatra

FastAPI Crash Course: Build a CRUD REST API in ~40 Lines of Python

Why FastAPI?

What We're Building

Prerequisites

Setup

The Full Code

Code Walkthrough

1. The App Instance

2. The Pydantic Model

3. The In-Memory Store

4. GET — List All Teas

5. POST — Add a Tea

6. PUT — Update by ID

7. DELETE — Remove by ID

Run It

Interactive API Docs (Free!)

Quick Test via Swagger UI

What's Next (Production Roadmap)

Java/Kotlin Developer Take

Source Code

From Learning to Shipping — Docker, Graceful Shutdown & ECS Fargate

From Learning to Shipping — Docker, Graceful Shutdown & ECS Fargate

Multi-Stage Docker Build

Graceful Shutdown

Health Check Endpoint

Terraform: ECS Fargate

CI/CD: GitHub Actions

What This Series Built

Testing in Go — Table-Driven Tests, Benchmarks, and go test Habits

Testing in Go — Table-Driven Tests, Benchmarks, and go test Habits

The go test Mental Model

Table-Driven Tests: The Go Idiom

Testing the Store: ErrNotFound

Handler Tests with httptest

Benchmarks: Built Right In

The go test Habits Worth Locking In

Up Next

Building My First Real API in Go — with Gin

Building My First Real API in Go — with Gin

Why Gin

Project Structure

The Model

The Store

The Handler

Middleware: Request Logging

Wiring It Together

What This Draws On From Earlier Posts

Up Next

Error Handling — Learning to Love `if err != nil`

Error Handling — Learning to Love if err != nil

No Exceptions, On Purpose

Why the Repetition Is the Point

errors.Is and errors.As: Inspecting Wrapped Errors

panic and recover: Not Your Exception Mechanism

Where I've Landed

Up Next

Goroutines & Channels — Concurrency Without the JVM's Baggage

Goroutines & Channels — Concurrency Without the JVM's Baggage

Goroutines: Threads, But Cheap

WaitGroups: The Right Way to Wait

Channels: Goroutines Talking to Each Other

select: Handling Multiple Channels at Once

Where This Actually Bites You

Why This Matters for the Series

Go's Type System — Structs, Interfaces, and Life Without Inheritance

Go's Type System — Structs, Interfaces, and Life Without Inheritance

Structs: Data, Nothing More

No Inheritance, So What Replaces It?

Interfaces: The Part That Actually Surprised Me

Putting It Together: Composition Over Inheritance, For Real

Where This Still Feels Unfamiliar

Up Next

Why I'm Learning Go in 2026 (A Java/Kotlin/Rust Engineer's Take)

Why I'm Learning Go in 2026 (A Java/Kotlin/Rust Engineer's Take)

The Itch That Started This

What Go Actually Optimizes For

Concurrency Was the Real Hook

Where I Think Go Will Push Back

What This Series Will Actually Build

Error Handling — Learning to Love `if err != nil`

Working with dynamic JSON (`serde_json::Value`)

What `black_box` does

Library: `crates/filestat-core/src/lib.rs`

CLI: `crates/filestat-cli/src/main.rs`