express-microservices-architecture

What this skill does

# Express.js Microservices Architecture

A comprehensive skill for building production-ready microservices with Express.js. Master middleware patterns, routing strategies, error handling, scalability techniques, and deployment architectures for Node.js microservices at scale.

## When to Use This Skill

Use this skill when:

- Building RESTful APIs and microservices with Node.js
- Designing scalable distributed systems with Express.js
- Implementing middleware-based architecture patterns
- Creating API gateways and service mesh architectures
- Developing production-ready Node.js applications
- Migrating monoliths to microservices architecture
- Building event-driven microservices
- Implementing authentication, authorization, and security layers
- Optimizing Express.js applications for high performance
- Setting up monitoring, logging, and observability
- Deploying Express.js apps with Docker and Kubernetes
- Implementing circuit breakers and resilience patterns

## Core Concepts

### Express.js Fundamentals

Express.js is a minimal and flexible Node.js web application framework that provides robust features for web and mobile applications. It's the de facto standard for building Node.js APIs and microservices.

**Key Characteristics:**
- **Minimal**: Unopinionated framework with essential web app features
- **Middleware-based**: Request/response pipeline architecture
- **Routing**: Powerful routing mechanism with parameter support
- **Template Engines**: Support for various view engines
- **Performance**: Built on top of Node.js for high performance
- **Extensible**: Rich ecosystem of middleware and plugins

### Middleware Architecture

Middleware functions are the backbone of Express.js applications. They have access to the request object (`req`), response object (`res`), and the next middleware function (`next`).

**Middleware Flow:**
```
Request → Middleware 1 → Middleware 2 → ... → Route Handler → Response
                ↓              ↓                      ↓
           Error Handler  Error Handler         Error Handler
```

**Middleware Types:**
1. **Application-level middleware**: Bound to `app` instance
2. **Router-level middleware**: Bound to `express.Router()` instance
3. **Error-handling middleware**: Has 4 parameters (err, req, res, next)
4. **Built-in middleware**: Express built-in functions (static, json, urlencoded)
5. **Third-party middleware**: External packages (cors, helmet, morgan)

### Routing Strategies

Express routing enables you to map HTTP methods and URLs to handler functions.

**Routing Components:**
- **Route paths**: String patterns, regex, or path parameters
- **Route parameters**: Named URL segments (:userId)
- **Route handlers**: Single or multiple callback functions
- **Response methods**: res.send(), res.json(), res.status(), etc.
- **Router instances**: Modular, mountable route handlers

### Error Handling

Error handling in Express requires special middleware with 4 parameters: `(err, req, res, next)`.

**Error Handling Flow:**
1. Synchronous errors are caught automatically
2. Asynchronous errors must be passed to `next(err)`
3. Error middleware processes errors centrally
4. Proper status codes and error formats returned

### Microservices Principles

**Characteristics of Microservices:**
- **Single Responsibility**: Each service does one thing well
- **Independence**: Services can be deployed independently
- **Decentralized**: Each service owns its data
- **Resilience**: Failure in one service doesn't crash entire system
- **Scalability**: Scale services independently based on demand
- **Technology Diversity**: Different services can use different tech stacks

## Microservices Patterns

### Pattern 1: API Gateway Pattern

The API Gateway acts as a single entry point for all client requests, routing them to appropriate microservices.

**Benefits:**
- Single entry point for clients
- Request routing and composition
- Authentication and authorization
- Rate limiting and throttling
- Request/response transformation
- Protocol translation

**Implementation Structure:**
```
Client → API Gateway → Microservice 1 (Users)
                    → Microservice 2 (Orders)
                    → Microservice 3 (Products)
                    → Microservice 4 (Notifications)
```

### Pattern 2: Service Discovery

Services register themselves and discover other services dynamically.

**Approaches:**
- **Client-side discovery**: Client queries service registry
- **Server-side discovery**: Load balancer queries registry
- **DNS-based discovery**: Using DNS for service location

**Popular Tools:**
- Consul
- Eureka
- etcd
- Kubernetes built-in discovery

### Pattern 3: Circuit Breaker

Prevents cascading failures by stopping requests to failing services.

**States:**
- **Closed**: Normal operation, requests pass through
- **Open**: Service failing, requests fail immediately
- **Half-Open**: Testing if service recovered

### Pattern 4: Event-Driven Architecture

Services communicate through events instead of direct calls.

**Components:**
- **Event producers**: Services that emit events
- **Event consumers**: Services that listen to events
- **Message broker**: RabbitMQ, Kafka, Redis
- **Event store**: Persist events for replay

### Pattern 5: Database per Service

Each microservice owns its database, ensuring loose coupling.

**Benefits:**
- Service independence
- Technology diversity
- Easier scaling
- Clear boundaries

**Challenges:**
- Distributed transactions
- Data consistency
- Joins across services

### Pattern 6: Saga Pattern

Manages distributed transactions across multiple services.

**Types:**
- **Choreography**: Services coordinate through events
- **Orchestration**: Central coordinator manages transaction

### Pattern 7: CQRS (Command Query Responsibility Segregation)

Separate read and write operations into different models.

**Benefits:**
- Optimized read/write models
- Scalability
- Performance
- Flexibility

## Middleware Architecture Patterns

### Custom Middleware Development

Middleware functions execute in the order they're defined.

**Basic Middleware Structure:**
```javascript
const express = require('express');
const app = express();

// Basic middleware
const requestLogger = (req, res, next) => {
  console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);
  next(); // Pass control to next middleware
};

app.use(requestLogger);
```

**From Context7 - Saving Data in Request Object:**
```javascript
const express = require('express');
const app = express();
const port = 3000;

// Middleware to add user data to the request object
const addUserInfo = (req, res, next) => {
  req.user = {
    id: 123,
    username: 'testuser'
  };
  next();
};

// Middleware to add request timestamp
const addTimestamp = (req, res, next) => {
  req.requestTime = Date.now();
  next();
};

// Apply middleware globally
app.use(addUserInfo);
app.use(addTimestamp);

app.get('/', (req, res) => {
  const userId = req.user.id;
  const username = req.user.username;
  const timestamp = req.requestTime;

  res.send(`User ID: ${userId}, Username: ${username}, Request Time: ${new Date(timestamp).toISOString()}`);
});

app.listen(port, () => {
  console.log(`Request data sharing example listening at http://localhost:${port}`);
});
```

### Error-Handling Middleware

Error middleware has 4 parameters and should be defined after all other middleware.

**From Context7 - Error Handling Middleware:**
```javascript
const express = require('express');
const app = express();
const port = 3000;

// A regular middleware
app.use((req, res, next) => {
  console.log('Request received');
  next(); // Pass control to the next middleware
});

// A route that might throw an error
app.get('/throw-error', (req, res, next) => {
  // Simulate an error
  const error = new Error('This is a simulated error');
  error.status = 400;
  next(error);
});

// Error-handling middleware (must have 4 arguments)
app.use((err, req, res, next) => {
  console.error('Er