PluginBench
Skill
Pass
Audit score 90

nodejs-best-practices

sickn33/agentic-awesome-skills

Node.js development principles and decision-making for architecture, frameworks, async patterns, and security.

What is nodejs-best-practices?

This skill teaches Node.js architectural thinking and decision-making rather than rote code patterns. Use it when selecting frameworks, designing async flows, implementing security practices, or making deployment decisions. It covers framework selection (Hono, Fastify, Express, NestJS), runtime choices, layered architecture, error handling, validation, and security principles for 2025.

  • Framework selection decision tree for edge, serverless, high-performance, enterprise, and full-stack contexts
  • Runtime and module system guidance (Node.js vs Bun vs Deno, ESM vs CommonJS, native TypeScript)
  • Layered architecture principles (controller, service, repository) with testability and flexibility considerations
  • Centralized error handling patterns with appropriate HTTP status codes and logging strategies
  • Async pattern guidance (async/await, Promise.all, allSettled, race) with event loop awareness
  • Input validation principles and library selection (Zod, Valibot, ArkType, Yup)

How to install nodejs-best-practices

npx skills add https://github.com/sickn33/agentic-awesome-skills --skill nodejs-best-practices
Claude Code
Cursor
Windsurf
Cline

How to use nodejs-best-practices

  1. 1.Review the framework selection decision tree for your specific use case (edge, serverless, high-performance, enterprise, or full-stack)
  2. 2.Identify your deployment target and ask yourself the selection questions (deployment, cold start criticality, team experience, legacy code)
  3. 3.Choose your runtime and module system based on project requirements (Node.js, Bun, or Deno; ESM or CommonJS)
  4. 4.Design your architecture using the layered structure concept (controller, service, repository) if your project will grow
  5. 5.Plan your error handling strategy with centralized error handling and appropriate HTTP status codes
  6. 6.Identify all validation points (API entry, database operations, external data, environment variables) and select a validation library
  7. 7.Apply the security checklist to your project (input validation, parameterized queries, password hashing, JWT verification, rate limiting, headers, HTTPS, CORS, secrets, dependencies)
  8. 8.Choose your testing strategy based on priorities (critical paths, edge cases, error handling)

Use cases

Good for
  • Choosing between Express, Fastify, Hono, or NestJS for a new API project based on deployment target and team experience
  • Designing error handling and HTTP status code responses for a REST API
  • Deciding whether to use async/await or Promise.all for concurrent database operations
  • Validating request inputs and external API responses at API boundaries
  • Planning security measures for authentication, authorization, and data protection
Who it's for
  • Node.js developers making architectural decisions
  • Backend engineers choosing frameworks for new projects
  • Teams establishing coding standards and best practices
  • Developers transitioning between different Node.js frameworks
  • Security-conscious developers implementing validation and error handling

nodejs-best-practices FAQ

Should I use Express or Fastify for a new project?

Use Fastify for high-performance APIs where speed matters (2-3x faster than Express). Use Express if your team is already familiar with it or you need maximum ecosystem compatibility. For edge/serverless, use Hono instead. The decision depends on your deployment target and performance requirements.

When should I use async/await vs Promise.all?

Use async/await for sequential operations where one depends on the previous result. Use Promise.all for parallel independent operations to avoid unnecessary waiting. Use Promise.allSettled if some operations can fail without stopping others. Use Promise.race for timeout or first-response-wins scenarios.

What validation library should I choose?

Use Zod for TypeScript-first projects with type inference. Use Valibot for smaller bundle size. Use ArkType for performance-critical applications. Use Yup if you're already using it with React Forms. The choice depends on your project's TypeScript usage and bundle size constraints.

How do I structure my Node.js application as it grows?

Use layered architecture: Controller/Route layer handles HTTP specifics and input validation, Service layer contains business logic and is framework-agnostic, Repository layer handles only data access and ORM interactions. This separation enables independent testing, easy database swaps, and clear responsibilities.

What's the most important security practice for Node.js APIs?

Validate all inputs at boundaries (query params, request body, headers, cookies, file uploads) and never trust external data. Use parameterized queries to prevent SQL injection, hash passwords with bcrypt or argon2, verify JWT signatures, implement rate limiting, and store secrets in environment variables only.

Full instructions (SKILL.md)

Source of truth, from sickn33/agentic-awesome-skills.


name: nodejs-best-practices description: "Node.js development principles and decision-making. Framework selection, async patterns, security, and architecture. Teaches thinking, not copying." risk: critical source: community date_added: "2026-02-27"

Node.js Best Practices

Principles and decision-making for Node.js development in 2025. Learn to THINK, not memorize code patterns.

When to Use

Use this skill when making Node.js architecture decisions, choosing frameworks, designing async patterns, or applying security and deployment best practices.


⚠️ How to Use This Skill

This skill teaches decision-making principles, not fixed code to copy.

  • ASK user for preferences when unclear
  • Choose framework/pattern based on CONTEXT
  • Don't default to same solution every time

1. Framework Selection (2025)

Decision Tree

What are you building?
│
├── Edge/Serverless (Cloudflare, Vercel)
│   └── Hono (zero-dependency, ultra-fast cold starts)
│
├── High Performance API
│   └── Fastify (2-3x faster than Express)
│
├── Enterprise/Team familiarity
│   └── NestJS (structured, DI, decorators)
│
├── Legacy/Stable/Maximum ecosystem
│   └── Express (mature, most middleware)
│
└── Full-stack with frontend
    └── Next.js API Routes or tRPC

Comparison Principles

FactorHonoFastifyExpress
Best forEdge, serverlessPerformanceLegacy, learning
Cold startFastestFastModerate
EcosystemGrowingGoodLargest
TypeScriptNativeExcellentGood
Learning curveLowMediumLow

