express

Express Implementation Patterns

Use this skill to keep Express applications modular, type-safe, secure, testable, and predictable.

Express is intentionally minimal. Keep application structure explicit rather than concentrating the entire backend in app.ts.

When to Use

Use this skill when:

• Implementing or refactoring an Express.js application, router, controller, service, repository, or middleware.
• Designing runtime validation, authentication, error handling, file uploads, or request lifecycle behavior in Express.
• Reviewing an Express TypeScript API for architecture, security, performance, observability, or test coverage.
• Migrating between Express 4 and Express 5 or changing async route and error-handling behavior.

When NOT to Use

Do not use this skill when:

• The service is implemented with NestJS, FastAPI, Spring Boot, or another backend framework with its own dedicated skill.
• The task is limited to frontend TypeScript, React, Vue, Angular, or browser-only code.
• The task concerns only SQL, infrastructure, containerization, or CI configuration without Express application changes.

Delivery Workflow

Use the checklist below and track progress:

Express progress:
- [ ] Step 1: Discover app structure, routing conventions, and middleware order
- [ ] Step 2: Model request schemas, validation, and authorization boundaries
- [ ] Step 3: Implement router/controller/service/repository responsibilities cleanly
- [ ] Step 4: Handle errors, async flow, side effects, and infrastructure concerns explicitly
- [ ] Step 5: Verify tests, security, observability, and production runtime behavior

Architecture Rules

• Keep app.ts focused on app composition only: middleware, routes, error handlers, and infrastructure wiring.
• Keep server.ts focused on process startup: config loading, port binding, graceful shutdown, and fatal error handling.
• Keep routers thin: route definitions, middleware composition, controller binding.
• Keep controllers thin: parse validated request data, delegate to services, map responses.
• Put business logic in services or domain collaborators, not routers, middleware, or controllers.
• Isolate database access behind repositories/data-access modules.
• Keep validation, authorization, persistence, mapping, and side effects separate.
• Avoid circular imports by organizing dependencies inward: route → controller → service → repository.
• Reuse project-standard config, logging, validation, and error patterns before introducing new abstractions.