intermediate

Validation

Валидируйте untrusted input на service boundaries через schemas, normalization, typed outputs и clear error responses.

Валидируйте весь недоверенный ввод на границе сервиса — body, query, params, headers — и отдавайте типизированные нормализованные значения для handler.

Библиотеки схем (Zod, Valibot, Joi, Ajv) парсят и приводят типы осознанно:

					const CreateOrder = z.object({
  sku: z.string().min(1),
  quantity: z.coerce.number().int().positive().max(100),
});

export async function createOrderHandler(req, res) {
  const parsed = CreateOrder.safeParse(req.body);
  if (!parsed.success) {
    return res.status(400).json({ errors: parsed.error.flatten() });
  }
  const order = await service.create(parsed.data);
  res.status(201).json(order);
}
				

Валидация ≠ авторизация: корректная форма не означает права на действие. 400 — неверный ввод, 422 — семантика, 401/403 — authz.

На интервью: где validation (controller vs domain); как не дублировать ограничения БД; единообразие ошибок.

Типовые ошибки: только body; доверие `Content-Type`; типы схемы как domain entity без маппинга.

Компромисс — между простотой, производительностью, безопасностью и эксплуатацией: назовите, что оптимизировали и какую цену приняли.

Чеклист:

  • Схемы рядом с маршрутом или OpenAPI.
  • safeParse на границе; throw в domain для инвариантов.
  • Нормализация один раз.
  • Отделите ошибки валидации от бизнес-правил.