Senior Fullstack

Senior Fullstack

Fullstack development skill with project scaffolding and code quality analysis tools.

---

Table of Contents

• Trigger Phrases
• Tools
• Workflows
• Reference Guides

---

Trigger Phrases

Use this skill when you hear:

• "scaffold a new project"
• "create a Next.js app"
• "set up FastAPI with React"
• "analyze code quality"
• "check for security issues in codebase"
• "what stack should I use"
• "set up a fullstack project"
• "generate project boilerplate"

---

Tools

Decision Engine

Deterministic profile picker. Given four assumptions (team-size, cadence, user-facing, budget) plus optional traffic/sensitivity inputs, ranks the four built-in profiles and returns the matched profile with SLO floor and named approver chain. Refuses to recommend a profile without the four required inputs.

Usage:

# See all options
python scripts/fullstack_decision_engine.py --help

# Run against a sample input
python scripts/fullstack_decision_engine.py --sample

# Pick a profile from real inputs
python scripts/fullstack_decision_engine.py \
    --team-size-12mo 8 --cadence daily --user-facing true --budget 5000 \
    --traffic-p99-rps 50 --data-sensitivity pii-only

# JSON output for downstream tools
python scripts/fullstack_decision_engine.py --sample --output json

Returns: matched profile name, score, matched/violated constraints, stack recommendation, anti-recommendations, SLO floor, named-approver chain, and canon references.

The engine encodes the same matrix the conversational grill walks through — use it directly when inputs are already known, or via the cs-fullstack-engineer agent for the question-by-question grill.

---

Project Scaffolder

Generates fullstack project structures with boilerplate code.

Supported Templates:

• nextjs - Next.js 14+ with App Router, TypeScript, Tailwind CSS
• fastapi-react - FastAPI backend + React frontend + PostgreSQL
• mern - MongoDB, Express, React, Node.js with TypeScript
• django-react - Django REST Framework + React frontend

Usage:

# List available templates
python scripts/project_scaffolder.py --list-templates

# Create Next.js project
python scripts/project_scaffolder.py nextjs my-app

# Create FastAPI + React project
python scripts/project_scaffolder.py fastapi-react my-api

# Create MERN stack project
python scripts/project_scaffolder.py mern my-project

# Create Django + React project
python scripts/project_scaffolder.py django-react my-app

# Specify output directory
python scripts/project_scaffolder.py nextjs my-app --output ./projects

# JSON output
python scripts/project_scaffolder.py nextjs my-app --json

Parameters:

Output includes:

• Project structure with all necessary files
• Package configurations (package.json, requirements.txt)
• TypeScript configuration
• Docker and docker-compose setup
• Environment file templates
• Next steps for running the project

---

Code Quality Analyzer

Analyzes fullstack codebases for quality issues.

Analysis Categories:

• Security vulnerabilities (hardcoded secrets, injection risks)
• Code complexity metrics (cyclomatic complexity, nesting depth)
• Dependency health (outdated packages, known CVEs)
• Test coverage estimation
• Documentation quality

Usage:

# Analyze current directory
python scripts/code_quality_analyzer.py .

# Analyze specific project
python scripts/code_quality_analyzer.py /path/to/project

# Verbose output with detailed findings
python scripts/code_quality_analyzer.py . --verbose

# JSON output
python scripts/code_quality_analyzer.py . --json

# Save report to file
python scripts/code_quality_analyzer.py . --output report.json

Parameters:

Output includes:

• Overall score (0-100) with letter grade
• Security issues by severity (critical, high, medium, low)
• High complexity files
• Vulnerable dependencies with CVE references
• Test coverage estimate
• Documentation completeness
• Prioritized recommendations

Sample Output:

============================================================
CODE QUALITY ANALYSIS REPORT
============================================================

Overall Score: 75/100 (Grade: C)
Files Analyzed: 45
Total Lines: 12,500

--- SECURITY ---
  Critical: 1
  High: 2
  Medium: 5

--- COMPLEXITY ---
  Average Complexity: 8.5
  High Complexity Files: 3

--- RECOMMENDATIONS ---
1. [P0] SECURITY
   Issue: Potential hardcoded secret detected
   Action: Remove or secure sensitive data at line 42

---

Workflows

Workflow 1: Start New Project

1. Choose appropriate stack based on requirements (see Stack Decision Matrix) 2. Scaffold project structure 3. Verify scaffold: confirm package.json (or requirements.txt) exists 4. Run initial quality check — address any P0 issues before proceeding 5. Set up development environment

# 1. Scaffold project
python scripts/project_scaffolder.py nextjs my-saas-app

# 2. Verify scaffold succeeded
ls my-saas-app/package.json

# 3. Navigate and install
cd my-saas-app
npm install

# 4. Configure environment
cp .env.example .env.local

# 5. Run quality check
python scripts/code_quality_analyzer.py .

# 6. Start development
npm run dev

Workflow 2: Audit Existing Codebase

1. Run code quality analysis 2. Review security findings — fix all P0 (critical) issues immediately 3. Re-run analyzer to confirm P0 issues are resolved 4. Create tickets for P1/P2 issues

# 1. Full analysis
python scripts/code_quality_analyzer.py /path/to/project --verbose

# 2. Generate detailed report
python scripts/code_quality_analyzer.py /path/to/project --json --output audit.json

# 3. After fixing P0 issues, re-run to verify
python scripts/code_quality_analyzer.py /path/to/project --verbose

Workflow 3: Stack Selection

Use the tech stack guide to evaluate options:

1. SEO Required? → Next.js with SSR 2. API-heavy backend? → Separate FastAPI or NestJS 3. Real-time features? → Add WebSocket layer 4. Team expertise → Match stack to team skills

See references/tech_stack_guide.md for detailed comparison.

---

Reference Guides

Architecture Patterns (references/architecture_patterns.md)

• Frontend component architecture (Atomic Design, Container/Presentational)
• Backend patterns (Clean Architecture, Repository Pattern)
• API design (REST conventions, GraphQL schema design)
• Database patterns (connection pooling, transactions, read replicas)
• Caching strategies (cache-aside, HTTP cache headers)
• Authentication architecture (JWT + refresh tokens, sessions)

Development Workflows (references/development_workflows.md)

• Local development setup (Docker Compose, environment config)
• Git workflows (trunk-based, conventional commits)
• CI/CD pipelines (GitHub Actions examples)
• Testing strategies (unit, integration, E2E)
• Code review process (PR templates, checklists)
• Deployment strategies (blue-green, canary, feature flags)
• Monitoring and observability (logging, metrics, health checks)

Tech Stack Guide (references/tech_stack_guide.md)

