DEV Community: Fiyinfoluwa Ojo

Day 30: 30 Days of Backend Development - What I Built, What I Learned

Fiyinfoluwa Ojo — Mon, 23 Mar 2026 21:27:38 +0000

30 Days. 30 Challenges. 1 Developer.

Today marks the end of the GDGoC Bowen 30-Day
Backend Challenge. Here's everything I built.

What I Built — Day by Day

Foundation (Days 1-5)

Day 1 → HTTP & Hello World with FastAPI
Day 2 → RESTful routes
Day 3 → Git workflow and branching
Day 4 → Dynamic path parameters
Day 5 → Query params & Pydantic validation

Data & APIs (Days 6-14)

Day 6 → SQLAlchemy data models
Day 7 → GET all items endpoint
Day 8 → Serializers & DTOs
Day 9 → POST create endpoint
Day 10 → Production-ready routes
Day 11 → DELETE endpoint
Day 12 → Global error handling
Day 13 → Pagination & filtering
Day 14 → Swagger API documentation

Auth & Security (Days 15-18)

Day 15 → Bcrypt password hashing
Day 16 → JWT authentication
Day 17 → Permissions & ownership
Day 18 → Environment variables & secrets

DevOps & Deployment (Days 19-20)

Day 19 → Docker containerization
Day 20 → Deployed to Render

Advanced (Days 21-24)

Day 21 → Pytest unit & integration tests
Day 22 → Database relationships
Day 23 → CORS & API contracts
Day 24 → In-memory caching

Capstone — To-Do App (Days 25-30)

Day 25 → PRD & planning
Day 26 → Full CRUD API
Day 27 → 10 automated tests
Day 28 → Deployed to Render
Day 29 → Filtering, pagination, docs
Day 30 → Final polish & README

The Capstone Project

Live URL:

gdgoc-bowen-todo.onrender.com

Docs:

gdgoc-bowen-todo.onrender.com

A fully production-ready To-Do App API with:

JWT authentication
Full CRUD with ownership
Priority levels and filtering
Pagination
10 automated tests
Full Swagger documentation

What I Learned

30 days of consistent building taught me more
than months of passive learning.

The most important lessons:

Consistency beats intensity
Build in public — it keeps you accountable
Every concept builds on the previous one
Documentation is part of the product
Tests give you confidence to keep building

What's Next

This is not the end — it's the foundation.
The next step is building more complex systems,
contributing to open source and preparing for
the Elevate career development meetup.

Thank you GDGoC Bowen for this challenge. 🙏

Day 30 done. The journey continues. 🔥

GDGoCBowen30dayChallenge

Capstone Day 4: Polishing the To-Do App : Filtering, Pagination & Full Documentation

Fiyinfoluwa Ojo — Mon, 23 Mar 2026 17:53:09 +0000

Day 4 — Making It Production Ready

The API works. Now let's make it excellent.
Today I added priority levels, filtering,
pagination and full Swagger documentation.

New Features

Priority Levels

Tasks now have 3 priority levels:

low
medium
high

Filtering

GET /tasks?priority=high -> only high priority tasks
GET /tasks?completed=false -> only incomplete tasks
GET /tasks?priority=high&completed=false -> combined!

Pagination

GET /tasks?page=1&limit=5 -> first 5 tasks

Response includes metadata:

{
  "metadata": {
    "total": 10,
    "page": 1,
    "limit": 5,
    "totalPages": 2
  },
  "data": [...]
}

Full Swagger Documentation

Every endpoint tagged, summarized and described.
Available at /docs — zero extra work needed.

Postman Tests

Filter by priority

Filter incomplete tasks

Swagger docs

What the Final API Looks Like

Method	Endpoint	Auth	Description
GET	/	No	API info
GET	/status	No	Health check
POST	/auth/signup	No	Register
POST	/auth/login	No	Login
GET	/tasks	Yes	Get tasks
POST	/tasks	Yes	Create task
PUT	/tasks/:id	Yes	Update task
DELETE	/tasks/:id	Yes	Delete task

Lessons Learned

The difference between a working API and a
great API is the details : filtering, pagination,
documentation and consistent error handling.
These are what separate junior from senior work.

Day 29 done. 1 more to go. 🔥

GDGoCBowen30dayChallenge

Capstone Day 3: Deploying the To-Do App API to Render

Fiyinfoluwa Ojo — Sat, 21 Mar 2026 02:50:32 +0000

The To-Do App is Live!

After 2 days of building and testing,
the To-Do App API is now deployed and
accessible to the entire world.

Live URL: https://gdgoc-bowen-todo.onrender.com

What's Deployed

A fully functional Task Management API with:

JWT Authentication (signup & login)
Full CRUD for tasks
Task ownership — users only see their own tasks
Input validation with Pydantic
10 automated tests all passing

