backend-development
Backend Development
Backend engineering guidance for Node.js/TypeScript and Go projects. Covers everything from adding a small feature to designing a new microservice — including vague tasks where you need to figure out the right approach from context.
Related Skills:
kavak-documentation— for Kavak-specific patterns (kbroker, STS, GitLab CI, Docker)test-driven-development— use for new features and bug fixes (Red-Green-Refactor)- Check
.claude/CLAUDE.mdor.cursor/rules/*for project-specific conventionsMCP: Use
kavak-platform/platform_docs_searchto query Kavak internal docs andkavak-platform/search_resourcefor workload/infrastructure info before implementing.
First: Understand the Codebase
Before writing any code, explore the project to understand its structure, patterns, and existing implementations. This matters because the biggest source of wasted effort is reimplementing something that already exists — or writing code that clashes with the project's established patterns.
- Read the project structure — identify the architecture, naming conventions, and patterns in use
- Search for similar code — extract keywords from your task (verbs, nouns, domain concepts) and search. You're looking for code you can reuse, extend, or extract shared logic from
- Document your reuse decision — REUSE (>70% similar), EXTEND (50-70%), EXTRACT (shared helper), or NEW (<30% similar)
Full process, search templates, and decision matrix: references/code-reuse-analysis.md
Core Principles
Architecture: Clean Architecture (4-layer) for new projects → references/architecture.md
- SOLID — each module does one thing, depends on abstractions not implementations
- DRY — every piece of business logic has ONE source of truth →
references/dry-detection.md - YAGNI — only build what the task requires right now, not hypothetical future needs
- KISS — the simplest solution that works is the right one
Code should be self-documenting. Comments explain "why", not "what". See references/code-quality.md for examples.
Existing Projects Rule
Follow the project's established patterns — if it uses flat structure, keep flat structure. If it uses callbacks, use callbacks. Don't force Clean Architecture on a codebase that doesn't use it. Apply good practices to new code you write, but match the project's conventions.
Clean Architecture applies to: new greenfield projects, new modules (when it fits), or explicit refactoring requests.
Quick Start
| Language | Test | Lint |
|---|---|---|
| Node/TS | npm test |
npm run lint |
| Go | go test ./... |
golangci-lint run |
Technology Selection
| Need | Choose |
|---|---|
| TypeScript API | NestJS |
| High concurrency | Go + Chi |
| Go database | pgx/v5 + sqlc |
| Node database | Drizzle (new), keep existing |
| Go Redis | rueidis (new), keep existing |
| Go job queue | River (PostgreSQL-backed) |
| Node job queue | pg-boss (PostgreSQL-backed) |
| Events (Kavak) | kbroker (Kafka-by-REST) |
| Rate limiting | pg-boss throttle / River snooze |
| Testing | Vitest (new Node), Jest (existing) |
| Tracing | OpenTelemetry + dd-trace |
Note: Use kbroker for events between services. Use pg-boss (Node) or River (Go) for job queues.
Common Workflows
New API Endpoint (TDD Approach)
Use
test-driven-developmentskill for Red-Green-Refactor cycle
- Write failing test first →
test-driven-developmentskill - Design endpoint →
references/api-design.md - Set up handler →
references/go/http-handlers.mdorreferences/node/frameworks.md - Add database access →
references/go/database.mdorreferences/node/database.md - Implement auth →
references/authentication.md - Refactor with tests passing →
references/code-quality.md
Add Similar Feature (DRY-First)
When the task says "do X like Y" or "add similar to existing":
- Find the existing implementation first — search for the feature mentioned
- >70% similar: inject existing service, call its method (5-10 lines)
- 50-70% similar: extract shared helper, refactor both old and new to use it
- <50% similar: OK to create new, keep it minimal
- Test both old and new paths — ensure refactoring didn't break existing
If your new code exceeds 50 lines, you likely missed a reuse opportunity.
Fix Slow Query
- Profile query →
references/debugging.md(EXPLAIN ANALYZE) - Add indexes →
references/performance.md - Add caching →
references/go/redis-queues.mdorreferences/node/database.md
Deploy New Service
- Write Dockerfile →
references/devops/docker.md - Set up CI/CD →
references/devops/ci-cd.md
Debug Production Issue
- Check logs/traces →
references/debugging.md - Profile if slow →
references/debugging.md(pprof/clinic.js) - Check DB queries →
references/debugging.md(pg_stat_statements)
References
| Reference | When to Use |
|---|---|
| Go | |
references/go/http-handlers.md |
Set up Chi routes, handlers, middleware |
references/go/database.md |
Implement pgx/v5, sqlc queries |
references/go/patterns.md |
Apply error handling, validation, testing |
references/go/redis-queues.md |
Add rueidis caching, River job queue |
| Node.js | |
references/node/frameworks.md |
Set up NestJS, Express, Fastify |
references/node/database.md |
Implement Drizzle, Prisma, caching |
references/node/patterns.md |
Apply validation, errors, testing |
| DevOps | |
references/devops/docker.md |
Write Dockerfiles, compose, health checks, DataDog metrics |
references/devops/ci-cd.md |
Configure GitLab CI pipelines |
| Cross-Cutting | |
references/architecture.md |
Clean Architecture (4-layer), microservices, events |
references/code-quality.md |
SOLID, DRY, YAGNI, KISS, design patterns |
references/code-reuse-analysis.md |
MANDATORY - Code reuse gate, decision matrix |
references/dry-detection.md |
MANDATORY - DRY detection, code reuse patterns |
references/api-design.md |
Design REST endpoints, versioning |
references/authentication.md |
Implement OAuth 2.1, JWT, RBAC |
references/security.md |
Apply OWASP Top 10, input validation |
references/performance.md |
Optimize caching, queries, pooling |
references/testing.md |
Write unit, integration, E2E tests |
references/debugging.md |
Debug with logs, profilers, tracing |
| Kavak | |
references/kavak/kbroker.md |
Publish/subscribe events between services |
references/kavak/queues-ratelimit.md |
Job queues, rate limiting with River/pg-boss |
references/kavak/microservice-auth.md |
Authenticate between services (STS) |
references/kavak/gitlab-ci.md |
Set up kavak-it/ci-jobs v3 pipelines |
references/kavak/docker-images.md |
Build with docker-debian base |
references/kavak/workload-config.md |
Configure .kavak/ dir, cron jobs |
references/kavak/logging-metrics.md |
Use kvklog, kvkmetric SDKs |
More from carvalab/k-skills
code-review
Use this skill as the FINAL step after writing or modifying code — reviews for logic bugs, architecture violations, security issues, and performance problems. Trigger after completing a feature, fixing a bug, before merging, or when asked to "review this code", "check my changes", or "is this ready to merge". Fixes issues directly and runs quality gates (lint, typecheck, build, tests). Delegates style to automation, focuses on what matters.
38refactor-cleaner
Use this skill to find and remove dead code, unused dependencies, duplicate logic, and unused exports using detection tools (knip, depcheck, ts-prune, deadcode, staticcheck). Trigger on "clean up dead code", "remove unused", "find dead code", "reduce bundle size", "dependency audit", or when the codebase feels bloated. For simplifying living code (readability, naming, complexity reduction) without detection tools, use code-simplifier instead. Use this skill during maintenance windows or before major refactors.
36code-simplifier
Use this skill after writing or modifying code to simplify it — reduces complexity, eliminates redundancy, and improves naming while preserving exact behavior. Trigger after implementing a feature, after a refactor, or when asked to "clean up this code", "simplify this", "make this more readable", or "reduce complexity". Also use when code feels too nested, verbose, or hard to follow. For removing dead code and unused dependencies with detection tools (knip, ts-prune, deadcode), use refactor-cleaner instead.
24doc-updater
Use this skill when documentation needs updating — after adding features, changing APIs, modifying architecture, or updating dependencies. Trigger on "update the docs", "generate codemap", "refresh the README", "document this", "update architecture docs", or when code changes make existing documentation stale. Generates codemaps from actual code, updates READMEs, architecture diagrams, and guides.
22frontend-development
Use this skill for ANY task in a Next.js or React frontend codebase — adding pages, building components, fixing UI bugs, styling, handling forms, fetching data, or modifying layouts. Trigger even when the task is vague like "add this feature", "fix the UI", "make this page", or "update the form" — if the project has next.config.*, React components, or client-side TypeScript, this skill applies. Covers App Router, Server Components, Server Actions, MUI styling, Zod validation, caching, and design quality. When in doubt whether this is frontend work, use this skill.
21test-driven-development
Use this skill when writing new features, fixing bugs, or adding test coverage. Enforces Red-Green-Refactor — write the test first, then the code. Trigger on "add tests", "write tests first", "TDD", "test this feature", "fix this bug" (reproduce with a failing test first), or when starting any new implementation. Prevents testing anti-patterns like over-mocking, test-per-method, and tests that pass but verify nothing.
19