DEV Community: John Afariogun

The Middle Child Syndrome: Why Your Frontend might not be able to Talk to it's Docker Siblings

John Afariogun — Fri, 20 Feb 2026 15:58:08 +0000

Containerizing full-stack apps reveals a harsh reality—your React frontend is the awkward middle child that can't speak to its Docker siblings.

Containerizing a full-stack application is a rite of passage for every DevOps-leaning engineer. You successfully get your Node.js backend talking to PostgreSQL, your Python ML service crunching data, and Redis caching everything in between.

But then, the "Middle Child" enters the room: The Frontend.

Despite being part of the docker-compose.yml family, the frontend often feels isolated, unable to speak the same internal language as its Docker siblings. Here's why it happens and how to solve it.

The Family Reunion That Excluded Frontend

I recently orchestrated a multi-service e-commerce app with:

Backend (Node.js/Express)    ✅ Connected
ML Service (Python/Flask)    ✅ Connected  
PostgreSQL Database          ✅ Connected
Redis Cache                  ✅ Connected
React Frontend               ❌ Left outside in the cold

Inside the Docker bridge network, life was beautiful. My backend could reach the ML service simply by using the service name:

// Inside the backend container
const response = await fetch('http://ml-service:5000/recommendations/42');
// ✅ Works perfectly!

The Docker DNS handles the heavy lifting. Services on the same bridge network are family.

# docker-compose.yml - Happy family networking
services:
  backend:
    networks: [app-network]
  ml-service:
    networks: [app-network]
  postgres:
    networks: [app-network]
  redis:
    networks: [app-network]

networks:
  app-network:
    driver: bridge

Frontend Got Kicked Out (The Harsh Reality)

Then I tried the same thing from my React frontend:

// React frontend trying to join the family...
fetch('http://backend:8080/api/products')
  .then(res => res.json())
  .catch(err => console.error('Sibling rivalry:', err));

Browser Console:

net::ERR_NAME_NOT_RESOLVED

Why Did This Fail?

The "Middle Child Syndrome" stems from a fundamental misunderstanding of where the code actually runs:

Backend code runs inside the Docker container → uses Docker's internal DNS
Frontend code is delivered by Docker, but executes in the user's browser

The browser lives on your host machine (your device), not inside the Docker bridge network. Your device's DNS has no idea what http://backend is. The Docker network is a private club your browser doesn't have membership for.

Browser ←─── HTTP ───► ??? ──── Docker Network ───► Services
  │                              (backend, ml, db, redis)
  │
  └── Can't reach Docker DNS directly ❌

The Solutions: Pick Your Poison

1. Expose Everything (Security Nightmare ⚠️)

The quickest fix is to expose every service to your host machine:

services:
  backend:
    ports:
      - "8080:8080"  # Now public on localhost
  ml-service:
    ports:
      - "5000:5000"  # Exposed to internet

React calls http://localhost:8080, also calls http://localhost:5000 ✅ Works, but you've just exposed all your internal services to the entire internet. In production, this is a massive security "no-go."

2. Backend Proxy (Secure & Simple)

Route frontend requests through your backend, which can access Docker DNS:

services:
  backend:
    ports:
      - "8080:8080"  # Single exposed port
  ml-service:
    # No ports exposed - internal only

Backend proxies ML requests:

// backend/server.js
app.get('/api/ml/:path*', async (req, res) => {
  const mlUrl = `http://ml-service:5000/${req.params.path}`;
  const response = await fetch(mlUrl);
  res.json(await response.json());
});

React calls /api/ml/recommendations → Backend proxies to ml-service:5000 ✅ Secure + elegant.

3. Nginx Reverse Proxy (Production Ready)

This is the most architecturally sound approach. Put a "Gatekeeper" in front of your family:

services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf

  frontend:
    # No ports exposed

  backend:
    # No ports exposed

  ml-service:
    # No ports exposed

nginx.conf:

server {
    listen 80;

    location /api/ {
        proxy_pass http://backend:8080/;
    }

    location /ml/ {
        proxy_pass http://ml-service:5000/;
    }

    location / {
        proxy_pass http://frontend:3000/;
    }
}

Now your frontend only talks to one place: the Nginx port. Nginx lives inside the Docker network and handles routing to all siblings.

Browser ←─── HTTP ───► Nginx (port 80) ──── Docker Network ───► Services ✅

The Root Cause: Network Architecture Mismatch

Docker bridge networks solve:

✅ Service-to-service communication
✅ Container DNS resolution
❌ Browser-to-container (without port mapping or proxy)

The fix requires understanding execution context:

Code Location	Runs Where?	Can Use Docker DNS?
`backend/server.js`	Inside container	✅ Yes
`ml-service/app.py`	Inside container	✅ Yes
`frontend/src/App.jsx`	In browser	❌ No

Lessons Learned (The Hard Way)