Selection Questions to Ask:

  1. What's the deployment target?
  2. Is cold start time critical?
  3. Does team have existing experience?
  4. Is there legacy code to maintain?

2. Runtime Considerations (2025)

Native TypeScript

Node.js 22+: --experimental-strip-types
├── Run .ts files directly
├── No build step needed for simple projects
└── Consider for: scripts, simple APIs

Module System Decision

ESM (import/export)
├── Modern standard
├── Better tree-shaking
├── Async module loading
└── Use for: new projects

CommonJS (require)
├── Legacy compatibility
├── More npm packages support
└── Use for: existing codebases, some edge cases

Runtime Selection

RuntimeBest For
Node.jsGeneral purpose, largest ecosystem
BunPerformance, built-in bundler
DenoSecurity-first, built-in TypeScript

3. Architecture Principles

Layered Structure Concept

Request Flow:
│
├── Controller/Route Layer
│   ├── Handles HTTP specifics
│   ├── Input validation at boundary
│   └── Calls service layer
│
├── Service Layer
│   ├── Business logic
│   ├── Framework-agnostic
│   └── Calls repository layer
│
└── Repository Layer
    ├── Data access only
    ├── Database queries
    └── ORM interactions

Why This Matters:

  • Testability: Mock layers independently
  • Flexibility: Swap database without touching business logic
  • Clarity: Each layer has single responsibility

When to Simplify:

  • Small scripts → Single file OK
  • Prototypes → Less structure acceptable
  • Always ask: "Will this grow?"

4. Error Handling Principles

Centralized Error Handling

Pattern:
├── Create custom error classes
├── Throw from any layer
├── Catch at top level (middleware)
└── Format consistent response

Error Response Philosophy

Client gets:
├── Appropriate HTTP status
├── Error code for programmatic handling
├── User-friendly message
└── NO internal details (security!)

Logs get:
├── Full stack trace
├── Request context
├── User ID (if applicable)
└── Timestamp

Status Code Selection

SituationStatusWhen
Bad input400Client sent invalid data
No auth401Missing or invalid credentials
No permission403Valid auth, but not allowed
Not found404Resource doesn't exist
Conflict409Duplicate or state conflict
Validation422Schema valid but business rules fail
Server error500Our fault, log everything

5. Async Patterns Principles

When to Use Each

PatternUse When
async/awaitSequential async operations
Promise.allParallel independent operations
Promise.allSettledParallel where some can fail
Promise.raceTimeout or first response wins

Event Loop Awareness

I/O-bound (async helps):
├── Database queries
├── HTTP requests
├── File system
└── Network operations

CPU-bound (async doesn't help):
├── Crypto operations
├── Image processing
├── Complex calculations
└── → Use worker threads or offload

Avoiding Event Loop Blocking

  • Never use sync methods in production (fs.readFileSync, etc.)
  • Offload CPU-intensive work
  • Use streaming for large data

6. Validation Principles

Validate at Boundaries

Where to validate:
├── API entry point (request body/params)
├── Before database operations
├── External data (API responses, file uploads)
└── Environment variables (startup)

Validation Library Selection

LibraryBest For
ZodTypeScript first, inference
ValibotSmaller bundle (tree-shakeable)
ArkTypePerformance critical
YupExisting React Form usage

Validation Philosophy

  • Fail fast: Validate early
  • Be specific: Clear error messages
  • Don't trust: Even "internal" data

7. Security Principles

Security Checklist (Not Code)

  • Input validation: All inputs validated
  • Parameterized queries: No string concatenation for SQL
  • Password hashing: bcrypt or argon2
  • JWT verification: Always verify signature and expiry
  • Rate limiting: Protect from abuse
  • Security headers: Helmet.js or equivalent
  • HTTPS: Everywhere in production
  • CORS: Properly configured
  • Secrets: Environment variables only
  • Dependencies: Regularly audited

Security Mindset

Trust nothing:
├── Query params → validate
├── Request body → validate
├── Headers → verify
├── Cookies → validate
├── File uploads → scan
└── External APIs → validate response

8. Testing Principles

Test Strategy Selection

TypePurposeTools
UnitBusiness logicnode:test, Vitest
IntegrationAPI endpointsSupertest
E2EFull flowsPlaywright

What to Test (Priorities)

  1. Critical paths: Auth, payments, core business
  2. Edge cases: Empty inputs, boundaries
  3. Error handling: What happens when things fail?
  4. Not worth testing: Framework code, trivial getters

Built-in Test Runner (Node.js 22+)

node --test src/**/*.test.ts
├── No external dependency
├── Good coverage reporting
└── Watch mode available

9. Anti-Patterns to Avoid

❌ DON'T:

  • Use Express for new edge projects (use Hono)
  • Use sync methods in production code
  • Put business logic in controllers
  • Skip input validation
  • Hardcode secrets
  • Trust external data without validation
  • Block event loop with CPU work

✅ DO:

  • Choose framework based on context
  • Ask user for preferences when unclear
  • Use layered architecture for growing projects
  • Validate all inputs
  • Use environment variables for secrets
  • Profile before optimizing

10. Decision Checklist

Before implementing:

  • Asked user about stack preference?
  • Chosen framework for THIS context? (not just default)
  • Considered deployment target?
  • Planned error handling strategy?
  • Identified validation points?
  • Considered security requirements?

Remember: Node.js best practices are about decision-making, not memorizing patterns. Every project deserves fresh consideration based on its requirements.

Limitations

  • Use this skill only when the task clearly matches the scope described above.
  • Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
  • Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.