Решение проблемы N+1 запроса без увеличения потребления памяти в Laravel

В целом, я абсолютно согласен с вами, что «чистые» запросы, написанные руками почти всегда эффективнее, чем ORM. И критические участки почти всегда следует писать руками (и это мы еще не говорим про overhead самой ORM даже при условии генерации абсолютно одинаковых запросов).
Тем не менее, ORM придуманы тоже не от скуки и снимают очень много головной боли и добавляют удобства взаимодействия с кодом во многих случаях.
Поэтому использовать ORM или нет — всегда компромисс.

Конкретно выделенное вами на скриншоте — это издержки «автор использовал UUID в качестве идентификатора». Сама ORM конкретно к этому случаю не очень причастна и не сильно изменила ситуацию.

Из моего опыта, есть несколько категорий разработчиков (опускаем пограничные состояния и утрируем):
— те, кто работают только с ORM и даже не смотрят на конечные запросы (даже на их количество).
— те, кто работают с sql, особо не думая, какой он
— те, кто работают с ORM, но следят за запросами, критические участки переписывают на plain sql
— те, кто работают с sql и понимают почему именно. Как правило, это реальный highload, но таких проектов не так много и «к этому нужно прийти».

Вряд ли этой статьей я удивлю кого-то из последней категории, но вот ребятам из третьей категории может быть интересно.

Решение проблемы N+1 запроса без увеличения потребления памяти в Laravel

Спасибо за интересный комментарий.
Ограниченная жадная загрузка ограничивает всю выборку, а не выборку связанных данных.

Попробовал варианты подгрузки. Если использовать подобный скоуп:

$users = \App\User::with(['articles' => function ($query) {
        $query->orderBy('created_at', 'asc')
            ->limit(1);
    }])->get();

то генерируется примерно такой sql:

select * from `articles` where `articles`.`user_id` in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50) order by `created_at` asc limit 1

Что генерирует не верные данные. Без лимита смысла нет (туда только сортировка уходит, а количество загружаемых моделей остается таким же), whereColumn он не умеет. Навскидку, для этого нужно будет прокидывать либо join внутрь, либо subselect, что сведется к тому же подходу, только будет выглядеть более громоздко.

Если у вас получится, буду рад, если поделитесь решением и выводами.

Решение проблемы N+1 запроса без увеличения потребления памяти в Laravel

Да, в оригинале написан роутер, но Closure в роуте — это по сути анонимный контроллер. И этот же самый код будет справедлив, если его перенести в метод контроллера.

Вы считаете, что лучше оставить «роутер» и это будет понятнее?

Решение проблемы N+1 запроса без увеличения потребления памяти в Laravel

Аналогичные запросы генерирует ORM, если использовать Client::with('addresses') или $client->load('addresses') для вашего примера.
Проблема в следующем — если у вас у клиента 1 адрес, то проблемы точно нет и этот способ хороший и удобный. А если у вас в среднем на клиента может быть 100 адресов, то это уже будет проблема, так как запросов будет два, но объектов, которые загрузит система из БД, а затем превратит в ваши классы, будет очень много. Это все память + CPU на сериализацию / десериализацию.

Unit тестирование в Laravel

Спасибо за дополнение.
Я стараюсь не тестировать фреймворк своими тестами. Может быть и есть некоторый смысл в тестах состава полей в переменой fillable, но мне кажется это не оправданным.
У меня в моделях нет бизнес логики, я все выношу ее в сервисный слой. Поэтому сами модели у меня достаточно легкие.
Писать тесты на связи — можно, конечно, но зачем? У вас были случаи, когда эти тесты вам помогли? Тесты ради тестов или coverage никому не нужны.

Насчет стиля именования тестов.
Вам очевидно одно, мне другое. Авторы laracast и ряда пакетов используют snake_case, авторы Laravel и ряда пакетов следуют PSR-2 и используют camelCase. В каждой команде есть свой style-guide написания кода. Это вкусовщина, а моя статья о другом. Давайте не будем отвлекаться и спорить о вкусах.

Unit тестирование в Laravel

Подход TDD имеет место быть. Я делюсь своим опытом. У меня пока нет понятного опыта работы с TDD, но хочу попробовать в будущем детальнее посмотреть сюда.

Умение составлять тест-кейсы и задавать вопрос «что именно я хочу протестировать» помогает снизить риски пропустить ошибку. TDD подход не исключает этих рисков. Я бы даже добавил, что 100% coverage через TDD не является гарантией отсутствия багов.

Также рефактор кода во время написания тестов для меня является «нормальной» практикой. Я это делаю достаточно часто.

Unit тестирование в Laravel

Спасибо. Я согласен, что это не настоящие репозитории. По сути, я 2 Namespace использую. В один складываю бизнес логику и тестирую. В другой работу с Eloquent и не практически никогда не тестирую. Как раз поэтому я и сделал сноску о моей терминологии и что «академически» это не верно называть репозиториями.

Larabeer Moscow — 21 июня

Презентации есть на сайте. Пример, по которому я делал презентацию лежит тут. Лучше смотреть историю по коммитам. Разные слайды презентации соответствуют разным состояниям по коммитам.

Если есть вопросы по докладу или по теме, с радостью готов пообщаться.

Как развиваться руководителю разработки

