Building Scalable Full-Stack Applications with React and Node.js

Building a full-stack app that works is one thing. Building one that scales to millions of users is another. Here's what I've learned after building multiple production systems.

Foundation: Monolith vs Microservices

Most startups should start with a monolith:

When to split?

The monolith-first approach let me ship fast at PDF Toolkit and DocMind. We could always refactor later.

Frontend Architecture: React Best Practices

Component Structure

Think in terms of containers (smart) and presentational (dumb) components:

// Container - handles logic
function ProjectCard({ projectId }) {
  const [project, setProject] = useState(null);
  useEffect(() => {
    fetch(`/api/projects/${projectId}`)
      .then(r => r.json())
      .then(setProject);
  }, [projectId]);
  return <ProjectCardView project={project} />;
}

// Presentational - renders only
function ProjectCardView({ project }) {
  return (
    <div>
      <h3>{project.title}</h3>
      <p>{project.description}</p>
    </div>
  );
}

// Container - handles logic

function ProjectCard({ projectId }) {

const [project, setProject] = useState(null);

useEffect(() => {

fetch(`/api/projects/${projectId}`)

.then(r => r.json())

.then(setProject);

}, [projectId]);

return ;

}

// Presentational - renders only

function ProjectCardView({ project }) {

return (

);

}

This separation makes testing easier and components reusable.

### State Management

Use Zustand or Jotai for small-to-medium apps, Redux for complex ones. Keep state as local as possible.

This separation makes testing easier and components reusable.

State Management

Use Zustand or Jotai for small-to-medium apps, Redux for complex ones. Keep state as local as possible.

import { create } from 'zustand';

const useProjectStore = create((set) => ({
  projects: [],
  addProject: (project) => set((state) => ({
    projects: [...state.projects, project]
  }))
}));

import { create } from 'zustand';

const useProjectStore = create((set) => ({

projects: [],

addProject: (project) => set((state) => ({

projects: [...state.projects, project]

}))

}));

### Data Fetching

Use React Query (TanStack Query) for caching and synchronization:

Data Fetching

Use React Query (TanStack Query) for caching and synchronization:

const { data, isLoading } = useQuery({
  queryKey: ['projects'],
  queryFn: () => fetch('/api/projects').then(r => r.json())
});

const { data, isLoading } = useQuery({

queryKey: ['projects'],

queryFn: () => fetch('/api/projects').then(r => r.json())

});

It handles caching, refetching, polling—all the hard parts.

## Backend Architecture: Node.js + Express

### Route Organization

Group by domain:

It handles caching, refetching, polling—all the hard parts.

Backend Architecture: Node.js + Express

Route Organization

Group by domain:

/routes
  /projects.ts
  /auth.ts
  /users.ts

/routes

/projects.ts

/auth.ts

/users.ts

Each route file exports a router:

Each route file exports a router:

export const projectRouter = express.Router();
projectRouter.get('/', getProjects);
projectRouter.post('/', createProject);
projectRouter.delete('/:id', deleteProject);

export const projectRouter = express.Router();

projectRouter.get('/', getProjects);

projectRouter.post('/', createProject);

projectRouter.delete('/:id', deleteProject);

### Middleware

Use middleware for cross-cutting concerns:

Middleware

Use middleware for cross-cutting concerns:

app.use(authMiddleware); // verify JWT
app.use(requestLogger); // log requests
app.use(errorHandler); // catch errors

app.use(authMiddleware); // verify JWT

app.use(requestLogger); // log requests

app.use(errorHandler); // catch errors

### Database Layer

Abstract database operations behind a repository layer:

Database Layer

Abstract database operations behind a repository layer:

class ProjectRepository {
  async findById(id) { /* query */ }
  async findAll() { /* query */ }
  async create(data) { /* insert */ }
  async update(id, data) { /* update */ }
  async delete(id) { /* delete */ }
}

class ProjectRepository {

async findById(id) { / query / }

async findAll() { / query / }

async create(data) { / insert / }

async update(id, data) { / update / }

async delete(id) { / delete / }

}

This decouples your routes from database specifics. Swap PostgreSQL for MongoDB—routes don't care.

## Database Design for Scale

### Normalization vs Denormalization

Normalize for writes, denormalize for reads:

- Critical data (users, transactions): normalized
- Analytics data: denormalized
- Slowly changing data: can be denormalized

### Indexing Strategy

Index what you query:

This decouples your routes from database specifics. Swap PostgreSQL for MongoDB—routes don't care.

Database Design for Scale

Normalization vs Denormalization

Normalize for writes, denormalize for reads:

Indexing Strategy

Index what you query:

CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_projects_user_id ON projects(user_id);
CREATE INDEX idx_created_at ON posts(created_at DESC);

CREATE INDEX idx_users_email ON users(email);

CREATE INDEX idx_projects_user_id ON projects(user_id);

CREATE INDEX idx_created_at ON posts(created_at DESC);

Missing indexes are a common scale killer.

### Connection Pooling

Use connection pooling (not raw connections):

Missing indexes are a common scale killer.

Connection Pooling

Use connection pooling (not raw connections):

const pool = new Pool({
  max: 20, // max connections
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000,
});

const pool = new Pool({

max: 20, // max connections

idleTimeoutMillis: 30000,

connectionTimeoutMillis: 2000,

});

## Deployment & Infrastructure

### Docker & Containers

Containerize early:

Deployment & Infrastructure

Docker & Containers

Containerize early:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

FROM node:18-alpine

WORKDIR /app

COPY package*.json ./

RUN npm ci --only=production

COPY . .

EXPOSE 3000

CMD ["node", "server.js"]

### Environment Variables

Never hardcode secrets:

Environment Variables

Never hardcode secrets:

DATABASE_URL=postgresql://user:pass@localhost/db
JWT_SECRET=your-secret-key
NODE_ENV=production

DATABASE_URL=postgresql://user:pass@localhost/db

JWT_SECRET=your-secret-key

NODE_ENV=production

### Monitoring & Logging

Use structured logging:

Monitoring & Logging

Use structured logging:

const logger = pino({
  level: process.env.LOG_LEVEL || 'info'
});

logger.info({ userId, action: 'login' });
logger.error({ error: err.message });

const logger = pino({

level: process.env.LOG_LEVEL || 'info'

});

logger.info({ userId, action: 'login' });

logger.error({ error: err.message });

Set up alerts for:
- Error rates > 5%
- Response time p95 > 500ms
- Database connection pool exhaustion

## Performance Optimization

### Frontend

- Code-split with Next.js
- Lazy load images
- Use CDNs for static assets
- Minify and compress everything

### Backend

- Cache at every layer (Redis, database query caching)
- Use pagination for large datasets
- Compress API responses (gzip)
- Batch database queries when possible

### Database

- Use read replicas for scaling reads
- Shard if needed (but do it late)
- Archive old data
- Maintain statistics for query optimizer

## Conclusion

Scalable full-stack apps aren't built; they're evolved. Start simple, measure bottlenecks, optimize strategically. The teams that win are those who understand their specific bottleneck and fix it—not those who over-engineer everything upfront.
    

Set up alerts for:

Performance Optimization

Frontend

Backend

Database

Conclusion

Scalable full-stack apps aren't built; they're evolved. Start simple, measure bottlenecks, optimize strategically. The teams that win are those who understand their specific bottleneck and fix it—not those who over-engineer everything upfront.