API Endpoints

Method	Endpoint	Auth
GET	`/`	No
POST	`/auth/signup`	No
POST	`/auth/login`	No
GET	`/tasks`	Yes
POST	`/tasks`	Yes
PUT	`/tasks/:id`	Yes
DELETE	`/tasks/:id`	Yes

Deployment Setup

3 things needed for Render:

requirements.txt -> all dependencies
.python-version -> pin to 3.11.0
Start command -> uvicorn main:app --host 0.0.0.0 --port $PORT

Live Proof

Lessons Learned

Deployment is the moment your code stops
being yours and starts being useful to others.
Every step from Day 1 to Day 28 led here.

Day 28 done. 2 more to go. 🔥

GDGoCBowen30dayChallenge

Capstone Day 2: Testing the To-Do App API with Pytest

Fiyinfoluwa Ojo — Fri, 20 Mar 2026 00:33:38 +0000

Why Test the Capstone?

Every feature I add could break an existing one.
Automated tests catch that instantly.
no manual Postman testing needed.

10 Tests Covering Everything

Auth Tests

Signup success
Duplicate email returns 400
Login success returns accessToken
Wrong password returns 401

Task Tests

Create task returns 201
Get tasks returns data array
Update task marks as completed
Delete task returns 204
Get tasks without token returns 401
Create task without title returns 422

Key Test Pattern

def get_token():
    email = f"taskuser{int(time.time())}@example.com"
    client.post("/auth/signup", json={
        "email": email, "password": "password123"
    })
    response = client.post("/auth/login", json={
        "email": email, "password": "password123"
    })
    return response.json()["accessToken"]

Every task test creates its own user and token,
tests are completely isolated from each other.

Results

10 passed, 0 failed. ✅

Lessons Learned

Testing a capstone project is different from
testing isolated endpoints : you need to test
the full flow: signup -> login -> create -> update -> delete.
That's what real integration testing looks like.

Day 27 done. 3 more to go. 🔥

GDGoCBowen30dayChallenge

PRD Day: Planning the To-Do App Backend Before Writing a Single Line of Code

Fiyinfoluwa Ojo — Thu, 19 Mar 2026 16:33:12 +0000

What is a PRD?

A Product Requirements Document defines what
you're building before you build it.
Today was about reading, understanding and
planning not coding.

The Project - To-Do App

A simple task management app with:

User authentication
Full CRUD for tasks
Data persistence
Clean REST API

My Selected Feature - Task Management API

I'm building the complete backend API covering:

POST /tasks -> create task
GET /tasks -> retrieve all tasks
PUT /tasks/:id -> update task
DELETE /tasks/:id -> delete task

My 5-Day Plan

Day 26 -> Models, database setup & full CRUD
Day 27 -> Authentication & ownership
Day 28 -> Testing & validation
Day 29 -> Deployment
Day 30 -> Final polish & documentation

Lessons Learned

The best code starts with a solid plan.
Understanding requirements before writing
code saves hours of refactoring later.

Day 25 done. The build starts tomorrow. 🔥

GDGoCBowen30dayChallenge

Capstone Day 1: Building the To-Do App Task Management API

Fiyinfoluwa Ojo — Thu, 19 Mar 2026 16:29:23 +0000

The Capstone Project Begins

Days 26-30 are all about the capstone project :
a full To-Do App API built as a team.

Today I built the complete Task Management API
with authentication and full CRUD operations.

The Tech Stack

FastAPI - web framework
SQLAlchemy - ORM
SQLite - database
JWT - authentication
Pydantic - validation
CORS - frontend ready

The Data Models

class User(Base):
    id, email, password, created_at

class Task(Base):
    id, title, description, completed, 
    user_id, created_at, updated_at

Tasks are linked to users : every user
only sees their own tasks.

The API Endpoints

POST /auth/signup -> Register a new user
POST /auth/login -> Login and get JWT token
GET /tasks -> Get all tasks for logged-in user
POST /tasks -> Create a new task
PUT /tasks/:id -> Update or complete a task
DELETE /tasks/:id -> Delete a task permanently

Postman Tests

Signup & Login

Create Task

Get All Tasks

Mark Task as Completed

Delete Task

Lessons Learned

Building a real product feels different from
daily exercises. Every decision matters :
the field names, the response shapes, the
status codes because a frontend team is
depending on this API to be consistent and reliable.

Day 26 done. 4 more to go. 🔥

GDGoCBowen30dayChallenge

Caching Intro: Making Your API Lightning Fast with In-Memory Cache

Fiyinfoluwa Ojo — Thu, 19 Mar 2026 14:22:11 +0000

Why Caching?

Every database query takes time. If 1000 users
request the same categories list every minute,
that's 1000 database queries for identical data.

