Node backend
Skill muxammadmamajonov/dot-claude/.claude/skills/node-backend
Use for Node.js backend services — NestJS, Fastify, Express — API design, middleware, auth, database integration, testing. Triggers — Node/TS server code, package.json, 'nestjs'.From its SKILL.md
npx -y skills add muxammadmamajonov/dot-claude --skill node-backendAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.5 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
Node.js Backend Development
When to use
- Writing REST or GraphQL APIs with Express, Fastify, or NestJS
- Designing middleware, guards, interceptors, or pipes
- Implementing authentication, authorization, or rate-limiting
- Integrating ORMs (Prisma, TypeORM, Drizzle) or raw query builders
- Writing unit/integration tests with Jest or Vitest
- Profiling performance or fixing memory leaks in a Node.js process
Workflow
- Classify — REST, GraphQL, gRPC, WebSocket, or worker/queue service.
- Choose the framework tier:
- NestJS: structured enterprise services (DI, modules, decorators, CLI scaffolding).
- Fastify: high-throughput APIs where raw RPS matters; schema-first with JSON Schema.
- Express: simple services or legacy projects; minimal overhead.
- Scaffold the project using the framework CLI:
- NestJS:
nest new my-service --strict - Fastify:
npm create fastify - Express: plain
npm init+express,helmet,pinominimal setup
- NestJS:
- Design the module/layer boundary:
- NestJS:
Module → Controller → Service → Repository - Fastify/Express:
routes → handlers → services → data-access
- NestJS:
- Define data contracts first — TypeScript interfaces or Zod/class-validator schemas before any handler code.
- Implement handlers — keep controllers thin (parse, delegate, respond). Business logic lives in services.
- Authenticate and authorize before any business logic:
- JWTs: validate signature + expiry; never decode without
verify. - API keys: constant-time comparison with
crypto.timingSafeEqual.
- JWTs: validate signature + expiry; never decode without
- Add error handling globally — NestJS:
ExceptionFilter; Fastify:setErrorHandler; Express: 4-arg error middleware at the end. - Write tests: unit tests for services (mock dependencies), integration tests hitting the real DB via test containers.
- Harden: helmet, cors (explicit allowlist), rate-limit, request size cap, SQL injection prevention via parameterised queries.
- Audit against .claude/checklists/security.md and .claude/checklists/performance.md before deploying.
Standards
TypeScript
- Enable
strict: true,noImplicitAny,strictNullChecksintsconfig.json. - Use
zodorclass-validatorfor runtime validation of all external input. - Avoid
any; useunknownand narrow explicitly.
NestJS specifics
- One feature per module; no circular module imports — use forwardRef only as last resort.
- Providers are singletons by default; use
REQUESTscope only when truly request-scoped. - Use
@UseGuards,@UsePipes,@UseInterceptorsat the controller/handler level, not ad-hoc in services. - Config:
@nestjs/configwith a typedConfigService; neverprocess.env.Xinline.
Fastify specifics
- Register all plugins with
fastify-pluginwrapper to share decorations across encapsulation. - Define JSON Schema for every route's
body,querystring,params,response— this enables auto-validation and serialisation optimisation. - Use Fastify's
pinologger (already included); do not add Winston on top.
Database
- Use connection pooling (pg-pool, Prisma connection limit, TypeORM pool config) — never create a new connection per request.
- All mutations must be in transactions for multi-step writes.
- Parameterise every query — never string-interpolate user input into SQL.
- Run migrations in CI before integration tests; never auto-migrate in production startup.
Error model
- Return RFC 7807 Problem+JSON (
type,title,status,detail,instance). - 4xx for client errors, 5xx for server faults; never return a stack trace to clients.
- Log correlation IDs with every error; propagate
X-Request-IDthrough service calls.
Do not
- Do not use
require()for dynamic plugin loading at request time — startup-time only. - Do not store secrets in environment-unguarded constants; use
.env+ validation at startup. - Do not swallow errors with empty
catch {}blocks. - Do not use synchronous
fs,crypto.randomBytes(sync), or any blocking call in an async route handler.
Common mistakes to avoid
| Mistake | Fix |
|---|---|
| JWT secret hardcoded in code | Load from process.env; validate its presence at startup. |
| Unhandled promise rejections crashing the process | Attach process.on('unhandledRejection', ...) and handle in async middleware. |
Missing await on async middleware | next() fires before the async work finishes; always await or return the promise. |
| N+1 queries from ORMs | Use include/join or DataLoader pattern for batching. |
| Returning 200 on validation failure | Return 400 with structured error body; never 200 for errors. |
| Listening on port before DB is ready | Health-check the DB in startup; delay listen() or crash fast. |
Output format
- New service: directory tree showing
module / controller / service / dto / entityfiles. - Route handler: TypeScript with typed request/response, validation pipe/schema, and error handling.
- Test file: Jest/Vitest describe block with happy path, validation failure, and auth failure cases.
- Config changes: diff of
tsconfig.json,package.jsonscripts, environment variable list.
Related checklists
- .claude/checklists/security.md
- .claude/checklists/performance.md
- .claude/checklists/qa.md
Related agents
- .claude/agents/core/orchestrator.md
- .claude/agents/engineering/devops-engineer.md
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 1 of the 12 instructions most data backend skills give in ~1.3k tokens
Counted across 229 of the 229 authors here whose files we hold, read 2026-08-07
- Separate business logic into service layershere, and in 22 of 229, across 15 files
- Retry failures with exponential backoffin 21 of 229, across 14 files
- Select only needed database columnsin 20 of 229, across 13 files
- Abstract data access into repository classesin 19 of 229, across 12 files
- Use centralized error handlersin 17 of 229, across 10 files
- Use AsNoTracking for read-only queriesin 16 of 229, across 4 files
- Use async/await for all I/O operationsin 16 of 229, across 5 files
- Implement structured loggingin 15 of 229, across 4 files
- Use dependency injection for all servicesin 14 of 229, across 2 files
- Use resource-based URLs for REST APIsin 13 of 229, across 7 files
- Invalidate cache after data changesin 13 of 229, across 9 files
- Use a dependency injection containerin 12 of 229, across 4 files
Said here and by no other author read
- define data contracts before handler code
- authenticate and authorize before business logic
- attach an unhandledRejection handler
- await async middleware
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.