Execution Context is King - Always ask: "Where is this code actually running?" If it's a .jsx file, it runs in the browser, not Docker.
One Ingress Point - Avoid "Swiss Cheese" security. Expose one port (80/443) and route everything internally.
Environment Variables Save Lives:

   const API_URL = import.meta.env.VITE_API_URL || 'http://localhost:8080';

CORS is Your Friend - Configure properly on all services that Nginx proxies:

   app.use(cors({ origin: process.env.ALLOWED_ORIGINS }));

Complete Working Example

version: '3.8'

services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on: [frontend, backend]

  frontend:
    build: ./frontend
    # No ports - accessed via nginx

  backend:
    build: ./backend
    environment:
      DB_HOST: postgres
      REDIS_URL: redis://redis:6379
    # No ports - accessed via nginx

  ml-service:
    build: ./ml-service
    # Internal only

  postgres:
    image: postgres:15
    environment:
      POSTGRES_DB: shopmicro

  redis:
    image: redis:alpine

networks:
  default:
    driver: bridge

The frontend middle child finally found its place - behind a proxy, secure, and talking to all its Docker siblings through proper networking architecture.

What's Next?

In my next post, I'll share how I took this ShopMicro architecture and scaled it into a Kubernetes cluster with Ingress controllers—where the networking gets even more "fun."

🔔 Notifycli: A Lightweight Go CLI for Firebase Push Notifications

John Afariogun — Fri, 05 Dec 2025 08:28:00 +0000

Need to send push notifications to your mobile or web clients — from the command line, a backend script, or a CI/CD pipeline — without building a full backend server?
Notifycli is a simple, Go-based CLI that does exactly that: use Firebase Cloud Messaging (FCM) credentials + a device token to send push notifications.

In this post, I unpack the code, show installation and usage, and highlight how it's built — so you can use or extend it for your own projects.

What is Notifycli?

According to the project README:

Notifycli is a “Go CLI for sending push notifications to mobile and web devices using Firebase Cloud Messaging.” (GitHub)
It supports sending to a single device (via FCM device token), and allows custom data payloads — e.g. a title, body, optional URL — which your app can use for deep linking or redirection. (GitHub)
It uses a clean project structure based on the popular CLI framework Cobra for subcommands and flag parsing. (GitHub)

Because it's a standalone binary (no heavy deps, no web server), it works well for automation: cron jobs, server scripts, deployment hooks, or any backend that just needs to “fire-and-forget” an FCM push.

Project Structure & Architecture

Here’s how the repo is structured: (GitHub)

Notifycli/
 ├── cmd/
 │    ├── root.go         # CLI root command definitions
 │    └── notify.go       # “notify” subcommand: sends a notification
 ├── internal/
 │    └── firebase/
 │         └── client.go  # Firebase FCM client wrapper
 ├── main.go              # Entry point
 ├── go.mod / go.sum      # Module definitions
 ├── test/                # (optional) tests
 └── README.md

Highlights:

cmd/: Uses Cobra to define commands and flags.
internal/firebase/client.go: Encapsulates FCM initialization, authentication using a Firebase service-account JSON key, and the logic to send notifications via FCM REST API. (GitHub)
Minimal external dependencies — this keeps the binary lightweight and portable.
Easy to integrate with scripts, cron jobs, CI/CD pipelines — you just call notifcli notify ....

How to Build & Use

1. Clone & Build

git clone https://github.com/johnafariogun/Notifycli.git
cd Notifycli
go build -o notifcli
# optionally:
go install

2. Provide Firebase Credentials

Go to your Firebase project → Project Settings → Service Accounts → Generate new private key.
Download the serviceAccount.json and place it in your project root (or anywhere you like, but pass its path with --creds). (GitHub)

3. Send a Notification via CLI

notifcli notify \
  --token <DEVICE_FCM_TOKEN> \
  --title "Deployment Successful" \
  --body "Your service is live." \
  --creds /path/to/serviceAccount.json

Optional flag: --url, to include a link in the data payload (useful for app deep links or redirect URLs). (GitHub)

That’s all — a simple, one-liner to trigger a push notification from anywhere.

Under the Hood: What’s Going On

The CLI parses flags (token, title, body, url, creds) via Cobra in cmd/notify.go. (GitHub)
The internal/firebase/client.go module: initializes a Firebase app using the provided service account, constructs the FCM message (with title/body, and optional data payload containing link), and sends the request to FCM via HTTPS. (GitHub)
Error handling covers cases like missing credentials, invalid FCM token, or network failures. The CLI prints descriptive error messages. (GitHub)
Because it's a native Go binary, it’s cross-platform (Linux, macOS, etc.) and doesn’t require runtime dependencies beyond Go’s standard library + net/http.

Why This Tool Matters

Simplicity & Speed: No need to build a full backend just to send notifications.
Automation-friendly: Great for deployment scripts, CI/CD, cron jobs, or server-side alerts.
Portable: Build once, deploy anywhere.
Extensible: You can extend internal/firebase/client.go to support more advanced FCM features — e.g. topic messages, batch sends, custom data payloads, image notifications. The architecture is clean and modular. (GitHub)