Caching stores the result in memory after the
first query. Everyone else gets it instantly.

The Cache Logic

cache = {}
CACHE_TTL = 60  # seconds

def get_from_cache(key: str):
    if key in cache:
        data, expires_at = cache[key]
        if time.time() < expires_at:
            print(" CACHE HIT")
            return data
        else:
            del cache[key]
            print(" CACHE EXPIRED")
    print(" CACHE MISS")
    return None

def set_cache(key: str, data):
    cache[key] = (data, time.time() + CACHE_TTL)

Cache Miss vs Cache Hit

@app.get("/categories")
def get_categories():
    cached = get_from_cache("all_categories")
    if cached:
        return {"source": "cache", "data": cached}

    # Hit the database only on cache miss
    categories = db.query(Category).all()
    set_cache("all_categories", result)
    return {"source": "database", "data": result}

First request -> source: "database" (Cache Miss)
Second request -> source: "cache" (Cache Hit)

Postman Proof

First request - Cache Miss

Second request - Cache Hit

Cache TTL

After 60 seconds the cache expires automatically.
The next request hits the database again and
refreshes the cache. This ensures data stays
reasonably fresh without hammering the database.

Lessons Learned

Caching is one of the highest ROI optimizations
in backend development. Identify routes that
don't change often and cache them.
For production use Redis instead of in-memory
cache it persists across server restarts
and works across multiple instances.

Day 24 done. 6 more to go.

GDGoCBowen30dayChallenge

CORS & API Contracts: Preparing Your Backend for Frontend Collaboration

Fiyinfoluwa Ojo — Thu, 19 Mar 2026 08:22:15 +0000

What is CORS?

When a React frontend on localhost:3000 tries to
call an API on localhost:8000, the browser blocks it.
That's CORS protection and it's a good thing.

But your own frontend should be allowed through.
That's what CORS configuration does.

Enabling CORS in FastAPI

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost:3000", "http://localhost:5173"],
    allow_credentials=True,
    allow_methods=["GET", "POST", "PUT", "DELETE", "OPTIONS"],
    allow_headers=["*"],
)

One middleware call, every response now includes
the correct CORS headers automatically.

API Contract : camelCase for Frontend

Backend Python uses snake_case by default.
But JavaScript frontends expect camelCase.

Instead of:

created_at -> use createdAt
category_id -> use categoryId
access_token -> use accessToken

Small change, big impact on frontend collaboration.

The Consistent Response Shape

Every endpoint follows the same contract:

GET /items returns:

{
  "data": [...],
  "count": 2
}

POST /auth/login returns:

{
  "accessToken": "...",
  "tokenType": "bearer",
  "email": "user@example.com"
}

Frontend developers can rely on these shapes
without reading your source code.

The OpenAPI Contract

FastAPI auto generates an OpenAPI spec at /openapi.json
This is your official API contract
frontend teams can import it into Postman
and know exactly what every endpoint expects and returns.

Postman Tests

Home endpoint showing CORS enabled

Items with camelCase fields

Lessons

CORS and consistent field naming aren't
afterthoughts, they're part of being a
good backend developer who works well with
frontend teams. Your API is only as good
as how easy it is to integrate with.

Day 23 done. 7 more to go.

GDGoCBowen30dayChallenge

Relationships & Nested Resources: One-to-Many with SQLAlchemy

Fiyinfoluwa Ojo — Tue, 17 Mar 2026 01:52:13 +0000

Modeling Real-World Complexity

Real data has relationships. A phone belongs to
Electronics. A keyboard belongs to Accessories.
Flat data doesn't capture this relationships do.

The One-to-Many Relationship

One Category has many Items.
One Item belongs to one Category.

class Category(Base):
    __tablename__ = "categories"
    id = Column(Integer, primary_key=True)
    name = Column(String, unique=True, nullable=False)
    items = relationship("Item", back_populates="category")

class Item(Base):
    __tablename__ = "items"
    id = Column(Integer, primary_key=True)
    name = Column(String, nullable=False)
    price = Column(Numeric(10, 2), nullable=False)
    category_id = Column(Integer, ForeignKey("categories.id"))
    category = relationship("Category", back_populates="items")

The ForeignKey links items to categories.
The relationship() tells SQLAlchemy how to
navigate between them.

Nested JSON Response

GET /items/1 returns:
{
  "id": 1,
  "name": "Laptop",
  "price": 999.99,
  "category": {
    "id": 1,
    "name": "Electronics",
    "description": "Electronic devices and gadgets"
  }
}

The category is nested inside the item response —
no extra API call needed.

Category with All Items

