Может войдёшь?
Черновики Написать статью Профиль

Статьи Demiurge

Laravel и ULID

В прошлой статье мы разобрались как в Laravel работать с UUID. Но он не решает всех проблем распределенных систем. Один из новых подходов к генерации уникальных идентификаторов это ULID — Universally Unique Lexicographically Sortable Identifier (универсальный уникальный лексографически сортируемый идентификатор).

Сравнение UUID и ULID

Во многих случаях использование UUID неоптимально:

  • Это не самый эффективный способ кодирования 128-битной случайности
  • UUID v1/v2 непрактичен во многих средах, так как требует доступа к уникальному стабильному MAC-адресу
  • UUID v3/v5 требует уникального начального числа и генерирует случайно распределенные идентификаторы, которые могут вызвать фрагментацию во многих структурах данных
  • UUID v4 не предоставляет никакой другой информации…

Eloquent и Blade: советы по повышению производительности

перевод Eloquent blade

Одна из самых распространенных проблем с производительностью, которую я видел в Laravel - это использование методов Eloquent и отношений из шаблонов Blade, создание ненужных дополнительных циклов и запросов. В этой статье я покажу различные сценарии и способы их эффективного использования.

Сценарий 1. Загрузка отношения belongsTo(): не забудьте про «жадную загрузку»

Типичный случай — вы перебираете записи через @foreach, и, в каком-то столбце, вам нужно показать родительскую запись с определенным полем.

@foreach ($sessions as $session)
<tr>
  <td>{{ $session->created_at }}</td>
  <td>{{ $session->user->name }}</td>
</tr>
@endforeach

И, конечно, Session принадлежит User, в app/Session.php :

public function user()
{
    return $this->belongsTo(User::class)…
artoodetoo

ИМХО, совершенно недопустимо изменять данные в Представлении. У кого-то может возникнуть такой соблазн, типа, для "оптимизации". Счётчик какой-нибудь посчитать и сохранить. Но не надо так делать! Потому что это портит логику и усложняет сопровождение.

Что же до "обращения к базе" в смысле операций чтения, в идеале да, они должны все происходить до обращения к Представлению. Но мы же сами добиваемся абстракции, когда чтение свойства объекта может неявно сопровождаться каким-то действием. Представление понятия не имеет делали мы eager loading или нет. Оно просто использует объект. Короче, врядли удастся избежать select в 100% случаев. По причине именно "объектности", "принципа чёрного ящика". Мы не всегда знаем как что-то работает внутри. Мы знаем только внешний эффект.

Недавно автор статьи Povilas опубликовал свой приём по внедрению данных в шаблон: через инъекцию сервиса (@inject), который рендерит свою вьюху и возвращает её как текст для вставки. Внутри такого сервиса очевидно будут операции с базой и как по мне это не очень страшно, если они не изменяют состояние.

Calculations in Blade, without violating MVC? Use Service Injection

← Назад | Дальше → Движется на Habravel