Wrap-up & Final Thoughts

Notifycli is a great example of how a small, focused tool can do one thing well — in this case: send FCM push notifications — and integrate easily into scripts, automation, or backend workflows.
Its clean Go + Cobra structure and minimal dependencies make it perfect for developers or DevOps workflows that don’t need a full backend server just for notifications.

If you need a lightweight, scriptable, cross-platform tool for mobile/web push notifications — especially useful for deployment alerts, status updates, or automation — give Notifycli a try.

A2A adventures

John Afariogun — Mon, 03 Nov 2025 17:43:20 +0000

Building a GitHub Issues Agent with FastAPI and A2A

This project demonstrates a small agent that receives A2A JSON-RPC messages and returns GitHub issues for a repository. It is intentionally minimal — focusing on clear message schemas, simple HTTP fetch logic, and deterministic behavior.

Motivation

I wanted an agent that can be called by other systems via an A2A JSON-RPC contract and that returns a small, well-formed payload containing issue metadata and a short textual summary.

Architecture

FastAPI for the HTTP server and lifecycle management
Pydantic models (in models/a2a.py) for the message contract
A single agent implementation (agents/github_issues_agent.py) that extracts the repository and calls a tool function utils.fetch_issues to get the data from GitHub

Implementation notes

agents/github_issues_agent.py extracts owner/repo strings from the message parts. It builds a TaskResult that includes a textual summary and an artifact containing the full issues payload.
utils/fetch_issues uses httpx and handles rate-limit behavior by allowing a GITHUB_TOKEN in the environment.

You can check it out at github.com/johnafariogun/github_app
— End

🐱 My HNG 13 Stage 0 Task — Building a Simple Cat Facts API with FastAPI

John Afariogun — Thu, 16 Oct 2025 10:45:06 +0000

After getting to the penultimate stage in HNG12 internship earlier this year, my perfectionist tendencies cropped up again and this time I want to get to the ultimate stage. First though I have to start from the scratch so stage 0 it is.

The goal for Stage 0 was straightforward:

👉 Build a small backend application that returns some personal info — and something extra (Cats facts).

🚀 Project Overview

This project, called Cat Facts API Integration, fetches random cat facts from the public Cat Facts API and combines them with basic user information.

It includes three simple endpoints:

/ → Root welcome route
/health → Health check
/me → My personal info + a random cat fact

All built with FastAPI, httpx, and a bit of structured logging.

🧩 Project Structure


HNG13_simple_rest_stage_0/
├── app.py
├── app.log
├── requirements.txt
└── README.md

The app includes:

FastAPI for routing and documentation
httpx for making async API requests
logging for monitoring
CORS middleware for flexible frontend integration if need be

🧭 Endpoints Documentation

Method	Endpoint	Description
`GET`	`/`	Root endpoint that returns a welcome message.
`GET`	`/health`	Confirms that the API is healthy and reachable.
`GET`	`/me`	Returns user info (email, name, stack) along with a random cat fact.

🧪 Example Response

GET /me

json { "status": "success", "user": { "email": "afariogun.john2002@gmail.com", "name": "John Afariogun", "stack": "Python/FastAPI" }, "timestamp": "2025-10-15T10:00:00Z", "fact": "Cats sleep for around 70% of their lives." }

🧰 Running the App Locally

To test this project on your system:

bash git clone https://github.com/johnafariogun/HNG13_simple_rest_stage_0 cd HNG13_simple_rest_stage_0 pip install -r requirements.txt

Then start the server:

bash python app.py

Visit these URLs in your browser:

http://127.0.0.1:8080
http://127.0.0.1:8080/me
http://127.0.0.1:8080/docs → to explore the auto-generated FastAPI documentation

You can checkout (mine)[https://hng13simplereststage0-production.up.railway.app/me]

📸 OpenAPI Documentation

FastAPI automatically provides Swagger UI for your routes:

🧭 Navigate to /docs
You’ll see your /, /health, and /me routes neatly documented — no extra setup needed!

🌍 Deployment

So I deployed this on Railway

You can check out how to deploy a fastapi app on railway at the official docs

💡 What I Learned

How to set up a simple FastAPI app
How to call external APIs asynchronously using httpx
How to implement logging and error handling
How to structure JSON responses neatly
The power of automatic documentation in FastAPI
How to deploy using Railway

🔚 Conclusion

Stage 0 may look simple, but it’s where the foundation for cleaner, production-ready APIs begins.

This project taught me how small things — like handling timeouts, errors, and logs — make a huge difference when building real backend systems.

Next step? Stage 1 of HNG 13, probably focusing on testing, deployment, and CI/CD 🚀

👨‍💻 Author: John Afariogun
Stack: Python / FastAPI
GitHub: @johnafariogun
Email: afariogun.john2002@gmail.com