• Frontend frameworks comparison (Next.js, React+Vite, Vue)
• Backend frameworks (Express, Fastify, NestJS, FastAPI, Django)
• Database selection (PostgreSQL, MongoDB, Redis)
• ORMs (Prisma, Drizzle, SQLAlchemy)
• Authentication solutions (Auth.js, Clerk, custom JWT)
• Deployment platforms (Vercel, Railway, AWS)
• Stack recommendations by use case (MVP, SaaS, Enterprise)

---

Quick Reference

Stack Decision Matrix

Common Issues

---

Assumptions and Verifiable Success Criteria (Karpathy discipline)

Before this skill scaffolds, recommends, or modifies any code, the following four assumptions MUST be surfaced. If any are unknown, the skill stops and walks the Forcing-question library instead.

1. Team size today + 12-month headcount — drives architecture (monolith / modular / services). Sam Newman: "MonolithFirst." 2. Deployment cadence target — drives CI/CD spend and feature-flag investment. Accelerate (Forsgren et al. 2018). 3. User-facing vs. internal vs. marketing-site — drives stack pick and a11y/perf budget. 4. Monthly cloud + SaaS budget ceiling — drives the build-vs-managed-service split.

Verifiable success criteria (Karpathy #4) — every recommendation this skill emits must include three machine-checkable numbers:

• An API latency target (p50, p95, p99 in ms)
• A frontend perf target (LCP, INP, CLS on mobile-4G)
• An uptime / SLO target

If any of those three is not stated, the recommendation is incomplete — go back to Q7 of the forcing-question library.

The scripts/fullstack_decision_engine.py tool encodes these checks: it refuses to recommend a profile without all four assumption inputs and prints the verifiable thresholds for the matched profile.

---

Customization profiles

Four built-in profiles in profiles/ calibrate every recommendation:

Pick a profile via:

python scripts/fullstack_decision_engine.py \
  --team-size 6 --team-size-12mo 12 \
  --cadence daily --user-facing true --budget 5000 \
  --traffic-p99-rps 45 --data-sensitivity pii-only

The tool returns the best-fit profile, the tradeoff against the runner-up (if within 15%), the stack recommendation, the anti-patterns to avoid on that profile, and the named-approver chain. This tool never auto-approves.

To add a custom profile: copy profiles/saas-startup.json to profiles/<your-org>.json, adjust the constraints and stack_recommendations blocks, and rerun. The JSON is the customization surface — no code changes needed.

---

Composition map

This skill does NOT reimplement scope owned by the POWERFUL-tier specialists. It forks into them. See references/composition_map.md for the full routing table. Key forks:

The cs-fullstack-engineer agent (in agents/engineering/cs-fullstack-engineer.md) orchestrates these forks via context: fork. Invoke it from another agent with Agent({subagent_type: "cs-fullstack-engineer", prompt: "..."}) or via the slash command /cs:fullstack-review <your problem>.

---

Forcing-question library (Matt Pocock grill)

Before locking any architecture or stack decision, walk the seven forcing questions in references/forcing_questions.md. Each has a recommended answer, canon citation, and kill criterion. The discipline:

1. One question per turn. No bundling. 2. Always recommend the answer with cited canon. 3. Track answers in a working file (e.g., /tmp/fullstack-grill-<date>.md). 4. If a kill criterion trips, stop. Do not scaffold around an unresolved gap. 5. After Q7, run fullstack_decision_engine.py with the seven answers as inputs.

Summary of the seven questions (full content in the reference):

1. Team size today + 12-month headcount? 2. Deployment cadence — per-PR, daily, weekly, quarterly? 3. Customer-facing, internal tool, or marketing site? 4. One-year p50 / p99 traffic forecast? 5. Hiring against the stack or training the team? 6. Year-one monthly cloud + SaaS ceiling? 7. Three verifiable success criteria with numeric targets?

---

Invocation from other agents and skills

This skill is invokable by any other agent or skill via three surfaces:

1. Slash command: /cs:fullstack-review <prompt> — runs the full grill + decision engine + composition routing. 2. Agent subagent: Agent({subagent_type: "cs-fullstack-engineer", prompt: "..."}) — forks context, returns ≤ 200-word digest. 3. Direct tool call: python scripts/fullstack_decision_engine.py ... — deterministic profile match without the conversational grill (use when inputs are already known).

See agents/engineering/cs-fullstack-engineer.md for the full invocation contract.

Fullstack Architecture Patterns

Proven architectural patterns for scalable fullstack applications covering frontend, backend, and their integration.

---

Table of Contents

• Frontend Architecture
• Backend Architecture
• API Design Patterns
• Database Patterns
• Caching Strategies
• Authentication Architecture

---

Frontend Architecture

Component Architecture

Atomic Design Pattern

Organize components in hierarchical levels:

src/components/
├── atoms/           # Button, Input, Icon
├── molecules/       # SearchInput, FormField
├── organisms/       # Header, Footer, Sidebar
├── templates/       # PageLayout, DashboardLayout
└── pages/           # Home, Profile, Settings

When to use: Large applications with design systems and multiple teams.

Container/Presentational Pattern

// Presentational - pure rendering, no state
function UserCard({ name, email, avatar }: UserCardProps) {
  return (
    <div className="card">
      <img src={avatar} alt={name} />
      <h3>{name}</h3>
      <p>{email}</p>
    </div>
  );
}

// Container - handles data fetching and state
function UserCardContainer({ userId }: { userId: string }) {
  const { data, loading } = useUser(userId);
  if (loading) return <Skeleton />;
  return <UserCard {...data} />;
}

When to use: When you need clear separation between UI and logic.

State Management Patterns

Server State vs Client State

React Query for Server State:

function useUsers(filters: Filters) {
  return useQuery({
    queryKey: ["users", filters],
    queryFn: () => api.getUsers(filters),
    staleTime: 5 * 60 * 1000, // 5 minutes
    gcTime: 30 * 60 * 1000,   // 30 minutes
  });
}

// Mutations with optimistic updates
function useUpdateUser() {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: api.updateUser,
    onMutate: async (newUser) => {
      await queryClient.cancelQueries({ queryKey: ["users"] });
      const previous = queryClient.getQueryData(["users"]);
      queryClient.setQueryData(["users"], (old) =>
        old.map(u => u.id === newUser.id ? newUser : u)
      );
      return { previous };
    },
    onError: (err, newUser, context) => {
      queryClient.setQueryData(["users"], context.previous);
    },
    onSettled: () => {
      queryClient.invalidateQueries({ queryKey: ["users"] });
    },
  });
}

---

Backend Architecture

Clean Architecture

src/
├── domain/              # Business entities, no dependencies
│   ├── entities/        # User, Order, Product
│   └── interfaces/      # Repository interfaces
├── application/         # Use cases, application logic
│   ├── use-cases/       # CreateOrder, UpdateUser
│   └── services/        # OrderService, AuthService
├── infrastructure/      # External concerns
│   ├── database/        # Repository implementations
│   ├── http/            # Controllers, middleware
│   └── external/        # Third-party integrations
└── shared/              # Cross-cutting concerns
    ├── errors/
    └── utils/