GET /categories/1 returns:
{
  "id": 1,
  "name": "Electronics",
  "items": [
    {"id": 1, "name": "Laptop", "price": 999.99},
    {"id": 2, "name": "Phone", "price": 699.99},
    {"id": 3, "name": "Headphones", "price": 199.99}
  ]
}

Postman Tests

Item with nested category

Category with all its items

Lessons Learned

Relationships are what make a database relational.
Model your data the way the real world works —
things belong to other things, and your API
should reflect that naturally.

Day 22 done. 8 more to go.

GDGoCBowen30dayChallenge

Unit & Integration Testing: Proving Your Code Works with Pytest

Fiyinfoluwa Ojo — Sat, 14 Mar 2026 11:38:25 +0000

Why Write Tests?

Manual testing means opening Postman every time
you make a change. Automated tests run in seconds
and catch bugs before they reach production.

Unit Tests vs Integration Tests

Unit tests -> test individual functions/logic in isolation
Integration tests -> test full endpoints with real HTTP requests

My 3 Unit Tests

1. Reject negative price

def test_price_validation_rejects_negative():
    with pytest.raises(ValidationError):
        ItemDTO(name="Test", price=-10)

2. Reject zero price

def test_price_validation_rejects_zero():
    with pytest.raises(ValidationError):
        ItemDTO(name="Test", price=0)

3. Accept positive price

def test_price_validation_accepts_positive():
    item = ItemDTO(name="Test", price=99.99)
    assert item.price == 99.99

My Integration Tests

Signup success

def test_signup_success():
    email = f"testuser{int(time.time())}@example.com"
    response = client.post("/auth/signup", json={
        "email": email,
        "password": "testpassword123"
    })
    assert response.status_code == 201
    assert response.json()["email"] == email

Duplicate email returns 400

def test_signup_duplicate_email():
    # signup twice with same email
    assert response.status_code == 400

Login returns token

def test_login_success():
    assert "access_token" in response.json()

Protected route without token returns 401

def test_protected_without_token():
    response = client.get("/protected")
    assert response.status_code == 401

The Results

8 passed, 0 failed. ✅

Lessons Learned

Tests are not extra work, they're insurance.
Every test you write is a bug you'll never
have to debug manually in production.

Day 21 done. 9 more to go.

GDGoCBowen30dayChallenge

Deploying a FastAPI App to Render: Taking Your API Live

Fiyinfoluwa Ojo — Fri, 13 Mar 2026 21:01:05 +0000

From Local to Live

Running an API on localhost is great for development.
But a real backend needs to be accessible to the world.
Today I deployed my FastAPI app to Render.

Why Render?

Free tier available
Connects directly to GitHub
Auto-deploys on every push to main
Environment variables built in
Zero server configuration

The Setup

3 files needed for deployment:

1. `requirements.txt`

fastapi==0.129.0
uvicorn==0.41.0
sqlalchemy==2.0.41
pydantic==2.11.5
bcrypt==4.3.0
pyjwt==2.10.1
python-dotenv==1.1.0

2. `.python-version`

3.11.0

This pins the Python version- critical because
newer versions can break dependencies.

3. Start Command

uvicorn main:app --host 0.0.0.0 --port $PORT

$PORT is automatically provided by Render.

Environment Variables on Render

Never hardcode secrets in your code.
Set them in Render's dashboard under Environment:

SECRET_KEY
ALGORITHM
DATABASE_URL

The Live API

Live URL: https://gdgoc-bowen-api.onrender.com

Lessons Learned

Deployment is not the scary part, it's just
connecting your GitHub repo to a platform and
setting your environment variables correctly.
The hard work is writing production-ready code.

Day 20 done. 10 more to go.

GDGoCBowen30dayChallenge

Dockerizing a FastAPI App: Eliminating "It Works on My Machine"

Fiyinfoluwa Ojo — Mon, 09 Mar 2026 06:36:53 +0000

What is Docker?

Docker packages your app and all its dependencies
into a container a lightweight, portable unit that
runs exactly the same on any machine.

No more "it works on my machine" problems.

The Dockerfile

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
Line by line:

FROM → base image (Python 3.11)
WORKDIR → working directory inside container
COPY requirements.txt → copy dependencies first
RUN pip install → install dependencies
COPY . . → copy all app code
EXPOSE 8000 → open port 8000
CMD → command to start the app

docker-compose.yml

services:
  api:
    build: .
    ports:
      - "8000:8000"
    command: python -m uvicorn main:app --host 0.0.0.0 --port 8000

Docker Compose links services together
useful when you add a database container later.

Build & Run

docker build -t gdgoc-bowen-api.
docker-compose up --build

Proof it Builds

Lessons Learned

Docker is not just a DevOps tool, it's a
backend developer's best friend. Every production
app runs in containers today. Learning Docker
early puts you ahead of most developers.

Day 19 done. 11 more to go.