Forem: Michelle

30-Day Cloud & DevOps Challenge: Day 7 — Docker Compose: One Command to Rule Them All

Michelle — Sun, 12 Apr 2026 14:35:05 +0000

Yesterday, I had two containers: one for my backend, one for my frontend.

But running them meant two terminals, two docker run commands, and remembering which port mapped to what.

Today, I fixed that forever.

I learned Docker Compose a tool that lets me define my entire application stack in one file and start everything with a SINGLE command.

First: What Problem Does Docker Compose Solve?

Without Docker Compose (Days 5 & 6)

# Terminal 1
cd backend
sudo docker build -t backend-app .
sudo docker run -p 3001:5000 backend-app

# Terminal 2 (new terminal)
cd frontend
npm run build
sudo docker build -t frontend-app .
sudo docker run -p 8080:80 frontend-app

The pain:

Multiple terminals
Many commands to remember
Containers don't automatically know about each other
Hard to share setup with others

With Docker Compose (Today)

# One terminal. One command.
sudo docker-compose up --build

That's it. Everything runs.

What is Docker Compose?

In one sentence: Docker Compose is a tool that lets you define and run multiple Docker containers together using a single YAML file.

The Analogy

Concept	Docker Alone	Docker Compose
Individual containers	Shipping containers	Shipping containers
Managing them	Moving each by hand	A crane operator with a manifest
Documentation	Remember what goes where	Everything in one file

Docker Compose is the crane operator + manifest that organizes all your containers at once.

Step 1: Creating docker-compose.yml

First, I went to my project root:

cd ~/Desktop/Production-Ready-Microservices-Platform

Then I created the Compose file:

touch docker-compose.yml
nano docker-compose.yml

Step 2: Writing the Compose File (Line by Line)

Line 1: Version

version: '3.8'

What this means: Which version of Docker Compose syntax to use (3.8 is current).

Line 2: Services Section

services:

What this means: Everything below defines containers (called "services").

Lines 3-6: Backend Service

  backend:
    build: ./backend
    ports:
      - "3001:5000"

Line	Meaning
`backend:`	Name of the service
`build: ./backend`	Build image using Dockerfile in `./backend`
`ports:`	Define port mapping
`- "3001:5000"`	Map host 3001 → container 5000

Lines 7-10: Frontend Service

  frontend:
    build: ./frontend
    ports:
      - "8080:80"

Same pattern, but for the frontend (port 8080 → 80).

The Complete File

version: '3.8'

services:
  backend:
    build: ./backend
    ports:
      - "3001:5000"

  frontend:
    build: ./frontend
    ports:
      - "8080:80"

That's it! 12 lines to define my entire application.

Step 3: What Docker Compose Does Behind the Scenes

When I ran docker-compose up --build, Compose did ALL of this automatically:

# 1. Created a shared network
docker network create microservices-platform_default

# 2. Built backend image
docker build -t microservices-platform-backend ./backend

# 3. Built frontend image
docker build -t microservices-platform-frontend ./frontend

# 4. Started backend container
docker run -d \
  --name microservices-platform-backend-1 \
  --network microservices-platform_default \
  -p 3001:5000 \
  microservices-platform-backend

# 5. Started frontend container
docker run -d \
  --name microservices-platform-frontend-1 \
  --network microservices-platform_default \
  -p 8080:80 \
  microservices-platform-frontend

All of that from one command. That's the magic of Docker Compose.

Step 4: Running Everything

sudo docker-compose up --build

What I saw:

[+] Building 2.5s (15/15) FINISHED
[+] Running 3/3
 ✔ backend   Built
 ✔ frontend  Built
 ✔ Network microservices-platform_default  Created

Then the containers started:

frontend-1  | /docker-entrypoint.sh: Configuration complete; ready for start up
backend-1   | Server is running on http://localhost:5000
backend-1   | Try these endpoints:
backend-1   |   - http://localhost:5000/
backend-1   |   - http://localhost:5000/health
backend-1   |   - http://localhost:5000/users

Both containers running simultaneously in ONE terminal!

Step 5: Testing Everything

Testing the Backend

In a new terminal:

curl http://localhost:3001/health

Response:

{"status":"healthy","service":"backend-api","timestamp":"2026-04-12T13:10:49.057Z"}

Testing the Frontend

In my browser: http://localhost:8080

My React app appeared! Same as Day 3, but now running inside a container managed by Compose.

Step 6: Stopping Everything

To stop all containers:

# In the Compose terminal, press Ctrl+C
Ctrl+C

# Then clean up
sudo docker-compose down

One command stops EVERYTHING. No more hunting for container IDs.

Docker vs Docker Compose: The Comparison

Task	Docker Alone	Docker Compose
Run one container	`docker run ...`	Overkill
Run multiple containers	Multiple commands	`docker-compose up`
Connect containers	Manual network setup	Automatic network
Start order	Manual (wait, then start)	`depends_on`
Environment variables	`-e` flag each time	In file
Port mapping	`-p` flag each time	In file
Share setup	Send commands to friend	Send one file
Rebuild after changes	Manual rebuild	`--build` flag
View logs	`docker logs ID`	`docker-compose logs`

Why Your Project NEEDS Docker Compose

Your Architecture

User → Frontend (React) → Backend (Node.js) → (Soon: PostgreSQL)

Each component has different needs:

Need	Frontend	Backend	Database (coming)
Base image	nginx:alpine	node:18-alpine	postgres:15
Port	80	5000	5432
Storage	None	None	Persistent volume
Start order	Last	Middle	First
Scale for	User traffic	API calls	Data growth

Without Compose (Manual Nightmare)

# Start database
docker run -d --name postgres -v postgres_data:/var/lib/postgresql/data postgres:15

# Wait for database
sleep 5

# Start backend
docker run -d --name backend --link postgres -e DB_HOST=postgres backend-app

# Start frontend
docker run -d --name frontend -p 8080:80 frontend-app

# Create network
docker network create myapp
docker network connect myapp postgres backend frontend

# To stop: 4 separate commands

15+ commands! One mistake and nothing works.

With Compose (One File)

version: '3.8'

services:
  postgres:
    image: postgres:15
    volumes:
      - postgres_data:/var/lib/postgresql/data

  backend:
    build: ./backend
    depends_on:
      - postgres
    environment:
      - DB_HOST=postgres

  frontend:
    build: ./frontend

# ONE command
docker-compose up --build

3 commands total. Perfect every time.

Issues I Ran Into

Issue 1: "no configuration file provided"

Error:

no configuration file provided: not found

Cause: I was in the wrong directory.

Fix:

cd ~/Desktop/Production-Ready-Microservices-Platform
ls -la docker-compose.yml  # Verify file exists

Issue 2: Port already allocated

Error:

Bind for 0.0.0.0:8080 failed: port is already allocated

Cause: I still had my old frontend container running from Day 6.

Fix:

sudo docker ps  # Find running containers
sudo docker stop <container_id>  # Stop the old one
sudo docker-compose up  # Now it works

Issue 3: The "version is obsolete" warning

Warning:

the attribute `version` is obsolete, it will be ignored

Fix: I can remove the version: '3.8' line — newer Docker versions don't need it.

Docker Compose Commands Cheat Sheet

Command	What it does
`docker-compose up`	Start all services
`docker-compose up -d`	Start in background (detached)
`docker-compose up --build`	Rebuild images then start
`docker-compose down`	Stop and remove containers
`docker-compose down -v`	Also remove volumes (databases!)
`docker-compose ps`	Show status of services
`docker-compose logs`	View logs from all services
`docker-compose logs backend`	View logs from backend only
`docker-compose build`	Rebuild images without starting
`docker-compose restart`	Restart all services

Key Takeaways

Docker Compose = Multiple containers, one command — No more terminal juggling
Everything in one file — Share your setup with anyone
Automatic networking — Containers can find each other by name
Declarative configuration — Say WHAT you want, not HOW
Local = Production — Same Compose file works everywhere

Resources

30-Day Cloud & DevOps Challenge: Day 6 — Dockerizing My React Frontend

Michelle — Sat, 11 Apr 2026 14:55:23 +0000

Yesterday, I packaged my backend into a Docker container. Today, I did the same for my React frontend.