Dependency Flow: domain ← application ← infrastructure

Repository Pattern:

// Domain interface
interface UserRepository {
  findById(id: string): Promise<User | null>;
  findByEmail(email: string): Promise<User | null>;
  save(user: User): Promise<User>;
  delete(id: string): Promise<void>;
}

// Infrastructure implementation
class PostgresUserRepository implements UserRepository {
  constructor(private db: Database) {}

  async findById(id: string): Promise<User | null> {
    const row = await this.db.query(
      "SELECT * FROM users WHERE id = $1",
      [id]
    );
    return row ? this.toEntity(row) : null;
  }

  private toEntity(row: UserRow): User {
    return new User({
      id: row.id,
      email: row.email,
      name: row.name,
      createdAt: row.created_at,
    });
  }
}

Middleware Pipeline

// Express middleware chain
app.use(cors());
app.use(helmet());
app.use(requestId());
app.use(logger());
app.use(authenticate());
app.use(rateLimit());
app.use("/api", routes);
app.use(errorHandler());

// Custom middleware example
function requestId() {
  return (req: Request, res: Response, next: NextFunction) => {
    req.id = req.headers["x-request-id"] || crypto.randomUUID();
    res.setHeader("x-request-id", req.id);
    next();
  };
}

function errorHandler() {
  return (err: Error, req: Request, res: Response, next: NextFunction) => {
    const status = err instanceof AppError ? err.status : 500;
    const message = status === 500 ? "Internal Server Error" : err.message;

    logger.error({ err, requestId: req.id });
    res.status(status).json({ error: message, requestId: req.id });
  };
}

---

API Design Patterns

REST Best Practices

Resource Naming:

• Use nouns, not verbs: /users not /getUsers
• Use plural: /users not /user
• Nest for relationships: /users/{id}/orders

HTTP Methods:

Response Envelope:

// Success response
{
  "data": { /* resource */ },
  "meta": {
    "requestId": "abc-123",
    "timestamp": "2024-01-15T10:30:00Z"
  }
}

// Paginated response
{
  "data": [/* items */],
  "pagination": {
    "page": 1,
    "pageSize": 20,
    "total": 150,
    "totalPages": 8
  }
}

// Error response
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Invalid input",
    "details": [
      { "field": "email", "message": "Invalid email format" }
    ]
  },
  "meta": { "requestId": "abc-123" }
}

GraphQL Architecture

Schema-First Design:

type Query {
  user(id: ID!): User
  users(filter: UserFilter, page: PageInput): UserConnection!
}

type Mutation {
  createUser(input: CreateUserInput!): UserPayload!
  updateUser(id: ID!, input: UpdateUserInput!): UserPayload!
}

type User {
  id: ID!
  email: String!
  profile: Profile
  orders(first: Int, after: String): OrderConnection!
}

type UserPayload {
  user: User
  errors: [Error!]
}

Resolver Pattern:

const resolvers = {
  Query: {
    user: async (_, { id }, { dataSources }) => {
      return dataSources.userAPI.findById(id);
    },
  },
  User: {
    // Field resolver for related data
    orders: async (user, { first, after }, { dataSources }) => {
      return dataSources.orderAPI.findByUserId(user.id, { first, after });
    },
  },
};

DataLoader for N+1 Prevention:

const userLoader = new DataLoader(async (userIds: string[]) => {
  const users = await db.query(
    "SELECT * FROM users WHERE id = ANY($1)",
    [userIds]
  );
  // Return in same order as input
  return userIds.map(id => users.find(u => u.id === id));
});

---

Database Patterns

Connection Pooling

// PostgreSQL with connection pool
const pool = new Pool({
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  max: 20,                    // Maximum connections
  idleTimeoutMillis: 30000,   // Close idle connections
  connectionTimeoutMillis: 2000,
});

// Prisma with connection pool
const prisma = new PrismaClient({
  datasources: {
    db: {
      url: `${process.env.DATABASE_URL}?connection_limit=20&pool_timeout=10`,
    },
  },
});

Transaction Patterns

// Unit of Work pattern
async function transferFunds(from: string, to: string, amount: number) {
  return await prisma.$transaction(async (tx) => {
    const sender = await tx.account.update({
      where: { id: from },
      data: { balance: { decrement: amount } },
    });

    if (sender.balance < 0) {
      throw new InsufficientFundsError();
    }

    await tx.account.update({
      where: { id: to },
      data: { balance: { increment: amount } },
    });

    return tx.transaction.create({
      data: { fromId: from, toId: to, amount },
    });
  });
}

Read Replicas

// Route reads to replica
const readDB = new PrismaClient({
  datasources: { db: { url: process.env.READ_DATABASE_URL } },
});

const writeDB = new PrismaClient({
  datasources: { db: { url: process.env.WRITE_DATABASE_URL } },
});

class UserRepository {
  async findById(id: string) {
    return readDB.user.findUnique({ where: { id } });
  }

  async create(data: CreateUserData) {
    return writeDB.user.create({ data });
  }
}

---

Caching Strategies

Cache Layers

Request → CDN Cache → Application Cache → Database Cache → Database

Cache-Aside Pattern:

async function getUser(id: string): Promise<User> {
  const cacheKey = `user:${id}`;

  // 1. Try cache
  const cached = await redis.get(cacheKey);
  if (cached) {
    return JSON.parse(cached);
  }

  // 2. Fetch from database
  const user = await db.user.findUnique({ where: { id } });
  if (!user) throw new NotFoundError();

  // 3. Store in cache
  await redis.set(cacheKey, JSON.stringify(user), "EX", 3600);

  return user;
}

// Invalidate on update
async function updateUser(id: string, data: UpdateData): Promise<User> {
  const user = await db.user.update({ where: { id }, data });
  await redis.del(`user:${id}`);
  return user;
}

HTTP Cache Headers:

// Immutable assets (hashed filenames)
res.setHeader("Cache-Control", "public, max-age=31536000, immutable");

// API responses
res.setHeader("Cache-Control", "private, max-age=0, must-revalidate");
res.setHeader("ETag", generateETag(data));

// Static pages
res.setHeader("Cache-Control", "public, max-age=3600, stale-while-revalidate=86400");

---

Authentication Architecture

JWT + Refresh Token Flow

1. User logs in → Server returns access token (15min) + refresh token (7d)
2. Client stores tokens (httpOnly cookie for refresh, memory for access)
3. Access token expires → Client uses refresh token to get new pair
4. Refresh token expires → User must log in again

Implementation:

// Token generation
function generateTokens(user: User) {
  const accessToken = jwt.sign(
    { sub: user.id, email: user.email },
    process.env.JWT_SECRET,
    { expiresIn: "15m" }
  );

  const refreshToken = jwt.sign(
    { sub: user.id, tokenVersion: user.tokenVersion },
    process.env.REFRESH_SECRET,
    { expiresIn: "7d" }
  );

  return { accessToken, refreshToken };
}

// Refresh endpoint
app.post("/auth/refresh", async (req, res) => {
  const refreshToken = req.cookies.refreshToken;

  try {
    const payload = jwt.verify(refreshToken, process.env.REFRESH_SECRET);
    const user = await db.user.findUnique({ where: { id: payload.sub } });

    // Check token version (invalidation mechanism)
    if (user.tokenVersion !== payload.tokenVersion) {
      throw new Error("Token revoked");
    }

    const tokens = generateTokens(user);
    setRefreshCookie(res, tokens.refreshToken);
    res.json({ accessToken: tokens.accessToken });
  } catch {
    res.status(401).json({ error: "Invalid refresh token" });
  }
});

Session-Based Auth

// Redis session store
app.use(session({
  store: new RedisStore({ client: redisClient }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    secure: process.env.NODE_ENV === "production",
    httpOnly: true,
    sameSite: "lax",
    maxAge: 7 * 24 * 60 * 60 * 1000, // 7 days
  },
}));

// Login
app.post("/auth/login", async (req, res) => {
  const user = await authenticate(req.body.email, req.body.password);
  req.session.userId = user.id;
  res.json({ user });
});

// Middleware
function requireAuth(req, res, next) {
  if (!req.session.userId) {
    return res.status(401).json({ error: "Authentication required" });
  }
  next();
}

---

Decision Matrix

Fullstack Engineer — Composition Map

