⚖️ whereHas() vs whereRelation() в Laravel

короче — не значит понятнее

Laravel-разработчики любят шорткаты. Меньше кода, меньше шума — приятно.
Но в реальных проектах с командой и постоянно меняющимися требованиями выигрывает ясность, а не длина строки.

Часто советуют заменить whereHas() на whereRelation():

// было
User::whereHas('profile', function ($q) {
    $q->where('is_verified', false);
})->get();

// стало
User::whereRelation('profile', 'is_verified', false)->get();

Формально — да, код короче.
Практически — не всё так радужно.

🧠 В чём реальная разница
whereHas() — явно про отношения

User::query()
    ->whereHas('profile', fn ($q) => $q->where('is_verified', false))
    ->get();

С первого взгляда понятно:

🔸фильтрация по relation

🔸логика живёт внутри профиля

🔸условия легко расширяются

🔸запрос честно отражает намерение

whereRelation() — скрывает сложность

User::whereRelation('profile', 'is_verified', false)->get();

Читается как фильтр по колонке users.
Но на деле — это подзапрос к связанной таблице.

❗️ Это вводит в заблуждение, особенно при чтении чужого кода.

🧩 Масштабирование условий

С whereHas() — естественно и прозрачно:

->whereHas('profile', fn ($q) => $q
    ->where('is_verified', false)
    ->whereNotNull('phone')
    ->where('age', '>', 18)
)

С whereRelation():

🔸либо цепочка вызовов

🔸либо возврат к whereHas()

🔸либо каша из стилей

🔍 Поиск и поддержка кода

Реальный кейс:

«Эндпоинт тормозит, ищем фильтрацию по отношениям»

whereHas() — легко найти поиском

whereRelation() — прячется среди обычных where

Для поддержки и отладки это критично.

⚙️ Производительность — миф

whereRelation() не быстрее.
Под капотом — тот же whereHas() и почти идентичный SQL.

Если медленно:

🔸нет индексов

🔸не тот подход к запросу

Метод тут ни при чём.

🧱 Проблема консистентности

Что происходит в проектах:

1. Сначала whereRelation() — «быстро и красиво»

2. Потом требования растут

3. Появляется whereHas()

4. В коде — два стиля без причины

5. В ревью — споры

Если сразу использовать whereHas():

🔸один паттерн

🔸единый стиль

🔸код готов к росту

🧠 Внутренности Laravel

Без магии:
whereRelation() — это обёртка над whereHas().
Не умнее. Не быстрее. Просто без closure.

📌 Правило на практике

Можно whereRelation(), если:

🔸один простой фильтр

🔸скрипт, отчёт, админка

🔸логика точно не вырастет

Лучше whereHas(), если:

🔸бизнес-логика

🔸командная разработка

🔸код придётся читать и менять

Экономия пары символов — плохой аргумент.
Пишите код для того, кто откроет файл через полгода.
В реальных проектах честный whereHas() почти всегда выигрывает.

👉 Ссылка на статью

Библиотека пхпшника

#элементарный_выбор

🔍 Can I PHP: проверяем доступность фичи налету

Расширение позволяет проверить доступность определенной функции/метода в различных версиях PHP и получить краткое описание возможностей.

👉 Сайт

#инструменты

How to: правильно обрабатывать ошибки валидации в Symfony

DTO + #[MapRequestPayload] в Symfony выглядят отлично.
Но ошибки валидации по умолчанию — шумные, разные по формату и неудобные для фронта.
Из-за этого часто появляются:
🔸 try/catch в контроллерах
🔸 дублирующийся маппинг ошибок
🔸 хаос в API-ответах

✅ Правильный подход
Пусть валидация падает сама, а форматирование ошибок происходит глобально, один раз.
Это решает Symfony Validation Response Bundle:
🔹 перехватывает ошибки из #[MapRequestPayload], #[MapQueryString], #[MapUploadedFile];
🔹 возвращает чистый JSON;
🔹 единый формат для всех эндпоинтов;
🔹 без логики в контроллерах.

🚀 Быстрый старт

composer require soleinjast/symfony-validation-response

Без конфигурации. Есть simple, RFC7807 и кастомные форматтеры.

👉 Подробный разбор и примеры — в статье.

Библиотека пхпшника