Top-level routing skill for ALL backend web framework and REST API technologies. Provides cross-framework expertise in API design, HTTP semantics, authentication, framework selection, and performance patterns. Use for framework selection, API design principles, and cross-framework comparisons. WHEN: \"backend framework\", \"REST API\", \"web API\", \"which framework\", \"Express vs FastAPI\", \"Django vs Rails\", \"Spring Boot vs\", \"API design\", \"backend architecture\", \"framework compar...
Installs into .claude/skills of the current project.
Are you the author of Overview?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/chrishuffman5-overview-4a576a73)
---
name: overview
description: "Top-level routing skill for ALL backend web framework and REST API technologies. Provides cross-framework expertise in API design, HTTP semantics, authentication, framework selection, and performance patterns. Use for framework selection, API design principles, and cross-framework comparisons. WHEN: \"backend framework\", \"REST API\", \"web API\", \"which framework\", \"Express vs FastAPI\", \"Django vs Rails\", \"Spring Boot vs\", \"API design\", \"backend architecture\", \"framework comparison\", \"API authentication\", \"API versioning\", \"middleware\", \"API performance\". Do NOT use for framework-specific implementation questions — use the matching technology skill (aspnet-core, django, express, fastapi, flask, go-web, nestjs, rails, rust-web, spring-boot)."
license: MIT
---
# Backend / REST API Domain
This skill is the top-level entry point for all backend web framework and API technologies. It covers cross-framework expertise in API design, HTTP semantics, authentication paradigms, framework selection, and performance patterns, and points to technology-specific skills for deep implementation details.
## When to Use This Skill vs. a Technology Skill
**Use this skill when the question is cross-framework or architectural:**
- "Which backend framework for our new project?"
- "How should I design my REST API versioning?"
- "Session auth vs JWT — when to use which?"
- "Batteries-included vs micro-framework for a startup?"
- "Sync vs async — does it actually matter?"
- "How should I paginate this API?"
- "API design review"
**Route to the matching technology skill when the question is technology-specific:**
- "ASP.NET Core Minimal API route groups" --> the `aspnet-core` skill
- "Express middleware ordering issue" --> the `express` skill
- "FastAPI dependency injection" --> the `fastapi` skill
- "Spring Boot auto-configuration" --> the `spring-boot` skill
- "Django ORM N+1 query" --> the `django` skill
- "Flask blueprint registration" --> the `flask` skill
- "NestJS guard vs interceptor" --> the `nestjs` skill
- "Rails Active Record callbacks" --> the `rails` skill
- "Go Gin middleware" --> the `go-web` skill
- "Rust Axum extractors" --> the `rust-web` skill
## How to Approach Tasks
1. **Classify** the request:
- **Framework selection** -- Use the comparison tables below
- **API design** -- Load `references/concepts.md` for REST principles, versioning, pagination, error handling
- **Authentication / authorization** -- Load `references/concepts.md` for auth paradigms (session, JWT, OAuth, CORS)
- **Performance** -- Load `references/concepts.md` for scaling patterns, connection pooling, async models
- **Paradigm comparison** -- Use the paradigm tables below, load `references/paradigm-*.md` for depth
- **Technology-specific** -- Read the matching technology skill
2. **Gather context** -- Language preferences, team expertise, project type (API-only vs full-stack), scale requirements, deployment target
3. **Analyze** -- Apply API design principles. Every pattern has trade-offs; never recommend without qualifying.
4. **Recommend** -- Ranked recommendation with trade-offs, not a single answer
## Framework Paradigms
### Batteries-Included (Full-Stack)
Frameworks that include ORM, auth, admin, migrations, templating out of the box. Opinionated — follow conventions and move fast.
| Framework | Language | Includes | Best For |
|---|---|---|---|
| **Django** | Python | ORM, admin, auth, forms, migrations, templates | Data-driven apps, rapid prototyping, content management |
| **Rails** | Ruby | ActiveRecord, Action Cable, Active Job, Turbo/Hotwire | Startups, full-stack web apps, convention over configuration |
| **Spring Boot** | Java/Kotlin | DI, Spring Data, Spring Security, Actuator, auto-config | Enterprise, microservices, JVM ecosystem |
| **ASP.NET Core** | C# | DI, EF Core, Identity, SignalR, Minimal APIs | Microsoft/.NET shops, enterprise, high performance |
### Micro-Framework
Minimal core — routing and middleware. You compose your own stack from libraries. Maximum flexibility, more assembly required.
| Framework | Language | Core Provides | Best For |
|---|---|---|---|
| **Express** | JS/TS | Routing, middleware chain | API-only services, Node.js ecosystem, rapid iteration |
| **Flask** | Python | Routing, Jinja2, Werkzeug | Small APIs, prototyping, microservices, learning |
| **Gin** | Go | Routing, JSON binding, middleware | High-performance APIs, Go ecosystem |
| **Fiber** | Go | Express-like API on fasthttp | Maximum throughput, familiar Express patterns |
### Async-First
Built on async runtimes for high-concurrency I/O-bound workloads. Best when your API is a proxy/orchestrator — calling databases, caches, and external APIs.
| Framework | Language | Runtime | Best For |
|---|---|---|---|
| **FastAPI** | Python | asyncio/ASGI (Starlette) | Modern Python APIs, auto-docs, type-driven development |
| **NestJS** | TS | Node.js event loop | Structured Node.js, Angular-like DI, enterprise TypeScript |
| **Actix Web** | Rust | Tokio | Maximum performance, safety-critical systems |
| **Axum** | Rust | Tokio (Tower ecosystem) | Composable Rust APIs, Tower middleware reuse |
## Technology Comparison
| Framework | Language | Paradigm | Performance | Learning Curve | Ecosystem | Trade-offs |
|---|---|---|---|---|---|---|
| **ASP.NET Core** | C# | Full-stack | Excellent | Medium | Large (.NET) | Windows heritage, licensing complexity |
| **Express** | JS/TS | Micro | Good | Low | Massive (npm) | Callback patterns, minimal structure |
| **FastAPI** | Python | Async | Very good | Low | Growing | Python GIL limits CPU-bound, 0.x versioning |
| **Spring Boot** | Java/Kotlin | Full-stack | Very good | High | Massive (JVM) | Verbose, heavy memory footprint, annotation magic |
| **Django** | Python | Full-stack | Moderate | Medium | Large | Monolithic feel, async support maturing |
| **Flask** | Python | Micro | Moderate | Very low | Large (extensions) | No opinions means more decisions |
| **NestJS** | TypeScript | Structured | Good | Medium-High | Growing | Decorator-heavy, steep DI learning curve |
| **Rails** | Ruby | Full-stack | Moderate | Medium | Large (gems) | Ruby performance, convention lock-in |
| **Go (net/http, Gin)** | Go | Micro/stdlib | Excellent | Low-Medium | Moderate | Verbose error handling, no generics until recently |
| **Rust (Actix, Axum)** | Rust | Async | Outstanding | High | Growing | Borrow checker, compile times, smaller ecosystem |
## Decision Framework
### Step 1: What kind of project?
| Project Type | Strong Candidates | Avoid |
|---|---|---|
| **API-only microservice** | FastAPI, Express, Gin, Axum | Django, Rails (overkill) |
| **Full-stack web app** | Django, Rails, ASP.NET Core, Spring Boot | Gin, Fiber (no templating) |
| **Enterprise / regulated** | Spring Boot, ASP.NET Core | Flask, Express (too unstructured) |
| **Real-time (WebSockets)** | NestJS, ASP.NET Core (SignalR), Rails (Action Cable) | Flask (limited async) |
| **ML/AI serving** | FastAPI, Flask | Spring Boot (Python model loading) |
| **Maximum performance** | Actix, Axum, Gin, ASP.NET Core | Django, Rails, Flask |
### Step 2: What does the team know?
This matters more than benchmarks. A team fluent in Python will ship faster with Django than with Spring Boot — even if Spring Boot benchmarks higher.
| Team Background | Natural Fit |
|---|---|
| Python developers | FastAPI (modern), Django (full-stack), Flask (simple) |
| JavaScript/TypeScript | Express (simple), NestJS (structured) |
| Java/Kotlin | Spring Boot |
| C#/.NET | ASP.NET Core |
| Ruby | Rails |
| Go | net/http + Gin or Fiber |
| Rust | Axum or Actix Web |
| Mixed / no preference | FastAPI or Express (lowest barrier) |
### Step 3: Scale expectations?
- **< 1K RPS**: Any framework handles this comfortably. Choose by productivity.
- **1K-10K RPS**: Still any framework with proper architecture. The database is the bottleneck, not the framework.
- **10K-100K RPS**: Go, Rust, or ASP.NET Core have an edge. But properly tuned FastAPI/Express handle this too.
- **> 100K RPS**: Go or Rust. Consider whether you actually need this — most don't.
**The uncomfortable truth**: Framework performance rarely matters. Database queries, network I/O, and architecture decisions dominate. A well-architected Django app outperforms a poorly-architected Actix app.
## Subcategory Routing
| Request Pattern | Route To |
|---|---|
| **Full-Stack Frameworks** | |
| ASP.NET Core, Minimal APIs, .NET Web API, Kestrel, EF Core | the `aspnet-core` skill |
| Spring Boot, Spring MVC, WebFlux, Actuator, JPA | the `spring-boot` skill |
| Django, DRF, ORM, admin, migrations, ASGI | the `django` skill |
| Rails, ActiveRecord, Action Cable, Turbo, Hotwire | the `rails` skill |
| **Micro-Frameworks** | |
| Express, middleware, routing, template engines | the `express` skill |
| Flask, blueprints, extensions, Jinja2, Werkzeug | the `flask` skill |
| **Async / Structured Frameworks** | |
| FastAPI, Pydantic, Starlette, async, OpenAPI auto-docs | the `fastapi` skill |
| NestJS, modules, providers, guards, interceptors, decorators | the `nestjs` skill |
| **Systems-Language Frameworks** | |
| Go, net/http, Gin, Fiber, chi, Echo, goroutines | the `go-web` skill |
| Rust, Actix Web, Axum, Tower, Tokio, extractors | the `rust-web` skill |
## Anti-Patterns
1. **"Benchmarks choose the framework"** — TechEmpower benchmarks measure hello-world throughput, not real application performance. The database, not the framework, is the bottleneck.
2. **"Micro-framework for a monolith"** — Express with 40 middleware packages is just a badly-organized Django. If you need batteries, use a batteries-included framework.
3. **"Full-stack framework for a Lambda function"** — Django in a Lambda function carries 200MB of ORM you won't use. Use Flask or a micro-framework.
4. **"REST for everything"** — gRPC is better for internal service-to-service. GraphQL is better for complex client-driven queries. REST is great for public APIs and simple CRUD.
5. **"No API versioning until v2"** — Version from day one. Adding versioning to a live API is painful.
6. **"Rolling your own auth"** — Use your framework's auth system or a dedicated IdP (Auth0, Keycloak, Entra ID). Custom auth is a security liability.
## Reference Files
Load these for deep foundational knowledge:
- `references/concepts.md` — REST/HTTP semantics, API versioning, pagination, error handling, authentication paradigms (session, JWT, OAuth 2.0, CORS), performance patterns (connection pooling, async models, horizontal scaling). Read for "how should I design X" or "session vs JWT" questions.
- `references/paradigm-traditional.md` — Batteries-included and MVC framework patterns (Django, Rails, Spring Boot, ASP.NET Core). Read when evaluating full-stack frameworks.
- `references/paradigm-async.md` — Async runtime models (event loop, asyncio, Tokio), when async helps vs hurts, structured concurrency. Read when evaluating async frameworks or deciding sync vs async.