Principle (Karpathy #2, Simplicity First): do not reimplement scope that the POWERFUL-tier engineering specialists already own. This skill is the fullstack orchestrator; the specialists are the implementers. Fork into them — do not duplicate them.

This map is the routing table for the cs-fullstack-engineer agent and the /cs:fullstack-review command.

Composition routing table

Composition rules

1. Fork via `context: fork` — the agent forks its own context, runs the sub-skill, returns a ≤ 200-word digest. 2. One sub-skill at a time. Matt Pocock's depth-first rule. Finish the API contract branch before opening the database branch. 3. Honor sub-skill outputs as inputs. If database-designer recommends a schema, the next call to api-design-reviewer must use that schema, not invent one. 4. Never reimplement specialist scope. If the user asks "what's the right index strategy?" do not answer with handcrafted advice — fork into database-designer. 5. Document the chain. Every artifact this skill produces must list the sub-skills it invoked, in order, with the digest paths.

Anti-patterns

• ❌ Calling all sub-skills at the start "to be thorough." Burns context, produces noise.
• ❌ Skipping cs-karpathy-reviewer before committing. Every commit from this skill must pass the diff-noise gate.
• ❌ Implementing what api-design-reviewer would have caught (e.g., inconsistent REST verbs). Fork first; commit second.
• ❌ Treating this skill's recommendations as approvals. Architecture choices must be sign-off-able by a named engineer; this skill never auto-approves.

When to escalate out of fullstack

• Pure-engineering org-design questions (team topologies, manager triggers) → escalate to cs-vpe-advisor.
• Strategic build-vs-buy at the company level → escalate to cs-cto-advisor.
• AI/ML pipeline questions → escalate to senior-ml-engineer / senior-prompt-engineer.
• Data warehouse / lakehouse / dbt questions → escalate to senior-data-engineer.
• Pure security / threat model → escalate to cs-ciso-advisor (strategic) or senior-security (tactical).

References

• Karpathy 4 principles → ../../../engineering/karpathy-coder/skills/karpathy-coder/references/karpathy-principles.md
• Matt Pocock grill discipline → ../../../engineering/grill-me/skills/grill-me/references/forcing_question_patterns.md
• Path-B 11-file contract → ../../../business-operations/CLAUDE.md (canonical statement)

Fullstack Development Workflows

Complete development lifecycle workflows from local setup to production deployment.

---

Table of Contents

• Local Development Setup
• Git Workflows
• CI/CD Pipelines
• Testing Strategies
• Code Review Process
• Deployment Strategies
• Monitoring and Observability

---

Local Development Setup

Docker Compose Development Environment

# docker-compose.yml
version: "3.8"

services:
  app:
    build:
      context: .
      target: development
    volumes:
      - .:/app
      - /app/node_modules
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgresql://user:pass@db:5432/app
      - REDIS_URL=redis://redis:6379
    depends_on:
      - db
      - redis

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: app
    volumes:
      - postgres_data:/var/lib/postgresql/data
    ports:
      - "5432:5432"

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  postgres_data:

Multistage Dockerfile:

# Base stage
FROM node:20-alpine AS base
WORKDIR /app
RUN apk add --no-cache libc6-compat

# Development stage
FROM base AS development
COPY package*.json ./
RUN npm ci
COPY . .
CMD ["npm", "run", "dev"]

# Builder stage
FROM base AS builder
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM base AS production
ENV NODE_ENV=production
COPY --from=builder /app/package*.json ./
RUN npm ci --only=production
COPY --from=builder /app/dist ./dist
USER node
CMD ["node", "dist/index.js"]

Environment Configuration

# .env.local (development)
DATABASE_URL="postgresql://user:pass@localhost:5432/app_dev"
REDIS_URL="redis://localhost:6379"
JWT_SECRET="development-secret-change-in-prod"
LOG_LEVEL="debug"

# .env.test
DATABASE_URL="postgresql://user:pass@localhost:5432/app_test"
LOG_LEVEL="error"

# .env.production (via secrets management)
DATABASE_URL="${DATABASE_URL}"
REDIS_URL="${REDIS_URL}"
JWT_SECRET="${JWT_SECRET}"

Environment validation:

import { z } from "zod";

const envSchema = z.object({
  NODE_ENV: z.enum(["development", "test", "production"]),
  DATABASE_URL: z.string().url(),
  REDIS_URL: z.string().url().optional(),
  JWT_SECRET: z.string().min(32),
  PORT: z.coerce.number().default(3000),
});

export const env = envSchema.parse(process.env);

---

Git Workflows

Trunk-Based Development

main (protected)
  │
  ├── feature/user-auth (short-lived, 1-2 days max)
  │   └── squash merge → main
  │
  ├── feature/payment-flow
  │   └── squash merge → main
  │
  └── release/v1.2.0 (cut from main for hotfixes)

Branch naming:

• feature/description - New features
• fix/description - Bug fixes
• chore/description - Maintenance tasks
• release/vX.Y.Z - Release branches

Commit Standards

Conventional Commits:

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Types:

• feat: New feature
• fix: Bug fix
• docs: Documentation
• style: Formatting
• refactor: Code restructuring
• test: Adding tests
• chore: Maintenance

Examples:

feat(auth): add password reset flow

Implement password reset with email verification.
Tokens expire after 1 hour.

Closes #123

---

fix(api): handle null response in user endpoint

The API was returning 500 when user profile was incomplete.
Now returns partial data with null fields.

---

chore(deps): update Next.js to 14.1.0

Breaking changes addressed:
- Updated Image component usage
- Migrated to new metadata API

Pre-commit Hooks

// package.json
{
  "scripts": {
    "prepare": "husky install"
  },
  "lint-staged": {
    "*.{ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.{json,md}": ["prettier --write"]
  }
}

# .husky/pre-commit
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

# .husky/commit-msg
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx commitlint --edit $1

---

CI/CD Pipelines

GitHub Actions

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check

  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test
          POSTGRES_DB: test
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run test:unit
      - run: npm run test:integration
        env:
          DATABASE_URL: postgresql://test:test@localhost:5432/test
      - uses: codecov/codecov-action@v3

  build:
    runs-on: ubuntu-latest
    needs: [lint, test]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build
          path: dist/

  deploy-preview:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: build
          path: dist/
      # Deploy to preview environment
      - name: Deploy Preview
        run: |
          # Deploy logic here
          echo "Deployed to preview-${{ github.event.pull_request.number }}"

  deploy-production:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    needs: build
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: build
          path: dist/
      - name: Deploy Production
        run: |
          # Production deployment
          echo "Deployed to production"

Database Migrations in CI

# Part of deploy job
- name: Run Migrations
  run: |
    npx prisma migrate deploy
  env:
    DATABASE_URL: ${{ secrets.DATABASE_URL }}

- name: Verify Migration
  run: |
    npx prisma migrate status

---

Testing Strategies

Testing Pyramid

         /\
        /  \        E2E Tests (10%)
       /    \       - Critical user journeys
      /──────\
     /        \     Integration Tests (20%)
    /          \    - API endpoints
   /────────────\   - Database operations
  /              \
 /                \ Unit Tests (70%)
/──────────────────\ - Components, hooks, utilities

Unit Testing

// Component test with React Testing Library
import { render, screen, fireEvent } from "@testing-library/react";
import { UserForm } from "./UserForm";

describe("UserForm", () => {
  it("submits form with valid data", async () => {
    const onSubmit = vi.fn();
    render(<UserForm onSubmit={onSubmit} />);

    fireEvent.change(screen.getByLabelText(/email/i), {
      target: { value: "test@example.com" },
    });
    fireEvent.change(screen.getByLabelText(/name/i), {
      target: { value: "John Doe" },
    });
    fireEvent.click(screen.getByRole("button", { name: /submit/i }));

    await waitFor(() => {
      expect(onSubmit).toHaveBeenCalledWith({
        email: "test@example.com",
        name: "John Doe",
      });
    });
  });

  it("shows validation error for invalid email", async () => {
    render(<UserForm onSubmit={vi.fn()} />);

    fireEvent.change(screen.getByLabelText(/email/i), {
      target: { value: "invalid" },
    });
    fireEvent.click(screen.getByRole("button", { name: /submit/i }));

    expect(await screen.findByText(/invalid email/i)).toBeInTheDocument();
  });
});

Integration Testing

// API integration test
import { createTestClient } from "./test-utils";
import { db } from "@/lib/db";

describe("POST /api/users", () => {
  beforeEach(async () => {
    await db.user.deleteMany();
  });

  it("creates user with valid data", async () => {
    const client = createTestClient();

    const response = await client.post("/api/users", {
      email: "new@example.com",
      name: "New User",
    });

    expect(response.status).toBe(201);
    expect(response.data.user.email).toBe("new@example.com");

    // Verify in database
    const user = await db.user.findUnique({
      where: { email: "new@example.com" },
    });
    expect(user).toBeTruthy();
  });

  it("returns 409 for duplicate email", async () => {
    await db.user.create({
      data: { email: "existing@example.com", name: "Existing" },
    });

    const client = createTestClient();

    const response = await client.post("/api/users", {
      email: "existing@example.com",
      name: "Duplicate",
    });

    expect(response.status).toBe(409);
    expect(response.data.error.code).toBe("EMAIL_EXISTS");
  });
});

E2E Testing with Playwright

// e2e/auth.spec.ts
import { test, expect } from "@playwright/test";

test.describe("Authentication", () => {
  test("user can log in and access dashboard", async ({ page }) => {
    await page.goto("/login");

    await page.fill('[name="email"]', "user@example.com");
    await page.fill('[name="password"]', "password123");
    await page.click('button[type="submit"]');

    await expect(page).toHaveURL("/dashboard");
    await expect(page.locator("h1")).toHaveText("Welcome back");
  });

  test("shows error for invalid credentials", async ({ page }) => {
    await page.goto("/login");

    await page.fill('[name="email"]', "wrong@example.com");
    await page.fill('[name="password"]', "wrongpassword");
    await page.click('button[type="submit"]');

    await expect(page.locator('[role="alert"]')).toHaveText(
      "Invalid email or password"
    );
  });
});

---

Code Review Process

PR Template

## Summary
<!-- Brief description of changes -->

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Changes Made
<!-- List specific changes -->

## Testing
- [ ] Unit tests added/updated
- [ ] Integration tests added/updated
- [ ] Manual testing completed

## Screenshots
<!-- If applicable -->

## Checklist
- [ ] Code follows style guidelines
- [ ] Self-review completed
- [ ] Documentation updated
- [ ] No new warnings

Review Checklist

Functionality:

• Does the code do what it's supposed to?
• Are edge cases handled?
• Is error handling appropriate?

Code Quality:

• Is the code readable and maintainable?
• Are there any code smells?
• Is there unnecessary duplication?

Performance:

• Are there N+1 queries?
• Is caching used appropriately?
• Are there memory leaks?

Security:

• Is user input validated?
• Are there injection vulnerabilities?
• Is sensitive data protected?

---

Deployment Strategies

Blue-Green Deployment

                 Load Balancer
                      │
         ┌────────────┴────────────┐
         │                         │
    ┌────┴────┐              ┌─────┴────┐
    │  Blue   │              │  Green   │
    │ (Live)  │              │  (Idle)  │
    └─────────┘              └──────────┘

1. Deploy new version to Green
2. Run smoke tests on Green
3. Switch traffic to Green
4. Blue becomes idle (rollback target)

Canary Deployment

                 Load Balancer
                      │
         ┌────────────┴────────────┐
         │                         │
         │ 95%                5%   │
         ▼                         ▼
    ┌─────────┐              ┌──────────┐
    │ Stable  │              │  Canary  │
    │ v1.0.0  │              │  v1.1.0  │
    └─────────┘              └──────────┘

1. Deploy canary with small traffic %
2. Monitor error rates, latency
3. Gradually increase traffic
4. Full rollout or rollback

Feature Flags

// Feature flag service
const flags = {
  newCheckoutFlow: {
    enabled: true,
    rolloutPercentage: 25,
    allowedUsers: ["beta-testers"],
  },
};

function isFeatureEnabled(flag: string, userId: string): boolean {
  const config = flags[flag];
  if (!config?.enabled) return false;

  // Check allowed users
  if (config.allowedUsers?.includes(userId)) return true;

  // Check rollout percentage
  const hash = hashUserId(userId);
  return hash < config.rolloutPercentage;
}

// Usage
if (isFeatureEnabled("newCheckoutFlow", user.id)) {
  return <NewCheckout />;
}
return <LegacyCheckout />;

---

Monitoring and Observability

Structured Logging

import pino from "pino";

const logger = pino({
  level: process.env.LOG_LEVEL || "info",
  formatters: {
    level: (label) => ({ level: label }),
  },
});

// Request logging middleware
app.use((req, res, next) => {
  const start = Date.now();
  const requestId = req.headers["x-request-id"] || crypto.randomUUID();

  res.on("finish", () => {
    logger.info({
      type: "request",
      requestId,
      method: req.method,
      path: req.path,
      statusCode: res.statusCode,
      duration: Date.now() - start,
      userAgent: req.headers["user-agent"],
    });
  });

  next();
});

// Application logging
logger.info({ userId: user.id, action: "login" }, "User logged in");
logger.error({ err, orderId }, "Failed to process order");

Metrics Collection

import { Counter, Histogram } from "prom-client";

const httpRequestsTotal = new Counter({
  name: "http_requests_total",
  help: "Total HTTP requests",
  labelNames: ["method", "path", "status"],
});

const httpRequestDuration = new Histogram({
  name: "http_request_duration_seconds",
  help: "HTTP request duration",
  labelNames: ["method", "path"],
  buckets: [0.1, 0.3, 0.5, 1, 3, 5, 10],
});

// Middleware
app.use((req, res, next) => {
  const end = httpRequestDuration.startTimer({
    method: req.method,
    path: req.route?.path || req.path,
  });

  res.on("finish", () => {
    httpRequestsTotal.inc({
      method: req.method,
      path: req.route?.path || req.path,
      status: res.statusCode,
    });
    end();
  });

  next();
});

Health Checks

app.get("/health", async (req, res) => {
  const checks = {
    database: await checkDatabase(),
    redis: await checkRedis(),
    memory: checkMemory(),
  };

  const healthy = Object.values(checks).every((c) => c.status === "healthy");

  res.status(healthy ? 200 : 503).json({
    status: healthy ? "healthy" : "unhealthy",
    checks,
    timestamp: new Date().toISOString(),
  });
});

async function checkDatabase() {
  try {
    await db.$queryRaw`SELECT 1`;
    return { status: "healthy" };
  } catch (error) {
    return { status: "unhealthy", error: error.message };
  }
}

function checkMemory() {
  const used = process.memoryUsage();
  const heapUsedMB = Math.round(used.heapUsed / 1024 / 1024);
  const heapTotalMB = Math.round(used.heapTotal / 1024 / 1024);

  return {
    status: heapUsedMB < heapTotalMB * 0.9 ? "healthy" : "warning",
    heapUsedMB,
    heapTotalMB,
  };
}

---

Quick Reference

Daily Workflow

# 1. Start work
git checkout main && git pull
git checkout -b feature/my-feature

# 2. Develop with hot reload
docker-compose up -d
npm run dev

# 3. Test changes
npm run test
npm run lint

# 4. Commit
git add -A
git commit -m "feat(scope): description"

# 5. Push and create PR
git push -u origin feature/my-feature
gh pr create

Release Workflow

# 1. Ensure main is stable
git checkout main
npm run test:all

# 2. Create release
npm version minor  # or major/patch
git push --follow-tags

# 3. Verify deployment
# CI/CD deploys automatically
# Monitor dashboards

Fullstack Engineer — Forcing-Question Library

Discipline (Matt Pocock, derived from `engineering/grill-me`, MIT): walk these one at a time. Do not skip ahead. Do not bundle. Answers must be written down. If the user cannot answer one, that is your next investigation — stop and surface the gap.

These seven questions are the Matt Pocock grill that gates every meaningful fullstack decision (stack pick, scale step, build-vs-buy, monolith-vs-microservices). Each has a recommended answer with canon citation and a kill criterion — the condition under which the plan fails the question and the work should stop until the gap is closed.

---

Q1 — "What is your team size today, and what is the credible 12-month engineer headcount?"

Recommended answer: a single integer for today plus a single integer for month 12 (e.g., "4 engineers today, 9 in 12 months, hiring funded through Series A close"). Not a range. Not "growing."

Why it's the first question: every other architecture question collapses on this number. A team of 4 cannot operate a microservice fleet; a team of 80 cannot share a monorepo without tooling. Will Larson is explicit: org structure is the binding constraint on architecture, not the other way around.

Kill criterion: "we're starting microservices day one" with no 30+ engineer plan in 12 months — STOP. Re-plan as modular monolith. (Sam Newman's "MonolithFirst" rule, 2021.)

Canon: Will Larson, An Elegant Puzzle (2019); Sam Newman, Building Microservices 2e (2021); Melvin Conway, How Do Committees Invent? (1968).

---

Q2 — "What is your target deployment cadence — per-PR, daily, weekly, or quarterly?"

Recommended answer: a specific cadence with named bottleneck (e.g., "daily; bottleneck is QA sign-off, fix that first"). The cadence forces every downstream choice: CI/CD spend, environment count, feature-flag investment, observability budget.

Why it matters: the Accelerate program's research (Forsgren/Humble/Kim, 2018) shows elite-cadence teams (per-PR or daily) outperform low-cadence teams on every business metric. But a quarterly-cadence team buying microservice infrastructure has bought the cost without the benefit.

Kill criterion: quarterly cadence with a microservice fleet, or weekly cadence with no feature-flag strategy → STOP. Fix the bottleneck before the architecture investment.

Canon: Forsgren, Humble & Kim, Accelerate (2018); DORA State of DevOps Reports (2014–2024).

---

Q3 — "Customer-facing product, internal tool, or marketing site? Pick exactly one."

Recommended answer: one of the three, written down. "Sort of both" usually means the wrong stack is about to be chosen.

Why it matters: the cost shape is different for each. A marketing site on a Next.js + GraphQL + PostgreSQL stack is paying for capability it will never use. An internal tool built like a public product over-invests in a11y, perf, and theming the four-user audience does not need. A customer-facing product built like an internal tool ships a broken first impression.

Kill criterion: "marketing-site-but-also-the-product-someday" — STOP. Build the marketing site as static (Astro / Hugo / pure HTML). Build the product as a separate codebase. Joining them later is cheap; un-joining them is expensive.

Canon: Donald Reinertsen, Principles of Product Development Flow (2009), Principle E2 (queue length); Jeff Patton, User Story Mapping (2014), on product-vs-tool framing.

---

Q4 — "What is your one-year p50 and p99 traffic forecast in RPS or daily-active users?"

Recommended answer: two numbers grounded in evidence — current baseline × growth multiplier with a named source ("today 12 RPS p50 / 45 RPS p99 from CloudWatch last 30 days; +3× per board commit; year-1 target 36 / 135 RPS"). Not "we want to scale."

Why it matters: premature scale planning is the #1 fullstack cost overrun. Backends sized for unverified hyperscale waste >50% of cloud spend (Vogels, 2016, "10 lessons"). Frontends sized for ten users with edge CDNs / SSR-on-everything are paying for performance their audience does not measure.

Kill criterion: p99 forecast > 100× current with no evidence basis — STOP. Build for 3× headroom; instrument the actual curve.

Canon: Martin Kleppmann, Designing Data-Intensive Applications (2017), ch. 1 on capacity planning; Werner Vogels, 10 Lessons from 10 Years of AWS (2016).

---

Q5 — "Are you hiring against your stack, or training your existing team into it?"

Recommended answer: one of "hiring against it" (with named recruiter pipeline + active reqs) or "training" (with named senior who has shipped this stack before). "Both" is usually neither.

Why it matters: exotic-stack picks (Elm, F#, Erlang, OCaml in 2026) ship the architecture but kill the recruiting curve. A Java-only team picking Rust because "it's safer" pays 6–12 months of velocity tax. A Next.js team picking Remix because "RSCs are confusing" pays the migration tax and the team has no senior.

Kill criterion: stack pick with no on-team senior AND no active reqs AND no recruiter pipeline — STOP. Pick the stack the team has shipped before.

Canon: Camille Fournier, The Manager's Path (2017), ch. 8 on hiring-velocity tax; Andy Grove, High Output Management (1983), on training as throughput investment.

---

Q6 — "What is the year-one monthly cloud + SaaS budget ceiling?"

Recommended answer: a single dollar figure with sign-off (e.g., "$3.5K/mo through year 1, signed off by CFO"). Not "as low as possible." Not "we'll figure it out."

Why it matters: the default fullstack stack in 2026 (Vercel + Supabase + Sentry + LaunchDarkly + Datadog + Auth0 + Stripe + Linear) clears $4K/mo for any non-trivial product before a single customer pays. Without a ceiling, the team picks Big-Co defaults and ships before noticing the burn.

Kill criterion: no ceiling AND default-Vercel-and-five-add-ons stack — STOP. Either set the ceiling or accept the burn in writing (CFO sign-off in chat).

Canon: Tomasz Tunguz, Cloud Cost Discipline essays (2020–2024); Bessemer State of the Cloud (annual); Martin Casado & Sarah Wang, The Cost of Cloud, a Trillion Dollar Paradox (a16z, 2021).

---

Q7 — "What does done look like? Name the verifiable success criteria — three measurable metrics, each with a target."

Recommended answer: three concrete metrics with thresholds (e.g., "p95 API latency < 200ms; first-contentful-paint < 1.8s on mobile-4G; uptime ≥ 99.9% over rolling 30 days"). Each metric must be machine-checkable, not "feels fast."

Why it matters: this is Karpathy Principle #4 (Goal-Driven Execution). Without verifiable success criteria, the implementation "looks right" and ships before anyone notices the regressions. Karpathy's 2026 critique: the LLM (and the human team) cannot loop toward a target if no target is named.

Kill criterion: any answer that does not contain a number — STOP. "Fast," "scalable," "robust," "production-ready," "great UX" are not success criteria.

Canon: Andrej Karpathy, 4 Coding Principles (2026), Principle #4; Tom Gilb, Competitive Engineering (2005), on quantified-quality discipline.

---

How to use this library in a conversation

1. State the rule first — tell the user you'll walk seven questions, one at a time, before recommending any stack or architecture. 2. One question per turn. Never bundle. 3. Recommend the answer. Always cite the canon source for why this is the right shape. 4. Surface the kill criterion. If the user's answer trips it, stop and surface that gap. Do not proceed. 5. Track the answers. Write them to a working file (e.g., /tmp/fullstack-grill-<date>.md) so the conversation can resume. 6. After Q7, recommend the profile. Match the seven answers against the profile JSON files in ../profiles/ and pick the closest fit. Surface ≥ 2 close matches with the tradeoff between them.

Fullstack Tech Stack Guide

Technology selection guide with trade-offs, use cases, and integration patterns for modern fullstack development.

---

Table of Contents

• Frontend Frameworks
• Backend Frameworks
• Databases
• ORMs and Query Builders
• Authentication Solutions
• Deployment Platforms
• Stack Recommendations

---

Frontend Frameworks

Next.js

Best for: Production React apps, SEO-critical sites, full-stack applications

When to choose:

• Need SSR/SSG for SEO
• Building a product that may scale
• Want full-stack in one framework
• Team familiar with React

// App Router pattern
// app/users/page.tsx
async function UsersPage() {
  const users = await db.user.findMany(); // Server component
  return <UserList users={users} />;
}

// app/users/[id]/page.tsx
export async function generateStaticParams() {
  const users = await db.user.findMany();
  return users.map((user) => ({ id: user.id }));
}

React + Vite

Best for: SPAs, dashboards, internal tools

When to choose:

• Building internal dashboards
• SEO not important
• Need maximum flexibility
• Prefer decoupled frontend/backend

Vue 3

Best for: Teams transitioning from jQuery, progressive enhancement

When to choose:

• Team new to modern frameworks
• Progressive enhancement needed
• Prefer official solutions (Pinia, Vue Router)

Comparison Matrix

---

Backend Frameworks

Node.js Ecosystem

Express.js

import express from "express";
import { userRouter } from "./routes/users";

const app = express();
app.use(express.json());
app.use("/api/users", userRouter);
app.listen(3000);

Fastify

import Fastify from "fastify";

const app = Fastify({ logger: true });

app.get("/users/:id", {
  schema: {
    params: { type: "object", properties: { id: { type: "string" } } },
    response: { 200: UserSchema },
  },
  handler: async (request) => {
    return db.user.findUnique({ where: { id: request.params.id } });
  },
});

NestJS

@Controller("users")
export class UsersController {
  constructor(private usersService: UsersService) {}

  @Get(":id")
  findOne(@Param("id") id: string) {
    return this.usersService.findOne(id);
  }

  @Post()
  @UseGuards(AuthGuard)
  create(@Body() createUserDto: CreateUserDto) {
    return this.usersService.create(createUserDto);
  }
}

Python Ecosystem

FastAPI

from fastapi import FastAPI, Depends
from sqlalchemy.orm import Session

app = FastAPI()

@app.get("/users/{user_id}", response_model=UserResponse)
async def get_user(user_id: int, db: Session = Depends(get_db)):
    user = db.query(User).filter(User.id == user_id).first()
    if not user:
        raise HTTPException(status_code=404)
    return user

Django

Framework Selection Guide

---

Databases

PostgreSQL

Best for: Most applications, relational data, ACID compliance

-- JSON support
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email VARCHAR(255) UNIQUE NOT NULL,
  profile JSONB DEFAULT '{}',
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Full-text search
CREATE INDEX users_search_idx ON users
  USING GIN (to_tsvector('english', email || ' ' || profile->>'name'));

SELECT * FROM users
WHERE to_tsvector('english', email || ' ' || profile->>'name')
  @@ to_tsquery('john');

MongoDB

Best for: Document-heavy apps, flexible schemas, rapid prototyping

// Flexible schema
const userSchema = new Schema({
  email: { type: String, required: true, unique: true },
  profile: {
    name: String,
    preferences: Schema.Types.Mixed, // Any structure
  },
  orders: [{ type: Schema.Types.ObjectId, ref: "Order" }],
});

Redis

Best for: Caching, sessions, real-time features, queues

// Session storage
await redis.set(`session:${sessionId}`, JSON.stringify(user), "EX", 3600);

// Rate limiting
const requests = await redis.incr(`rate:${ip}`);
if (requests === 1) await redis.expire(`rate:${ip}`, 60);
if (requests > 100) throw new TooManyRequestsError();

// Pub/Sub
redis.publish("notifications", JSON.stringify({ userId, message }));

Database Selection Matrix

---

ORMs and Query Builders

Prisma

Best for: TypeScript projects, schema-first development

// schema.prisma
model User {
  id        String   @id @default(cuid())
  email     String   @unique
  posts     Post[]
  profile   Profile?
  createdAt DateTime @default(now())
}

// Usage - fully typed
const user = await prisma.user.findUnique({
  where: { email: "user@example.com" },
  include: { posts: true, profile: true },
});
// user.posts is Post[] - TypeScript knows

Drizzle

Best for: SQL-first TypeScript, performance-critical apps

// Schema definition
const users = pgTable("users", {
  id: uuid("id").primaryKey().defaultRandom(),
  email: varchar("email", { length: 255 }).notNull().unique(),
  createdAt: timestamp("created_at").defaultNow(),
});

// Query - SQL-like syntax
const result = await db
  .select()
  .from(users)
  .where(eq(users.email, "user@example.com"))
  .leftJoin(posts, eq(posts.userId, users.id));

SQLAlchemy (Python)

# Model definition
class User(Base):
    __tablename__ = "users"

    id = Column(UUID, primary_key=True, default=uuid4)
    email = Column(String(255), unique=True, nullable=False)
    posts = relationship("Post", back_populates="author")

# Query
users = session.query(User)\
    .filter(User.email.like("%@example.com"))\
    .options(joinedload(User.posts))\
    .all()

---

Authentication Solutions

Auth.js (NextAuth)

Best for: Next.js apps, social logins

// app/api/auth/[...nextauth]/route.ts
import NextAuth from "next-auth";
import GitHub from "next-auth/providers/github";
import Credentials from "next-auth/providers/credentials";

export const { handlers, auth, signIn, signOut } = NextAuth({
  providers: [
    GitHub,
    Credentials({
      credentials: { email: {}, password: {} },
      authorize: async (credentials) => {
        const user = await verifyCredentials(credentials);
        return user;
      },
    }),
  ],
  callbacks: {
    jwt({ token, user }) {
      if (user) token.role = user.role;
      return token;
    },
  },
});

Clerk

Best for: Rapid development, hosted solution

// Middleware
import { clerkMiddleware } from "@clerk/nextjs/server";

export default clerkMiddleware();

// Usage
import { auth } from "@clerk/nextjs/server";

export async function GET() {
  const { userId } = await auth();
  if (!userId) return new Response("Unauthorized", { status: 401 });
  // ...
}

Custom JWT

Best for: Full control, microservices

// Token generation
function generateTokens(user: User) {
  const accessToken = jwt.sign(
    { sub: user.id, role: user.role },
    process.env.JWT_SECRET,
    { expiresIn: "15m" }
  );

  const refreshToken = jwt.sign(
    { sub: user.id, version: user.tokenVersion },
    process.env.REFRESH_SECRET,
    { expiresIn: "7d" }
  );

  return { accessToken, refreshToken };
}

// Middleware
function authenticate(req, res, next) {
  const token = req.headers.authorization?.replace("Bearer ", "");
  if (!token) return res.status(401).json({ error: "No token" });

  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET);
    next();
  } catch {
    res.status(401).json({ error: "Invalid token" });
  }
}

---

Deployment Platforms

Vercel

Best for: Next.js, frontend-focused teams

Railway

Best for: Full-stack apps, databases included

AWS (ECS/Lambda)

Best for: Enterprise, complex requirements

Deployment Selection

---

Stack Recommendations

Startup MVP

Frontend: Next.js 14 (App Router)
Backend:  Next.js API Routes
Database: PostgreSQL (Neon/Supabase)
Auth:     Auth.js or Clerk
Deploy:   Vercel
Cache:    Vercel KV or Upstash Redis

Why: Fastest time to market, single deployment, good scaling path.

SaaS Product

Frontend: Next.js 14
Backend:  Separate API (FastAPI or NestJS)
Database: PostgreSQL (RDS)
Auth:     Custom JWT + Auth.js
Deploy:   Vercel (frontend) + AWS ECS (backend)
Cache:    Redis (ElastiCache)
Queue:    SQS or BullMQ

Why: Separation allows independent scaling, team specialization.

Enterprise Application

Frontend: Next.js or React + Vite
Backend:  NestJS or Go
Database: PostgreSQL (Aurora)
Auth:     Keycloak or Auth0
Deploy:   Kubernetes (EKS/GKE)
Cache:    Redis Cluster
Queue:    Kafka or RabbitMQ
Observability: Datadog or Grafana Stack

Why: Maximum control, compliance requirements, team expertise.

Internal Tool

Frontend: React + Vite + Tailwind
Backend:  Express or FastAPI
Database: PostgreSQL or SQLite
Auth:     OIDC with corporate IdP
Deploy:   Docker on internal infrastructure

Why: Simple, low maintenance, integrates with existing systems.

---

Quick Decision Guide