用途
backend-patterns 提供后端架构模式与最佳实践，用于构建可扩展的服务端应用，主要面向 Node.js、Express 和 Next.js API 路由。它适合在设计 REST 或 GraphQL API 端点、实现仓储/服务/控制器分层、优化数据库查询、添加缓存、搭建后台任务或异步处理、组织 API 错误处理与校验、构建中间件（认证、日志、限流）等场景中参考使用。
主要能力
API 设计模式
- RESTful API 结构：基于资源的 URL，使用 GET/POST/PUT/PATCH/DELETE 对应列表、单条、创建、替换、更新、删除操作；通过查询参数实现过滤、排序、分页（如 status、sort、limit、offset）。
- 仓储模式（Repository Pattern）：抽象数据访问逻辑，定义接口（如 MarketRepository 的 findAll、findById、create、update、delete），并提供具体实现（如 SupabaseMarketRepository）。
- 服务层模式（Service Layer Pattern）：将业务逻辑与数据访问分离，例如 MarketService 中组合向量搜索与仓储查询。
- 中间件模式（Middleware Pattern）：以请求/响应处理管道方式包装处理器，示例为 withAuth 高阶函数校验 Bearer Token 并注入 req.user。
数据库模式
- 查询优化：只选择需要的列，避免 select('*')；使用过滤、排序与 limit。
- 防止 N+1 查询：先批量获取关联 ID，再一次性查询并建立 Map 映射，替代循环内逐条查询。
- 事务模式：通过 Supabase RPC 调用 SQL 函数（如 create_market_with_position）在数据库端自动开启事务与回滚。
缓存策略
- Redis 缓存层：在仓储实现中先查缓存，未命中再查数据库并写回缓存（setex 设置过期时间），并提供 invalidateCache 删除缓存。
- Cache-Aside 模式：先读缓存，未命中查数据库，再更新缓存。
错误处理模式
- 集中式错误处理器：定义 ApiError 类，统一处理 ApiError、ZodError 校验错误与未知错误，返回统一 JSON 结构与状态码。
- 指数退避重试：fetchWithRetry 在失败时按 1s、2s、4s 延迟重试，最多指定次数。
认证与授权
- JWT 令牌校验：verifyToken 使用 jwt.verify 解析载荷，requireAuth 从 Authorization 头提取 Bearer Token。
- 基于角色的访问控制：定义角色到权限的映射（admin、moderator、user），通过 hasPermission 与 requirePermission 高阶函数包装处理器。
限流
- 限流必须使用共享存储，如 Redis、网关或平台原生限流器；不要在生产 API 中使用每进程内存计数器，因为它们在部署时重置、在多副本间分裂，并在无服务器或多实例环境中失效开放。后端层负责选择集成点与错误形态；HTTP 契约参考 api-design，滥用场景审查参考 security-review。
后台任务与队列
- 简单队列模式：JobQueue 类提供 add 与内部 process 循环，示例用于索引市场（IndexJob），API 路由将任务加入队列而非阻塞。
日志与监控
- 结构化日志：Logger 类输出包含 timestamp、level、message 及上下文的 JSON 日志，支持 info、warn、error，并可在请求中生成 requestId 关联日志。
使用方式
资料以代码示例形式展示各模式的实现，涵盖 TypeScript 接口、类与函数。开发者可按需参考对应模式的代码结构，将其应用到 Node.js、Express 或 Next.js API 路由项目中。示例涉及 Supabase、Redis、jsonwebtoken、zod 等库，但资料未提供安装命令或具体依赖版本。
适用场景
- 设计 REST 或 GraphQL API 端点
- 实现仓储、服务或控制器分层
- 优化数据库查询（N+1、索引、连接池）
- 添加缓存（Redis、内存、HTTP 缓存头）
- 设置后台任务或异步处理
- 组织 API 的错误处理与校验
- 构建中间件（认证、日志、限流）
限制
资料未提供该技能的安装方式、依赖版本、收费信息、平台支持范围或效果数据。限流部分明确要求使用共享存储，禁止在生产 API 中使用每进程内存计数器。资料末尾提示：后端模式用于实现可扩展、可维护的服务端应用，应选择适合自身复杂度级别的模式。