Ох… только сегодня взял билеты в Спб вернуться. Чувствую нужно сдавать)
Отправил заявку

Конспект доклада «Что мы знаем о микросервисах» (HL2018, Avito, Вадим Мадисон)

В договоре на участие в конференции такой идеи не было

Очень странно принимать участие в таком обсуждении.

Но как правило хорошего тона — не распространять материалы до официальной публикации

На этот счет я отдельно спрашивал и получил разрешение и одобрение.

одно дело — обсуждение в кулуарах и с коллегами (в закрытом кругу)

А если с ними поделился, они потом никому не могут говорить?

Для меня знания — это источник света, вдохновения и роста, а для вас гриф секретности.
Мне действительно очень жаль, что вы считаете эту публикацию вредной.

Конспект доклада «Что мы знаем о микросервисах» (HL2018, Avito, Вадим Мадисон)

записи видео и презентации будут доступны через некоторое (не очень большое) время

Если вам так удобнее, можете пропустить и посмотреть исключительно видео или презентации. Лично мне такие конспекты помогают лучше понять доклад, запомнить основные мысли, отразить некоторые выводы для себя. Ну и потратить 10 минут на чтение тезисных моментов всегда проще, чем пересмотреть видео на 50 минут.
Изучение тезисов не отменяет, при желании, пересмотр видео (может быть даже не 1 раз).

А конспекты попахивают пиратством…

Не могли бы пояснить мысль?

Конспект доклада «Как стать классным спецом по бд» (HL2018, Data Egret, Илья Космодемьянский)

Я с опаской буду комментировать. Мое мнение, что важно и нужно владеть технологиями на стыке. Для БД (по крайней мере сейчас) реляционные отношения (они же тоже разные бывают) являются некоторой основной и вокруг них строится многое. Возможно, нереляционные БД не используют всех возможностей. А многие вещи необходимо реализовывать на уровне приложения, а не БД. Но знать это необходимо, если мы говорим о твердом базисе.
Иначе можно свести к «я только на ООП пишу код, поэтому про возможности других способов (функциональное, аспектное например) даже читать не буду». Вроде бы не верно это. Тема действительно холиварная, поэтому это исключительно мое IMHO.

Конспект доклада «Как стать классным спецом по бд» (HL2018, Data Egret, Илья Космодемьянский)

Название статьи сформировано по названию доклада.

А какой из перечисленных пунктов, на ваш взгляд, не подходит для «не реляционных» баз? Посмотрел еще раз список. Глаз не зацепился.

Конспект доклада «Как стать классным спецом по бд» (HL2018, Data Egret, Илья Космодемьянский)

Я гуглил в магазине по названию. Может быть есть переиздания. По своей ссылке увидел как минимум электронный вариант. Бумагу люблю больше, но электронная книга лучше, чем ничего.
По актуальности не подскажу, но я больше просто бэкенд-разработчик. С базами сталкиваюсь, естественно, но не так часто (и много), как DBA.

На доклад пошел, так как сам хочу подтянуть свои знания по БД. Ну и расширить кругозор.
Наверно, будет более правильно попробовать привлечь к обсуждению hydrobiont

Конспект доклада «Что мы знаем о микросервисах» (HL2018, Avito, Вадим Мадисон)

По п.2 — ходила такая мысль в кулуарах. Но тут было бы хорошо Вадима услышать.
На одном из слайдов презентации была графика с отображением всех сервисов и связями между ними. Из действительно много (но, да, это не говорит ничего о размере каждого).

Чего почитать для самообразования на выходных и не только

Можно на гит выложить.
Мне кажется очень удобно.

Пример подобного подхода: github.com/zualex/devmap/blob/master/README.md

Kivy. Xamarin. React Native. Три фреймворка — один эксперимент (часть 3)

Смотрели аналоги под vuejs (https://weex.apache.org например)? Интересно было бы ваше мнение услышать.

Наиболее востребованные языки программирования – 2018

А в выборке 1с точно слово «Битрикс» в его вариациях исключается? А то подозрительно часто встречается. Нет ли тут подвоха.

Как не надо разрабатывать проект на Битрикс

Не, не завезли. Также не завезли миграции, mvc, solid, очереди, адекватную событийную модель, присутствие нормальной документации (имеется ввиду актуальной и полной).
Скажу больше, судя по фичам последнего релиза, скоро начнут отвозить из существующего.

А как вы работаете с Laravel?

На самом же деле для небольших проектов достаточно ничего не мудрить,

А для больших как вы предлагаете? Статья описывает подходы для более-менее серьезных проектов. При создании лендинга на laravel эту часть, безусловно, можно пропустить.

И все это время читаю на разных форумах об архитектуре Laravel что Eloqent слабоват и не позваляет писать сложные запросы, красиво. На самом деле, решение простое, не писать сложные запросы, использовать простые связи, избегать вложенности и писать код с удовольствием. У вас много сложных запросов? Вы где то свернули не туда.

Разберитесь в разнице между подходами Active Record и Doctrine (Data Mapper, Gateway) и возможно вам станет понятнее.
Почитайте больше про паттерны.

не тратили время на изучение очередного модного архитектурного паттерна и пытались придумать свой велосипед

Если вы считаете, что паттерны, предлагаемые доктриной или подходы, описываемые в данной статье — это новый модный паттерн, то у меня для вас плохие новости.