But there's a twist, frontend containers are DIFFERENT. No Node.js running. No npm start. Just pure, static files served by nginx.

And I learned why nginx is the king of web servers.

First: How Frontend Docker is Different

Backend Container	Frontend Container
Runs Node.js server	Runs nginx (web server)
Needs `npm start`	Just serves static files
Code changes often	Build once, serve forever
Port 5000	Port 80 (standard web port)
~135MB image	~23MB image

Analogy:

Backend = Restaurant kitchen (active cooking, handling requests)
Frontend = Dining room + menu (just shows what's ready)

Step 1: Building React for Production

Right now, I run React with npm start (development mode). For Docker, I need a production build, optimized, minified, and ready to serve.

Navigate to frontend folder

cd ~/Desktop/Production-Ready-Microservices-Platform/frontend

Build the production version

npm run build

What this command does:

Takes all my React code
Optimizes it (removes comments, shortens variable names)
Minifies files (makes them smaller)
Creates a build folder with everything needed

What I saw:

Creating an optimized production build...
Compiled successfully.

File sizes after gzip:
  40.21 kB  build/static/js/main.xxxxx.js
  1.78 kB   build/static/css/main.xxxxx.css

Verify the build folder

ls

I could see the build folder (blue or highlighted in terminal).

ls build

Output:

index.html  static  asset-manifest.json

What's inside:

index.html — The main HTML file
static/ — JavaScript and CSS files
asset-manifest.json — Map of all assets

Step 2: Creating the Dockerfile

Why nginx?

nginx (pronounced "engine-x") is the most popular web server in the world. It's:

Feature	Why It Matters
Fast	Can handle 10,000+ connections simultaneously
Lightweight	Alpine version is only 23MB
Reliable	Used by Netflix, Airbnb, Uber, Dropbox
Simple	Just point it to your files and it works

Create the Dockerfile

nano Dockerfile

The Complete Dockerfile

FROM nginx:alpine
COPY build /usr/share/nginx/html
EXPOSE 80

That's it! Three lines. Frontend containers are much simpler than backend.

Understanding Each Line

Line	What it does	Why
`FROM nginx:alpine`	Start with nginx on Alpine Linux	Tiny base image (23MB)
`COPY build /usr/share/nginx/html`	Put React files where nginx looks	nginx serves from this folder by default
`EXPOSE 80`	Document the port	Standard web port

What is `/usr/share/nginx/html`?

This is nginx's default document root — the folder where it looks for files to serve. When you put index.html there, nginx automatically serves it.

Save and verify

# Save: Ctrl+O, Enter, Ctrl+X

# Verify the file
cat Dockerfile

Output:

FROM nginx:alpine
COPY build /usr/share/nginx/html
EXPOSE 80

Step 3: Building the Frontend Image

sudo docker build -t frontend-app .

Breaking down the command:

Part	Meaning
`sudo docker build`	Build an image
`-t frontend-app`	Tag it as "frontend-app"
`.`	Use Dockerfile in current directory

What I saw:

[+] Building 0.5s (5/5) FINISHED
 => [1/2] FROM nginx:alpine
 => [2/2] COPY build /usr/share/nginx/html
 => exporting to image
 => => naming to docker.io/library/frontend-app:latest

Verify the image

sudo docker images

Output:

REPOSITORY     TAG       IMAGE ID       CREATED         SIZE
frontend-app   latest    xxxxxxx        1 minute ago    23MB
backend-app    latest    e0e0904815be   1 day ago       135MB
nginx          alpine    xxxxxxx        2 weeks ago     23MB

Notice the size difference:

Backend image: 135MB (Node.js + dependencies)
Frontend image: 23MB (just static files + nginx)

Step 4: Running the Frontend Container

sudo docker run -p 8080:80 frontend-app

Understanding the port mapping:

Part	Meaning
`-p 8080:80`	Map port 8080 (my computer) → port 80 (container)
`frontend-app`	Which image to use

Why port 80? Port 80 is the standard web port. Browsers use it by default when you visit http://example.com.

Why map to 8080? Port 80 is often already in use. 8080 is a common alternative.

What I saw: Nothing in the terminal. That's normal! nginx runs silently.

Step 5: Testing the Container

Open browser

I went to: http://localhost:8080

My React app appeared! The same one I built on Day 3.

Check running containers

In a new terminal:

sudo docker ps

Output:

CONTAINER ID   IMAGE          COMMAND                  CREATED         STATUS         PORTS
b8194975c784   frontend-app   "/docker-entrypoint.…"   3 minutes ago   Up 3 minutes   0.0.0.0:8080->80/tcp

What this shows:

Container is running
Port 8080 on my computer → port 80 inside container
Status: Up (healthy!)

Running Both Containers

Now I have TWO containers running:

Container	Image	Port	Purpose
frontend-app	nginx:alpine	8080	Serves React app
backend-app	node:18-alpine	3001	API endpoints

To see both:

sudo docker ps

Output:

CONTAINER ID   IMAGE           COMMAND                  PORTS
b8194975c784   frontend-app    "/docker-entrypoint.…"   0.0.0.0:8080->80/tcp
a1b2c3d4e5f6   backend-app     "docker-entrypoint.s…"   0.0.0.0:3001->5000/tcp

Step 6: Stopping the Container

To stop the frontend container, I went to its terminal and pressed:

Ctrl + C

The container stopped gracefully.

What I Learned

Why nginx for Frontend?

Alternative	Pros	Cons
`serve` (npm package)	Simple	Needs Node.js installed
`http-server`	Easy	Not production-ready
nginx	Fast, reliable, tiny	Slight learning curve

Production Build vs Development

Aspect	`npm start` (dev)	`npm run build` (prod)
File size	Large (unminified)	Small (minified)
Source maps	Yes (debugging)	No (smaller)
Hot reload	Yes	No
Performance	Slow	Fast
Use case	Development	Production/Docker

The Build Process Explained

React Source Code (JSX, Components)
        ↓
    npm run build
        ↓
Optimized Files (minified, bundled)
        ↓
   build/ folder
        ↓
    COPY to nginx
        ↓
     Served to users

Mistakes I Made (And Fixed)

Mistake 1: Trying to use `npm start` in Docker

What I thought: I could just do CMD ["npm", "start"] like backend

Why it's wrong: React's dev server isn't meant for production containers

Fix: Use nginx to serve static files

Mistake 2: Wrong COPY destination

What I tried: COPY build /var/www/html

Why it's wrong: nginx default folder is /usr/share/nginx/html

Fix: Use the correct nginx document root

Mistake 3: Forgetting to run `npm run build`

What happened: Docker couldn't find the build folder

Error: COPY failed: stat build: file does not exist

Fix: Always run npm run build before building the Docker image

Docker Commands Cheat Sheet (Updated)

Command	What it does
`npm run build`	Create production build of React app
`docker build -t name .`	Build image from Dockerfile
`docker images`	List all images
`docker run -p HOST:CONTAINER image`	Run container from image
`docker ps`	List running containers
`docker ps -a`	List ALL containers (including stopped)
`docker stop container_id`	Stop running container
`docker rm container_id`	Remove stopped container
`docker rmi image_id`	Remove image

Key Takeaways

Frontend containers are simpler — Just static files + web server
nginx is the industry standard — 40% of all websites use it
Production builds are essential — npm run build creates optimized files
Alpine images are tiny — My frontend image is only 23MB
Port mapping is still important — Container port 80 → host port 8080

Resources

Let's Connect!

Have you containerized a frontend app before? What web server do you prefer? nginx, Apache, or something else?

Drop a comment or connect on LinkedIn. Let's learn together!

This is Day 6 of my 30-Day Cloud & DevOps Challenge. Follow along as I build a complete microservices platform from scratch!

30-Day Cloud & DevOps Challenge: Day 5 — Dockerizing My Backend (First Steps into Containers)

Michelle — Sat, 11 Apr 2026 14:28:01 +0000

Yesterday, I had a working PostgreSQL database with real data. But there was one problem...

My backend still ran with npm run dev. It worked on MY laptop, but would it work anywhere else?

Today, I solved that forever.

I packaged my Node.js backend into a Docker container — a self-contained unit that runs IDENTICALLY on any computer. And I learned why containers are revolutionizing software deployment.

First: What Even IS Docker? (Explained Simply)

The Problem Docker Solves

Before Docker (The "It works on my machine" nightmare):

Computer	Issue
Your laptop	Node.js v18, PostgreSQL local
Your coworker's laptop	Node.js v14, different OS
Cloud server	Ubuntu, missing dependencies
Production	Completely different environment

Result: "But it worked on MY machine!"

The Docker Solution

Think of Docker like a shipping container:

Analogy	Docker
Shipping container	Docker container
Ship, train, truck	Any computer running Docker
Your stuff inside	Your app + Node.js + all dependencies

The magic: Once it's in a container, it runs IDENTICALLY everywhere.

Step 1: Checking Docker Installation

First, I needed to verify Docker was installed on my Ubuntu system:

docker --version

Output:

Docker version 29.2.1, build a5c7197

Docker was installed! But I hit a permission issue:

docker ps

Error:

permission denied while trying to connect to the docker API

Fixing Docker Permissions

The issue: My user wasn't in the docker group.

Solution:

# Add my user to docker group
sudo usermod -aG docker mkangeth

# Log out and back in (or restart)
# Then verify
docker ps

Alternative (what I used): Added sudo before each docker command:

sudo docker ps

Output:

CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

Empty list = Docker is working!

Step 2: Creating the Dockerfile

A Dockerfile is like a recipe that tells Docker how to build your container.

What is a Dockerfile?

Think of it like baking a cake:

Baking Analogy	Dockerfile Instruction
Start with base ingredients	`FROM node:18-alpine`
Set up your workspace	`WORKDIR /app`
Add your ingredients	`COPY package*.json ./`
Mix everything	`RUN npm install`
Present the final cake	`CMD ["npm", "start"]`

Creating the File

First, navigate to my backend folder:

cd ~/Desktop/Production-Ready-Microservices-Platform/backend

Create the Dockerfile:

touch Dockerfile
nano Dockerfile

The Complete Dockerfile (Line by Line)

# Use Node.js 18 on Alpine Linux (tiny Linux, only 5MB!)
FROM node:18-alpine

# Create and set working directory inside the container
WORKDIR /app

# Copy package files first (for Docker caching)
COPY package*.json ./

# Install all dependencies
RUN npm install

# Copy all source code
COPY . .

# Tell Docker the container listens on port 5000
EXPOSE 5000

# Start the application
CMD ["npm", "start"]

Why Each Line Matters

Instruction	What it does	Why it's important
`FROM node:18-alpine`	Base image with Node.js	Alpine is tiny (5MB vs 100MB+)
`WORKDIR /app`	Sets working directory	All commands run from here
`COPY package*.json ./`	Copies dependency list	Docker caches this layer
`RUN npm install`	Installs dependencies	Happens inside the container
`COPY . .`	Copies your code	Last layer (changes most often)
`EXPOSE 5000`	Documents the port	Doesn't publish, just informs
`CMD ["npm", "start"]`	Runs when container starts	Production command, not dev

Step 3: Building the Docker Image

Now the magic happens — building my image:

sudo docker build -t backend-app .

Breaking down the command:

Part	Meaning
`sudo docker build`	Build an image from a Dockerfile
`-t backend-app`	Tag (name) the image "backend-app"
`.`	Use Dockerfile in current directory

What I saw:

[+] Building 45.2s (10/10) FINISHED
 => [1/5] FROM node:18-alpine
 => [2/5] WORKDIR /app
 => [3/5] COPY package*.json ./
 => [4/5] RUN npm install
 => [5/5] COPY . .
 => exporting to image
 => => naming to docker.io/library/backend-app:latest

Verifying the Image

sudo docker images

Output:

REPOSITORY     TAG       IMAGE ID       CREATED         SIZE
backend-app    latest    e0e0904815be   2 minutes ago   135MB
node           18-alpine f0286cc18189   2 weeks ago     120MB

My image is 135MB — much smaller than a full Ubuntu image would be (thanks, Alpine!)

Step 4: Running the Container

Time to run my backend inside a container:

sudo docker run -p 3001:5000 backend-app

Understanding port mapping:

Part	Meaning
`-p 3001:5000`	Map port 3001 (my computer) → port 5000 (container)
`backend-app`	Which image to use

Why port mapping?

Inside container: app runs on port 5000
On my computer: I can access it via port 3001

Output:

> backend@1.0.0 start
> node server.js

 Server is running on http://localhost:5000
 Try these endpoints:
   - http://localhost:5000/
   - http://localhost:5000/health
   - http://localhost:5000/users

The terminal stays "stuck" here — that's GOOD! My server is running!

Step 5: Testing the Container

In a new terminal, I tested my running container:

curl http://localhost:3001/health

Response:

{"status":"healthy","service":"backend-api","timestamp":"2026-04-11T14:03:42.057Z"}

Then tested the users endpoint:

curl http://localhost:3001/users

Response:

[
  {"id":1,"name":"Alice","email":"alice@example.com"},
  {"id":2,"name":"Bob","email":"bob@example.com"},
  {"id":3,"name":"Charlie","email":"charlie@example.com"}
]

SUCCESS! My Dockerized backend was working perfectly!

Step 6: Stopping the Container

To stop the container, I went back to the first terminal and pressed:

Ctrl + C

The server shut down gracefully.

What I Learned

Docker Concepts I Mastered

Concept	What I learned
Image	A blueprint/template (like a class in programming)
Container	A running instance of an image (like an object)
Dockerfile	The recipe that defines how to build an image
Port mapping	Connecting container ports to host ports
Layer caching	Docker reuses unchanged layers for faster builds

The Docker Workflow

Dockerfile → docker build → Image → docker run → Container
   (recipe)      (build)     (blueprint)   (run)    (running app)

Why Alpine Linux?

Base Image	Size	Use case
`node:latest`	~1GB	Full OS, many tools
`node:18-slim`	~200MB	Minimal Debian
`node:18-alpine`	~120MB	Tiny, security-focused

I chose Alpine: Smaller = faster downloads, less storage, smaller attack surface.

Mistakes I Made (And Fixed)

Mistake 1: Docker Permission Denied

Error:

permission denied while trying to connect to the docker API

Fix: Added sudo before docker commands OR added user to docker group:

sudo usermod -aG docker $USER
# Then log out and back in

Mistake 2: Wrong Port Mapping

What happened: My server ran on port 5000, but I mapped to port 8000

Fix:

# Wrong
sudo docker run -p 3001:8000 backend-app

# Correct
sudo docker run -p 3001:5000 backend-app

Lesson: Always check what port your app actually uses!

Docker Commands Cheat Sheet

Command	What it does
`docker --version`	Check Docker version
`docker images`	List all images on your computer
`docker ps`	List RUNNING containers
`docker ps -a`	List ALL containers (including stopped)
`docker build -t name .`	Build an image from Dockerfile
`docker run -p HOST:CONTAINER image`	Run a container from an image
`docker stop container_id`	Stop a running container
`docker rm container_id`	Remove a stopped container
`docker rmi image_id`	Remove an image
`docker logs container_id`	See container logs

Key Takeaways

Containers are NOT virtual machines — They share the host OS kernel, making them lightweight and fast
Dockerfiles are recipes — They define exactly how to build your container
Images are blueprints — You build once, run anywhere
Containers are running instances — You can run many containers from one image
Port mapping is essential — Containers have their own network; you must expose ports
Alpine Linux is your friend — Tiny images = faster everything

Resources

Let's Connect!

Have you used Docker before? What was your first container? Any tips for someone just starting?

Drop a comment or connect on LinkedIn. Let's learn together!

This is Day 5 of my 30-Day Cloud & DevOps Challenge. Follow along as I build a complete microservices platform from scratch!

30-Day Cloud & DevOps Challenge: Day 4 — PostgreSQL Deep Dive (From Zero to Database Hero)

Michelle — Wed, 08 Apr 2026 09:13:28 +0000

Yesterday, my React frontend finally talked to my Node.js backend. But there was one problem...

The users were FAKE. Hardcoded in server.js. Every time the server restarted, any new users would disappear forever.

Today, I fixed that permanently.

I installed PostgreSQL, created a database, built a users table, and stored real data that survives server restarts. And I learned WAY more about databases than I expected.

First: What Even IS a Database?

Before writing a single command, I needed to understand what a database actually IS.

Think of it like this:

Real World	Database
A filing cabinet	The database itself
A drawer in the cabinet	A table
A folder in the drawer	A row (record)
Information on the folder	Columns (fields)

For my users:

One drawer called users
Each folder has: an ID number, a name, an email address, a creation date
I can open any folder, read it, change it, or throw it away

The magic: Even if I turn off my computer, the filing cabinet (database) still has all my folders.

Step 1: Installing PostgreSQL

I'm on Ubuntu Linux, so installation was straightforward:

# Update my package list (like refreshing the app store)
sudo apt update

# Install PostgreSQL
sudo apt install postgresql postgresql-contrib -y

# Verify it's running
sudo systemctl status postgresql

What I learned about each command:

Command	What it actually does
`sudo`	"Super user do" — gives admin permissions
`apt update`	Refreshes the list of available software
`apt install postgresql`	Downloads and installs the database
`-y`	Automatically answers "yes" to confirmation prompts

The moment I knew it worked: Seeing Active: active (running) in green text.

Step 2: Understanding PostgreSQL Users

When PostgreSQL installs, it automatically creates:

A system user called postgres (the admin/manager)
A default database also called postgres

Analogy:

Concept	Analogy
PostgreSQL	A bank vault
`postgres` user	The bank manager (has all the keys)
My job	Ask the manager to create a vault for MY project

To become the manager:

sudo -u postgres psql

My prompt changed from: mkangeth@LAP-018:~$

To: postgres=#

Note: That postgres=# means I'm INSIDE PostgreSQL now. Different commands work here.

Step 3: My First PostgreSQL Commands

Seeing what databases already exist:

\l

This showed me three databases: postgres, template0, template1. None were mine.

Creating MY database:

CREATE DATABASE microservices_platform;

Response: CREATE DATABASE — it worked!

Creating a user for my app:

CREATE USER app_user WITH PASSWORD 'mysecretpassword';

Response: CREATE ROLE

Giving my user permission:

GRANT ALL PRIVILEGES ON DATABASE microservices_platform TO app_user;

Response: GRANT

Connecting to MY database:

\c microservices_platform

Response: You are now connected to database "microservices_platform"

Notice: My prompt changed to microservices_platform=#

Step 4: Creating My First Table

Now for the exciting part — creating a table to store users.

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(100) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Let me explain EVERY piece:

Part	What it means
`CREATE TABLE users`	Make a new table called "users"
`id SERIAL PRIMARY KEY`	Auto-number each user (1,2,3...) and use it as the unique identifier
`name VARCHAR(100) NOT NULL`	Name column, max 100 characters, can't be empty
`email VARCHAR(100) UNIQUE NOT NULL`	Email column, max 100 chars, no duplicates, can't be empty
`created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP`	Automatically sets the current time when a user is added

Response: CREATE TABLE — my table exists!

Step 5: Inserting Data

Time to add some users:

INSERT INTO users (name, email) VALUES 
('Alice', 'alice@example.com'),
('Bob', 'bob@example.com'),
('Charlie', 'charlie@example.com');

Response: INSERT 0 3 — three users added successfully.

Step 6: Reading My Data

The moment of truth — seeing what's actually in my database:

SELECT * FROM users;

Output:

id |  name   |        email        |         created_at
----+---------+---------------------+----------------------------
 1 | Alice   | alice@example.com   | 2026-04-08 09:57:56.360654
 2 | Bob     | bob@example.com     | 2026-04-08 09:57:56.360654
 3 | Charlie | charlie@example.com | 2026-04-08 09:57:56.360654
(3 rows)

I literally cheered. My data was stored permanently in a real database!

Step 7: Exiting PostgreSQL

\q

Back to my normal terminal prompt.

What I Learned About Databases (Deep Dive)

Why PostgreSQL Specifically?

Feature	Why It Matters
ACID compliance	Transactions are atomic — either fully complete or fully fail (no partial updates)
MVCC	Multiple users can read/write simultaneously without locking each other
Advanced data types	JSON, arrays, hstore, geometric data — not just strings and numbers
Standards compliant	Learning PostgreSQL teaches you SQL that works on Oracle, DB2, etc.

The Data Types I Used

Type	What it stores	Example
`SERIAL`	Auto-incrementing integer	1, 2, 3, 4...
`VARCHAR(100)`	Text up to 100 characters	"Alice"
`TIMESTAMP`	Date and time	"2026-04-08 09:57:56"

The Constraints I Used

Constraint	What it does
`PRIMARY KEY`	Uniquely identifies each row (no duplicates, never null)
`NOT NULL`	This field must have a value
`UNIQUE`	No two rows can have the same value in this column
`DEFAULT`	If no value is provided, use this automatic value

Mistakes I Made (And Fixed)

Mistake 1: Typing PostgreSQL commands in the normal terminal

What happened: I typed \c at mkangeth@LAP-018:~$ and got command not found

Why: \c is a PostgreSQL command, not a Linux command

Fix: Enter PostgreSQL first with sudo -u postgres psql

Mistake 2: Forgetting the semicolon

What happened: I typed CREATE DATABASE microservices_platform and nothing happened

Why: PostgreSQL waits for ; to know the command is complete

Fix: Always end SQL commands with ;

Mistake 3: Incomplete CREATE DATABASE

What happened: I typed CREATE DATABASE microservices and got stuck at a postgres-# prompt

Why: I didn't finish the command

Fix: Press Ctrl+C to cancel, then retype the full command

PostgreSQL vs Other Databases (What I Learned)

Database	Best For	Why
PostgreSQL	Complex apps, data integrity	Full SQL support, ACID compliant
MySQL	Simple web apps, WordPress	Fast reads, easier to learn
SQLite	Mobile apps, local storage	No server needed, single file
MongoDB	Flexible schema, JSON data	No fixed structure, horizontal scaling
Firebase	Real-time apps, prototyping	Built-in auth, real-time updates
Supabase	PostgreSQL + convenience	Open source, real-time, auto-API

Why I chose PostgreSQL for this project: It's the industry standard for serious applications. Apple, Netflix, and Uber all use it.

Key Takeaways

Databases are permanent storage — unlike server memory, data survives restarts
Tables have structure — columns define what data looks like (types, constraints)
PostgreSQL is powerful — ACID compliance, advanced data types, concurrency handling
SQL is the language — CREATE, INSERT, SELECT, UPDATE, DELETE
The prompt tells you where you are — $ = terminal, =# = PostgreSQL

Quick Reference: PostgreSQL Commands I Learned

Command	What it does
`sudo -u postgres psql`	Enter PostgreSQL as admin
`\l`	List all databases
`\c database_name`	Connect to a specific database
`\d`	List all tables in current database
`\d table_name`	Show table structure
`CREATE DATABASE name;`	Create a new database
`CREATE USER name WITH PASSWORD 'pass';`	Create a new user
`GRANT ALL PRIVILEGES ON DATABASE db TO user;`	Give user permissions
`CREATE TABLE ...`	Create a new table
`INSERT INTO ... VALUES ...`	Add data to a table
`SELECT * FROM ...`	Read data from a table
`\q`	Exit PostgreSQL

Resources

Let's Connect!

Have you worked with databases before? SQL or NoSQL? What's your preference and why?

Drop a comment or connect on LinkedIn. Let's learn together!

30-Day Cloud & DevOps Challenge: Day 3 — Connecting Frontend to Backend (The CORS Journey)

Michelle — Fri, 03 Apr 2026 10:42:26 +0000

After yesterday's backend success, today was about making my React frontend actually TALK to my Node.js API.

Spoiler alert: It wasn't as simple as I thought. But that's where the real learning happened.

What I Set Out to Do Today

Build a React frontend that:

✅ Connects to my backend API
✅ Fetches health status automatically
✅ Displays users from the database
✅ Shows everything in a nice UI

Simple, right? Well... let me share the journey.

Step 1: Creating the React App

I started by creating a React app in my project folder:

cd ~/Desktop/Production-Ready-Microservices-Platform
npx create-react-app frontend

This created a complete React application with all the boilerplate code.

What I learned: create-react-app is a magical command that sets up an entire React development environment in minutes. It includes:

Development server with hot reloading
Build tools (webpack, Babel)
Testing setup
Production build optimization

Step 2: Cleaning Up Unnecessary Files

React creates many example files. I removed what I didn't need:

cd frontend/src
rm App.test.js setupTests.js reportWebVitals.js logo.svg

What I learned: reportWebVitals.js tracks performance metrics (load time, responsiveness). Not needed for learning, but useful for production apps.

Oops moment: After deleting files, React crashed because index.js was still trying to import reportWebVitals. Fixed by removing those import lines from index.js.

Step 3: Writing the React Component

Here's the complete App.js I built:

import { useState, useEffect } from 'react';
import './App.css';

function App() {
  // State = memory for our component
  const [backendStatus, setBackendStatus] = useState('Checking backend...');
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(false);

  // useEffect = runs automatically when page loads
  useEffect(() => {
    checkBackendHealth();
  }, []);

  // Check if backend is alive
  async function checkBackendHealth() {
    try {
      const response = await fetch('http://localhost:8000/health');
      const data = await response.json();
      setBackendStatus(`✅ Backend is healthy! Service: ${data.service}`);
    } catch (error) {
      setBackendStatus('❌ Cannot reach backend. Make sure it\'s running on port 8000');
    }
  }

  // Load users from backend
  async function loadUsers() {
    setLoading(true);
    try {
      const response = await fetch('http://localhost:8000/users');
      const data = await response.json();
      setUsers(data);
    } catch (error) {
      console.error('Failed to load users:', error);
    } finally {
      setLoading(false);
    }
  }

  return (
    <div className="App">
      <h1> Microservices Platform</h1>

      <div className="status-card">
        <h2>Backend Status</h2>
        <p>{backendStatus}</p>
      </div>

      <div className="status-card">
        <h2> Users List</h2>
        <button onClick={loadUsers} disabled={loading}>
          {loading ? 'Loading...' : 'Load Users'}
        </button>

        <div className="users-list">
          {users.map(user => (
            <div key={user.id} className="user-item">
              <strong>{user.name}</strong>
              <br />
               {user.email}
            </div>
          ))}
        </div>
      </div>
    </div>
  );
}

export default App;

The Major Problem: CORS

I ran both servers:

Backend on port 8000 (npm run dev)
Frontend on port 3000 (npm start)

But my React app showed: ❌ Cannot reach backend

The browser console showed this error:

Access to fetch at 'http://localhost:8000/health' from origin 'http://localhost:3000' 
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present

What is CORS? (Simple Explanation)

Term	Meaning
CORS	Cross-Origin Resource Sharing
Origin	The domain + port where your app lives (http://localhost:3000)
The Problem	Browsers block requests from one origin to another by default (security)
The Fix	Tell the backend "It's OK to accept requests from React"

Analogy:

React = A person at door 3000
Backend = A person at door 8000
Browser = Security guard
Without CORS = Guard says "You can't talk to each other, different doors!"
With CORS = Guard says "Oh, it's allowed. Go ahead!"

Fixing CORS (Step by Step)

Step 1: Install the CORS package

cd backend
npm install cors

Step 2: Add CORS to server.js

const express = require('express');
const cors = require('cors');  // ← ADD THIS

const app = express();
app.use(cors());  // ← ADD THIS

Step 3: Restart both servers

Backend: Ctrl+C then npm run dev
Frontend: Ctrl+C then npm start

Step 4: Hard refresh browser

Ctrl + Shift + R

The Moment It Worked

After fixing CORS, my browser showed:

Backend Status: ✅ Backend is healthy! Service: backend-api

Clicking "Load Users" displayed:

SUCCESS! My frontend and backend were finally talking!

Key Learnings from Day 3

Technical Concepts

Concept	What I Learned
React State	`useState` creates memory for your component. When state changes, UI updates automatically
useEffect	Runs code automatically when component loads (great for fetching initial data)
fetch API	Browser's built-in way to make HTTP requests to APIs
CORS	Browser security that blocks cross-origin requests unless backend allows it
Ports	React uses 3000, backend uses 8000 — different ports = different origins

Problem-Solving Skills

Reading error messages: The CORS error looked scary, but it told me exactly what was wrong
Using browser Console: F12 → Console tab shows all errors
Testing with curl: curl http://localhost:8000/health proved backend was working (curl ignores CORS)
Systematic debugging: Backend works? Yes. Frontend works? Yes. Connection? CORS issue.

Mistakes I Made (And Fixed)

Mistake	Consequence	Fix
Deleted files without updating imports	React compilation error	Removed import lines from index.js
Didn't install CORS package	CORS still blocked	`npm install cors`
Forgot to restart backend	Changes didn't take effect	`Ctrl+C` then `npm run dev`
Didn't hard refresh browser	Saw old cached page	`Ctrl+Shift+R`

Tips for Anyone Building Their First React + API App

Test backend with curl first — If curl works but React doesn't, it's CORS
Always restart servers after changes — They don't auto-reload config
Use browser Console — It's your best friend for debugging
Hard refresh (Ctrl+Shift+R) — Avoid seeing cached old versions
Keep both terminals visible — One for backend, one for frontend

Resources

Let's Connect!

Have you struggled with CORS before? Building your first full-stack app? I'd love to hear about your journey!

Drop a comment or connect on LinkedIn. Let's learn together!

This is Day 3 of my 30-Day Cloud & DevOps Challenge. Follow along as I build a complete microservices platform from scratch!

30-Day Cloud & DevOps Challenge: Day 2 — Building My First Backend API

Michelle — Wed, 01 Apr 2026 13:10:35 +0000

The journey continues! After setting up my project structure on Day 1, today was all about building the heart of my microservices platform: the backend API.

If you missed Day 1, you can catch up here: [https://dev.to/michellewanjiru/day-1-of-my-30-day-cloud-devops-challenge-project-setup-2a5a?trk=public_post_comment-text]

What I Set Out to Do Today

Build a working REST API that can:

Respond to HTTP requests
Return JSON data
Serve as the foundation for my microservices platform

Simple, right? Well... let me share how it actually went.

The Tech Stack I Chose

I decided to go with Node.js + Express for my backend because:

JavaScript is everywhere (frontend, backend, even DevOps tools)
Express is lightweight and beginner-friendly
I already had Node.js installed on my Ubuntu system

Step-by-Step: What I Actually Did

1. Initial Setup

cd backend
npm init -y  # Creates package.json
npm install express  # Web framework
npm install --save-dev nodemon  # Auto-restarts server on changes

What I learned: package.json is like a shopping list for your project. Every tool you add gets listed there, making it easy to share your project with others.

2. Writing My First Server

I created server.js with three endpoints:

const express = require('express');
const app = express();
const PORT = 8000;

// Root endpoint
app.get('/', (req, res) => {
    res.json({ message: 'Welcome to the Microservices Platform API', status: 'running' });
});

// Health check endpoint
app.get('/health', (req, res) => {
    res.json({ status: 'healthy', service: 'backend-api', timestamp: new Date().toISOString() });
});

// Users endpoint (mock data for now)
app.get('/users', (req, res) => {
    res.json([
        { id: 1, name: 'Alice', email: 'alice@example.com' },
        { id: 2, name: 'Bob', email: 'bob@example.com' },
        { id: 3, name: 'Charlie', email: 'charlie@example.com' }
    ]);
});

app.listen(PORT, () => {
    console.log(` Server running on http://localhost:${PORT}`);
});

Understanding each part:

app.get() defines what happens when someone visits a URL
(req, res) => {} is a function that handles the request and sends a response
res.json() sends data back as JSON (the language of APIs)

3. The Challenge That Almost Stopped Me

I tried running my server with:

npm run dev

And got this error:

npm error Missing script: "dev"

My reaction: 😅 Wait, what? I thought I had this!

How I diagnosed it:

npm run  # Shows all available scripts

Only test was showing. I had completely forgotten to add the "dev" script to my package.json!

The fix: I opened package.json and added:

"scripts": {
    "start": "node server.js",
    "dev": "nodemon server.js"
}

Lesson learned: Never assume your configuration is correct. Always verify with simple commands.

4. The Moment It Finally Worked

After fixing the script, I ran:

npm run dev

And saw:

 Server running on http://localhost:8000

Then in another terminal:

curl http://localhost:8000/

Response:

{"message":"Welcome to the Microservices Platform API","status":"running"}

I literally cheered in my chair.🎉 My first API was alive!

Testing All Endpoints

Here's what each endpoint returned:

Endpoint	Response
`GET /`	Welcome message
`GET /health`	Service status with timestamp
`GET /users`	List of 3 mock users

All working perfectly!

Key Learnings from Day 2

Technical Concepts I Gained:

HTTP Methods: GET is how you retrieve data from a server
JSON: The universal language of APIs — both request and response
Ports: Think of them like doors — 8000 is the door my API listens on
Endpoints: Specific URLs that do specific things (/health, /users)
Package.json scripts: Custom commands to automate repetitive tasks

Problem-Solving Skills:

Diagnosing errors: npm run helped me see what was actually available
Reading error messages: "Missing script" told me exactly what was wrong
Step-by-step verification: Test each piece before assuming everything works

Mindset Shifts:

Done is better than perfect: My first API doesn't have a database yet, and that's okay
Celebrate small wins: Getting that first curl response was genuinely exciting
Embrace mistakes: The missing script error taught me more than if everything worked perfectly

Tips for Anyone Starting Their Own API

Start simple. My API only does 3 things right now — that's enough!
Test as you go. Don't write 100 lines of code before testing. Test after each endpoint.
Use curl or browser. It's satisfying to see your API respond in real-time.
Save your package.json changes. I almost forgot this one!
Keep notes. Document what you learn, especially the mistakes.

A Quick Thank You

To everyone following along and the community helping me debug, your support means everything. Special shoutout to those who reminded me to check my package.json scripts!

What's Next (Day 3)

Tomorrow, I'm building a frontend that will:

Fetch data from my API
Display the list of users
Show the health status

It's going to be the first time my frontend and backend talk to each other!

Links & Resources

GitHub Repository: Production-Ready-Microservices-Platform
Express Documentation: expressjs.com
Nodemon: nodemon.io

Let's Connect!

Are you also learning backend development? Building your first API? I'd love to hear about your journey!

Drop a comment below or connect with me on LinkedIn at https://www.linkedin.com/in/michelle-wanjiru-420877275/?lipi=urn%3Ali%3Apage%3Ad_flagship3_detail_base%3BHw%2F74ryNQ7CjXqDkL3k7eQ%3D%3D. Let's learn together!

This is Day 2 of my 30-Day Cloud & DevOps Challenge. Follow along as I build a complete microservices platform from scratch!

Day 1 of My 30-Day Cloud & DevOps Challenge — Project Setup

Michelle — Tue, 31 Mar 2026 08:39:12 +0000

Today marks the start of my 30-day Cloud & DevOps challenge, and I focused on laying a strong foundation for the project. Before diving into code, I wanted to ensure the structure, documentation, and workflow are clear—because a well-organized project makes everything else much easier.

What I Did Today

Created GitHub repository — the central place to track code, documentation, and collaboration.
Planned project architecture — decided on a three-part system:
- Frontend — the user interface
- Backend — API and business logic
- Database — persistent data storage
Created basic folder structure:

  /frontend
  /backend
  /infra       # Terraform configs for cloud infrastructure
  /k8s         # Kubernetes manifests
  /ansible     # Configuration management playbooks
  /jenkins     # CI/CD pipeline scripts
  README.md
  ROADMAP.md

Why this structure?

Separates concerns clearly: each component has its own space.
Makes scaling easier—if I add more microservices, the structure can accommodate them.
Keeps infrastructure and deployment configurations isolated from application code.
Documentation (README.md, ROADMAP.md) stays at the root for visibility.
- Added initial documentation:
README.md — outlines project goal, architecture, tech stack, and future progress.
ROADMAP.md — a detailed 30-day plan that breaks down daily tasks and objectives.
- Planned Git branching strategy:
Using conventional commit prefixes for clarity:
- feat/ → new features
- fix/ → bug fixes
- docs/ → documentation updates
- chore/ → general maintenance tasks
Workflow:
- main branch — always stable
- develop branch — integration of features before merging to main
- Feature branches (feat/...) branch off develop and merge back via pull requests.

Why These Decisions Matter

Starting with a solid structure and clear workflow ensures:

Consistency across development
Easier collaboration if others join
Smooth CI/CD and deployment setup later
Traceability of changes through meaningful commits and branches

Next Steps

Tomorrow, I’ll begin building the backend API and setting up the database. The foundation is ready, now it’s time to code, containerize, and gradually bring the infrastructure to life.

Why Branch Naming Conventions Matter More Than You Think

Michelle — Wed, 25 Mar 2026 22:07:56 +0000

From final-final-v2 to Something That Makes Sense

I used to name my Git branches like I was improvising under pressure.

update
new-code
try-again
final-final-v2

At the time, it made perfect sense. I knew what I was working on. Until I came back a few days later. Or worse, until someone else had to look at my work.

That’s when it hit me: branch naming isn’t just labeling. It’s communication.

In professional software development, poor communication doesn’t just slow you down, it breaks teams.

Why Do Branch Names Even Matter?

A branch name is the first thing people see before they read your code. A good branch name should instantly answer:

What is being worked on?
Why does it exist?
Is it a feature, a fix, or something else?

If someone has to open your code to understand your branch, you’ve already made things harder than necessary. A well-named branch is like a good commit message: it saves time, reduces confusion, and makes collaboration smoother.

The Standard Naming Pattern

Most professional teams follow a simple structure:
category/description

Or, when working with task tracking tools:
category/taskID-description

This isn’t about being strict for no reason. It’s about traceability and clarity.

Common Branch Categories

Category	Purpose	Example
feat	New features	`feat/login-page`
fix	Bug fixes	`fix/header-alignment`
docs	Documentation changes	`docs/update-install-guide`
refactor	Code improvements (no behavior change)	`refactor/api-auth-logic`
test	Adding or fixing tests	`test/ant-movement-logic`
chore	Maintenance tasks	`chore/update-go-mod`
perf	Performance improvements	`perf/optimize-bfs-search`
ci	CI/CD configuration changes	`ci/github-actions-setup`

Notice something? None of them say "stuff," "things," or "updates." Shocking, I know.

Best Practices for Naming Branches

1. Use Kebab Case (Hyphens, Not Chaos)

Stick to lowercase and separate words with hyphens.

feat/add-user-profile ✔️
feat/Add_User_Profile ❌

Why? It's easier to read, consistent, and plays nicely with CLI tools. Underscores and random capitalization just add friction.

2. Include Ticket or Task IDs

If you're using Jira, Trello, or GitHub Issues, include the task ID:
fix/LEM-42-invalid-coord-check

This creates a direct link between the code, the requirement, and the discussion behind it. Future you will be grateful.

3. Be Descriptive, Not Overdramatic

Bad: feat/fix-everything-broken-in-parser-because-life-is-hard
Better: feat/parser-ignore-extra-hashes

Make it clear and concise.

4. Keep Branches Short-Lived

A branch is not a long-term commitment.

Good workflow: Create → Work → Merge → Delete.
Bad workflow: Create → Forget → Revive → Break → Panic.

A Simple Workflow Example

Let’s say you’re working on a project like Lem-in. Here’s what clean branch usage looks like:

# Implement a new feature
git checkout -b feat/bfs-implementation

# Fix a documentation issue
git checkout -b docs/fix-readme-typo

# Improve performance
git checkout -b perf/graph-adjacency-optimization

Without opening a single file, anyone on your team already understands what’s happening. That’s the whole point.

What Changed for Me

Learning this didn’t feel like a big deal at first. It’s just naming things, right? But it forced me to think differently:

Be clear about what I’m doing.
Be intentional with my work.
Consider the people reading my code.

And that’s really what good engineering is about.

Final Thoughts

Clean code is important, but clean communication is what makes collaboration work. Branch naming sits at the intersection of organization, teamwork, and maintainability.

If your branches still look like final-final-v3-this-one-works, it’s not a Git problem, it’s a discipline problem.

How a Video Travels Across the World to Reach Your Screen

Michelle — Sun, 22 Mar 2026 08:05:42 +0000

Introduction

You click on a video.

It pauses for a fraction of a second, then begins to play as if nothing complicated just happened.

But in that instant, a chain reaction is triggered across continents, oceans, and machines. Data moves through systems designed with extreme precision, all to deliver a seamless experience.

This is what actually happens.

The Misconception: Why Satellites Don’t Power the Internet

It’s natural to assume the internet runs through satellites. Space feels like the fastest, most direct route.

In practice, satellites are rarely used for everyday internet traffic like video streaming.

The reason is latency.

A signal sent to a satellite must travel tens of thousands of miles into space and back. That round trip introduces delays that make real-time experiences feel slow and inconsistent.

Instead, the internet relies on something far more grounded and far more efficient.

The Real Backbone: Fiber Optic Cables

The internet is physical.

It exists as a vast network of fiber optic cables laid underground and across ocean floors. These cables transmit data as pulses of light, allowing information to travel at incredible speeds over long distances.

Entire continents are connected this way.

When you stream a video, your data is often traveling through these underwater cables quietly carrying information across the planet.

Where Content Lives: Data Centers and Servers

Before a video can reach you, it has to exist somewhere.

That place is a data center.

Inside are servers, specialized computers built to store, process, and deliver content at scale. They rely on solid-state drives (SSDs) because speed and reliability are critical.

When you press play, a server retrieves the video and begins sending it toward your device.

Identity on the Internet: IP Addresses and Domain Names

Every device on the internet has a unique identifier called an IP address.

This is how data knows where to go.

But raw IP addresses aren’t designed for humans. That’s why domain names exist.

Instead of remembering something like:

142.250.190.14

You use something simple and readable:

youtube.com

Domain names are a human-friendly layer on top of machine-level addressing.

DNS: Translating Names Into Locations

When you type a domain name, your system needs to find the corresponding IP address.

This is handled by the Domain Name System (DNS).

DNS acts like a global lookup service. It takes the name you entered and returns the exact address of the server hosting the content.

Without DNS, using the internet would mean memorizing long numerical identifiers for every site.

How Data Actually Moves: Packets

A video is not sent as a single, continuous file.

It is broken into smaller pieces called packets.

[Packet 1] -> [Packet 2] -> [Packet 3] -> ...

Each packet travels independently across the network and may take a completely different route.

This approach makes the system faster and more resilient. If one path is congested, packets can be rerouted dynamically.

When they arrive, your device reassembles them into the original video stream.

Routing the Journey: Routers and Signal Conversion

As packets move through the network, they pass through routers.

Routers determine the most efficient path for each packet in real time, constantly adapting to network conditions.

They also handle signal conversion.

Fiber optic cables carry data as light. When that data reaches your local network, routers convert it into electrical signals that your devices can understand.

Who Keeps Order: ICANN

With billions of devices connected globally, coordination is essential.

This responsibility falls to ICANN (Internet Corporation for Assigned Names and Numbers).

ICANN ensures that:

Every domain name is unique
IP addresses are properly allocated
The system remains globally consistent

Without this level of coordination, the internet would quickly become unreliable.

The Rules That Make It Work: Protocols

None of this works without a shared set of rules.

These rules are called protocols.

They define how data is:

Broken into packets
Transmitted across networks
Reassembled at its destination

Protocols ensure that systems built in different parts of the world can communicate without conflict.

Why This Matters

The internet feels instant, but it is anything but simple.

Every video you watch depends on:

Physical infrastructure spanning the globe
Systems for identifying and locating devices
Rules governing how data is transmitted
Machines working continuously behind the scenes

All of this happens in seconds, often without you noticing.

That's why streaming a video feels effortless.

But behind that simplicity is a deeply coordinated system of infrastructure, computation, and rules working together in real time.

The next time you press play, consider what just happened.

A request left your device, crossed continents, located the right server, and returned as a perfectly assembled stream of data

All in the time it took you to blink.

GitHub Workflows and CI/CD: The System Behind Every Functional Team

Michelle — Sun, 22 Mar 2026 07:41:17 +0000

Code Isn’t the Problem

Most developers think the hard part is writing code.

It’s not.

The real difficulty shows up the moment you’re not working alone.

Multiple people pushing changes. Features colliding. Bugs appearing out of nowhere.

Suddenly, it’s not about what you build.

It’s about how changes move through your system.

The Reality: Code Needs a Process

In a team, code doesn’t just exist.

It has a lifecycle.

It’s introduced. Tested. Reviewed. Merged. Deployed.

Without structure, that lifecycle breaks.

That’s where GitHub workflows and CI/CD pipelines come in.

GitHub Workflows: Controlling the Chaos

A GitHub workflow isn’t just about branches.

It’s a system for managing change safely.

A simple structure most teams use:

main → production-ready code
develop → integration branch
feature/* → new work
fix/* → bug fixes

Example branch names:

feature/payment-integration
fix/api-timeout

This creates clarity.

You know what someone is working on without opening the code.

The Flow: What Happens to Every Change

Every change follows a path:

Create a branch from develop
Build your feature
Push your code
Open a Pull Request
Run automated checks
Get reviewed
Merge into develop
Deploy through main

This isn’t bureaucracy.

It’s protection against chaos.

CI/CD: Where Things Become Automatic

Workflows define how things should happen.

CI/CD makes sure they actually do.

Continuous Integration means every time you push code:

Tests run
Code builds
Errors are caught early

Continuous Deployment means:

Approved code is deployed automatically
No manual steps
No guesswork

Example: GitHub Actions Pipeline (Go)

name: Go CI Pipeline

on:
  push:
    branches: [ "develop", "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  test-build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - uses: actions/setup-go@v4
        with:
          go-version: '1.21'

      - run: go mod tidy
      - run: go test ./...
      - run: go build ./...

Without CI/CD:

Testing depends on humans
Bugs reach production
Deployments feel risky

With CI/CD:

Every change is verified
Teams move faster with confidence
Collaboration becomes smoother

Where we Go Wrong

No branch naming convention → confusion
Skipping pull requests → no review
No automated tests → CI is useless
Overcomplicating pipelines → everything slows down

Conclusion

GitHub workflows and CI/CD are not advanced topics.

They are the foundation of working with others.

Code matters.

But the system around your code is what makes everything actually work.

🧵 Goroutines, Channels, and the Quiet Beauty of Concurrency in Go

Michelle — Fri, 20 Mar 2026 17:10:27 +0000

There’s a moment every Go developer hits.

At first, goroutines feel like magic, you sprinkle go in front of a function and suddenly things run at the same time. Fast. Clean. Almost too easy.

And then… confusion creeps in.

“Why is this value wrong?”
“Why is my program stuck?”
“Why does this work sometimes… but not always?”

That’s when you realize:

Go’s concurrency model isn’t just about running things at once, it’s about coordination.

Let’s walk through it like humans, not textbooks.

Goroutines: Tiny Workers With a Job

Think of goroutines as tiny workers you can spin up instantly.

You don’t manage them. You don’t schedule them.

You just give them work and let Go figure out the rest.

go fetchData()
go processImage()
go sendEmail()

Each of these runs independently.

What makes goroutines special is not just that they’re concurrent, it’s that they’re lightweight enough to feel disposable. You stop worrying about “cost” and start thinking in terms of tasks.

The Subtle Truth: Concurrency Is Coordination

A lot of people think concurrency is about speed.

It’s not.

It’s about structuring your program so multiple things can happen without stepping on each other.

Speed is just a side effect.

Channels: Conversations, Not Pipes

Now imagine those goroutines as people in a room.

If they all start talking at once without structure, it’s chaos.

Channels bring order.

They’re not just data pipes, they’re conversations with rules.

ch := make(chan string)

When you send:

ch <- "done"

And receive:

msg := <-ch

Something deeper is happening:

One goroutine is saying: “I’m ready to hand this off.”

Another is saying: “I’m ready to receive it.”

They meet at that exact moment.

The Magic of Blocking

Here’s where Go does something beautiful.

Channels block by default.

If you send and no one is receiving → you wait
If you receive and no one has sent → you wait

No extra code. No explicit synchronization.

It’s like a handshake, both sides have to be ready.

A Small, Human Example

func worker(ch chan string) {
    // doing some work...
    ch <- "I'm done"
}

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

    go worker(ch)

    message := <-ch
    fmt.Println(message)
}

There’s no explicit “wait” here.

But main waits anyway — because it’s listening.

That’s synchronization, quietly happening under the hood.

Buffered Channels: When Timing Doesn’t Have to Match

Real life isn’t always a perfect handshake.

Sometimes you leave a message and walk away.

That’s what buffered channels are:

ch := make(chan int, 2)

Now you can do:

ch <- 1
ch <- 2

And the sender doesn’t immediately block.

It’s like dropping letters into a mailbox, as long as there’s space, you don’t have to wait.

When Sharing Becomes Inevitable

So far, everything feels clean.

Goroutines talk through channels. No shared state. No problems.

But in real systems, you will end up sharing data.

And that’s where things get dangerous.

The Problem: Race Conditions

Consider this:

var counter int

func increment() {
    counter++
}

Looks harmless.

But under the hood, counter++ is:

Read the value
Add 1
Write it back

Now imagine two goroutines doing this at the same time.

They can step on each other, and suddenly your count is wrong.

Not always. Just enough to make debugging painful.

Mutex: A Simple but Powerful Guard

A mutex is not fancy.

It just says: “One at a time.”

var mu sync.Mutex
var counter int

func increment() {
    mu.Lock()
    counter++
    mu.Unlock()
}

Now, no matter how many goroutines call increment, only one can modify counter at once.

It’s like a single key to a locked room, whoever holds it gets exclusive access.

Channels vs Mutex: A Practical Way to Think About It

This is where many developers get stuck.

So here’s a grounded way to decide:

If you’re passing data between goroutines → use channels
If you’re protecting shared data → use a mutex

Or even simpler:

Use channels when you can.

Use mutexes when you must.

What’s Really Happening Under the Hood

When you write concurrent Go code, you’re designing a system of:

Independent workers (goroutines)
Communication paths (channels)
Safety boundaries (mutexes)

If any of these are missing or misused:

You get deadlocks (everything waits forever)
Or race conditions (things break unpredictably)

The Mindset Shift

The real shift isn’t technical, it’s mental.

You stop thinking:

“How do I make this faster?”

And start thinking:

“How do I let these pieces work independently, but safely?”

Try This Yourself

A simple exercise:

Spin up multiple goroutines
Let each send a number into a channel
Collect and sum them in main

Then try the same thing using:

a shared variable
a mutex

You’ll notice something subtle:

Channels feel like coordination.

Mutexes feel like control.

Both are useful, but they feel different.

Final Thought

Go’s concurrency model isn’t just a tool, it’s a philosophy.

It nudges you toward writing programs that don’t just run…

…but programs where things move, communicate, and flow together.

And once that clicks, concurrency stops being scary

and starts being something you can actually enjoy.

The Dart async/await Function: What Your App Is Actually Doing When It Says “Loading…”

Michelle — Mon, 09 Feb 2026 07:53:13 +0000

For a long time, I thought “loading” meant my app was stuck.

Not broken. Just frozen. Waiting. Politely doing nothing until the data finally showed up.

That idea lived in my head every time I saw a loading spinner. I didn’t question it. I accepted that this was how apps worked and hoped for the best.

Then one day, it stopped making sense.

The Picture I Had in My Head

I imagined my Dart app working like this:

Run some code
Hit an await
Everything stops
The app waits
Data arrives
The app continues

Simple. Linear. Comforting.

Except real apps don’t behave like that. And once you notice it, you can’t unsee it.

Buttons still respond. Animations still move. Logs still appear. The app is clearly alive.

So what exactly is “waiting”?

“Loading” Is a Friendly Lie

When an app shows “Loading…”, it’s not describing what the app is doing.

It’s describing what you are waiting for.

Behind the scenes, your Dart app is still running. It just refuses to block itself for one slow operation like a network request or a database call.

Instead, it quietly says:

“I’ll come back to this later.”

And then it keeps going.

What `async` and `await` Really Mean in Dart

This was the moment things clicked for me.

await does not pause the entire program.

It pauses one function.

That’s it.

When a Dart function hits an await, it steps aside. The event loop keeps running. Other tasks continue. UI updates still happen. The app stays responsive.

The future you’re waiting on finishes when it finishes, and Dart calmly resumes that function later.

No freezing.
No global pause.
No drama.

Why This Was So Confusing at First

As beginners, we think in steps.

Line 1 runs.
Line 2 runs.
Line 3 runs.

Async code breaks that mental model.

Now things start, pause, resume, and overlap. Not randomly, but not in a straight line either.

Once I stopped forcing async code into a linear story, it stopped feeling mysterious.

It wasn’t magic.

It was scheduling.

The Real Meaning of “Loading…”

Now when I see a loading spinner, I read it differently.

It doesn’t mean:
“Nothing is happening.”

It means:
“Something is happening somewhere else, and we’ll let you know when it’s done.”

That small shift changed how I debug, how I read logs, and how I write async functions in Dart.

Why This Matters

If you’re working with Dart, Flutter, or any modern framework, async is everywhere.

Most mistakes don’t come from syntax errors. They come from the wrong mental picture.

Once you understand that your app is always running and await is just a polite pause, things feel calmer. Clearer. Less fragile.

Final Thought

In the end, I realized my app was never frozen.

It was busy.

It just didn’t think I needed all the details.

Forem: Michelle

30-Day Cloud & DevOps Challenge: Day 7 — Docker Compose: One Command to Rule Them All

First: What Problem Does Docker Compose Solve?

Without Docker Compose (Days 5 & 6)

With Docker Compose (Today)

What is Docker Compose?

The Analogy

Step 1: Creating docker-compose.yml

Step 2: Writing the Compose File (Line by Line)

Line 1: Version

Line 2: Services Section

Lines 3-6: Backend Service

Lines 7-10: Frontend Service

The Complete File

Step 3: What Docker Compose Does Behind the Scenes

Step 4: Running Everything

Step 5: Testing Everything

Testing the Backend

Testing the Frontend

Step 6: Stopping Everything

Docker vs Docker Compose: The Comparison

Why Your Project NEEDS Docker Compose

Your Architecture

Without Compose (Manual Nightmare)

With Compose (One File)

Issues I Ran Into

Issue 1: "no configuration file provided"

Issue 2: Port already allocated

Issue 3: The "version is obsolete" warning

Docker Compose Commands Cheat Sheet

Key Takeaways

Resources

30-Day Cloud & DevOps Challenge: Day 6 — Dockerizing My React Frontend

First: How Frontend Docker is Different

Step 1: Building React for Production

Navigate to frontend folder

Build the production version

Verify the build folder

Step 2: Creating the Dockerfile

Why nginx?

Create the Dockerfile

The Complete Dockerfile

Understanding Each Line

What is /usr/share/nginx/html?

Save and verify

Step 3: Building the Frontend Image

Verify the image

Step 4: Running the Frontend Container

Step 5: Testing the Container

Open browser

Check running containers

Running Both Containers

Step 6: Stopping the Container

What I Learned

Why nginx for Frontend?

Production Build vs Development

The Build Process Explained

Mistakes I Made (And Fixed)

Mistake 1: Trying to use npm start in Docker

Mistake 2: Wrong COPY destination

Mistake 3: Forgetting to run npm run build

Docker Commands Cheat Sheet (Updated)

Key Takeaways

Resources

Let's Connect!

30-Day Cloud & DevOps Challenge: Day 5 — Dockerizing My Backend (First Steps into Containers)

First: What Even IS Docker? (Explained Simply)

The Problem Docker Solves

The Docker Solution

Step 1: Checking Docker Installation

Fixing Docker Permissions

Step 2: Creating the Dockerfile

What is a Dockerfile?

Creating the File

The Complete Dockerfile (Line by Line)

Why Each Line Matters

Step 3: Building the Docker Image

Verifying the Image

Step 4: Running the Container

Step 5: Testing the Container

What is `/usr/share/nginx/html`?

Mistake 1: Trying to use `npm start` in Docker

Mistake 3: Forgetting to run `npm run build`