My Journey with Docker and React - From Frustration to Flow

A React developer's personal story of containerizing applications and lessons learned along the way

The "It Works on My Machine" Problem

It was 2:00 AM, and I was still awake, staring at my screen with bloodshot eyes. "But it works on my machine!" I insisted to my teammate over Slack. We had a demo with a client in just 6 hours, and the app that worked flawlessly on my laptop was crashing when my colleague tried to run it.

Sound familiar? This was my life before I discovered the magic of Docker.

As a React developer, I've spent countless hours fighting environment issues. Different Node versions. Missing dependencies. Mismatched environment variables. The web development equivalent of "Mercury is in retrograde" – unexplainable problems that waste precious development time.

That sleepless night was my turning point. I decided there had to be a better way, and that's when I dove headfirst into Docker. Today, I want to share my journey of containerizing React applications – the struggles, the victories, and everything I wish someone had told me when I started.

My First Docker Container - A Comedy of Errors

My first attempt at Dockerizing a React app was... let's call it a learning experience. I started with a simple Create React App project and the most basic Dockerfile imaginable:

FROM node:latest
WORKDIR /app
COPY . .
RUN npm install
CMD ["npm", "start"]

I was so proud when I built my first image and ran it. That pride lasted approximately 30 seconds until I realized my container crashed immediately. No error messages, just silent failure.

After hours of Googling and head-scratching, I discovered multiple rookie mistakes:

1. I hadn't exposed any ports
2. I was using npm start which tries to launch in interactive mode
3. I hadn't considered that node_modules was being copied over

Here's what my working version eventually looked like:

FROM node:18-alpine
 
WORKDIR /app
 
COPY package.json package-lock.json ./
RUN npm install
 
COPY . .
 
EXPOSE 3000
 
CMD ["npm", "start"]

But even then, I realized I was only solving part of the problem. This worked for development, but what about production?

The Production Epiphany

The moment it clicked for me was when I deployed my first Dockerized React app to production. I'd been using the development server in containers, which is fine for testing but terrible for production.

I remembered that React apps are just static files after building. I didn't need a complex Node.js server - I just needed something to serve those files efficiently.

That's when I discovered multi-stage builds. This pattern changed everything:

# Build stage
FROM node:18-alpine as build
 
WORKDIR /app
 
COPY package.json package-lock.json ./
RUN npm ci
 
COPY . .
RUN npm run build
 
# Production stage using nginx
FROM nginx:alpine
 
# Copy built files from the build stage
COPY --from=build /app/build /usr/share/nginx/html
 
EXPOSE 80
 
CMD ["nginx", "-g", "daemon off;"]

The first time I deployed this to production, my app loaded lightning fast. The container was tiny compared to my development version, and it consumed far fewer resources. I felt like I'd unlocked a superpower.

Hot Reloading: The Developer's Dream

As I got more comfortable with Docker, I realized I missed one feature during development: hot reloading. Any React developer knows the joy of seeing your changes instantly reflected in the browser without refreshing.

Through more trial and error, I found a solution using Docker volumes. By mounting my source code directory as a volume, any change I made locally would be immediately available inside the container:

version: "3"
 
services:
  react-app:
    build:
      context: .
      dockerfile: Dockerfile.dev
    ports:
      - "3000:3000"
    volumes:
      - ./src:/app/src
      - ./public:/app/public
    environment:
      - CHOKIDAR_USEPOLLING=true

That CHOKIDAR_USEPOLLING=true was another little gem I discovered after noticing hot reloading was inconsistent on some operating systems.

The Environment Variables Nightmare

Environment variables in React have always been tricky, but Docker added another layer of complexity. I spent a full day trying to figure out why my API calls were failing, only to realize my environment variables weren't being properly passed to the container.

The solution was twofold:

1. Remember that Create React App requires variables to be prefixed with REACT_APP_
2. Use build args for build-time variables

FROM node:18-alpine as build
 
WORKDIR /app
 
COPY package.json package-lock.json ./
RUN npm ci
 
COPY . .
 
# Build-time environment variables
ARG REACT_APP_API_URL
ENV REACT_APP_API_URL=${REACT_APP_API_URL}
 
RUN npm run build
 
FROM nginx:alpine
COPY --from=build /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

This way, I could pass different environment variables during the build process:

docker build --build-arg REACT_APP_API_URL=https://api.production.com -t my-react-app:prod .

Docker Compose: The Team Game-Changer

The real magic happened when our team started using Docker Compose for our full-stack applications. Before this, setting up a local development environment with a React frontend, Node.js API, and MongoDB database was a multi-page tutorial that new team members dreaded.

With Docker Compose, we consolidated it all into a single YAML file:

version: "3"
 
services:
  react-app:
    build:
      context: ./frontend
      dockerfile: Dockerfile.dev
    ports:
      - "3000:3000"
    volumes:
      - ./frontend/src:/app/src
      - ./frontend/public:/app/public
    environment:
      - REACT_APP_API_URL=http://localhost:4000/api
    depends_on:
      - api
 
  api:
    build:
      context: ./backend
    ports:
      - "4000:4000"
    environment:
      - MONGODB_URI=mongodb://mongo:27017/myapp
      - NODE_ENV=development
    depends_on:
      - mongo
 
  mongo:
    image: mongo:4.4
    ports:
      - "27017:27017"
    volumes:
      - mongo-data:/data/db
 
volumes:
  mongo-data:

The onboarding process went from "follow these 20 steps and pray" to "run docker-compose up and grab a coffee." New developers could start contributing on day one instead of spending days setting up their environment.

Lessons Learned the Hard Way

After using Docker with React for several years, here are the biggest lessons I've learned:

1. Keep your images small: Use Alpine-based images and multi-stage builds. My production images went from 1.2GB to under 100MB.

2. Use a .dockerignore file: My builds got dramatically faster once I added node_modules, .git, and other unnecessary files to my .dockerignore:

node_modules
.git
.github
build
.dockerignore
.env*
.gitignore
README.md

3. Cache dependencies smartly: Order your Dockerfile commands from least to most frequently changing to utilize Docker's layer caching. This cut my build times in half.

4. Security matters: Don't run containers as root, use specific versions for base images, and scan your images for vulnerabilities.

5. CI/CD is your friend: Automate your Docker builds and tests. I set up GitHub Actions to build and push my Docker images:

name: Build and Deploy
 
on:
  push:
    branches: [main]
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
 
      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: myapp/react-frontend:latest

Where I Am Today

Today, Docker is an essential part of my React development workflow. I can't imagine going back to the days of "it works on my machine" excuses or lengthy environment setup docs.

My current setup includes:

• A development Dockerfile with hot reloading
• A production-optimized Dockerfile with multi-stage builds
• Docker Compose for local development with backend services
• Automated testing in containers
• CI/CD pipelines for building and deploying containerized apps

The journey wasn't always smooth, but the destination was worth it. If you're a React developer still hesitant about Docker, I hope my story encourages you to give it a try. You might lose a weekend to the learning curve, but you'll gain countless hours in productivity and peace of mind.

Remember: containers aren't just for backend developers. They're for anyone who values consistency, reproducibility, and sanity in their development workflow.

Happy Dockerizing!