Существует несколько "драйверов" для обработки этих broadcast событий

Основная идея: у нас есть событие (event) и мы хотим отправить его (broadcasting) куда-то наружу за пределы нашего Laravel приложения

Попробуем написать собственный broadcast driver, который делает post запрос на какой-то url

Подключаем наш собственный драйвер в конфиге

Есть некоторая неконсистентность в именовании: переменная окружения BROADCAST_DRIVER на самом деле ищет по массиву connections в конфиге broadcasting.php. В этом же конфиге используется термин driver, но это другое, никак не связанное с BROADCAST_DRIVER 🤯

Далее демо с вебсокетами на Laravel, но что-то пошло не так и зависло

Скоро выйдет laravel-websockets 2.0 - упор в горизонтальное масштабирование!

Далее по программе Understanding Foundation: What ties everything together
MIGUEL PIEDRAFITA
A deep dive into how the illuminate packages come together to create Laravel.

В начале психоделический слайд

Как работает auto discovery установленных пакетов: Laravel парсит файл installed.json (сформированный composer'ом) и ищет там пакеты помеченные extra Laravel

Фасады генерируются автоматически и сохраняются в storage/framework/cache

На этом прерываю трансляцию на сон. Как у меня появится доступ к видео записям, расскажу что там дальше было. По плану ещё два доклада: Doing small things with Livewire & Alpine и Laravel's Artisan Console component

Что если хочется в легаси приложении использовать удобные функции Laravel? Например, очереди? Рецепт: на лету создать инстанс Laravel приложения, забутстрапить его и теперь можно пользоваться удобными Laravel-очередями:

```
// Подготавливаем инстанс Laravel приложения
// путь к директории bootstrap с Laravel приложением может отличается,
// зависит от текущего .php файла
$laravelApp = require DIR . '/../../bootstrap/app.php';
$bootstrappers = [
LoadEnvironmentVariables::class,
LoadConfiguration::class,
HandleExceptions::class,
RegisterFacades::class,
SetRequestForConsole::class,
RegisterProviders::class,
BootProviders::class,
];
$laravelApp->bootstrapWith($bootstrappers);
$laravelApp->loadDeferredProviders();

// Запускаем Laravel Job находясь где-то посредине Legacy приложения!
MyJob::dispatch();
```

Подсмотрено в Телеграм чате «Пыхтелка»: фрагмент легаси кода с необычным использованием деструктора в исключении

Blackfire (достаточно удобный профилировщик) научился распознавать имена Blade шаблонов! Раньше показывал длинное имя скомпилированного файла шаблона, что было не удобно: http://amp.gs/cls0

Про Blackfire я рассказывал в одном из старых выпусков подкаста: http://amp.gs/cls3

Но с тех пор я отказался от платной подписки и лишь иногда пользуюсь ограниченными возможностями бесплатной версии. Сейчас в основном профилирую локально.

Рекомендую прочитать свежую статью про Fibers в PHP 8.1 от Christian Lück (один из разработчиков ReactPHP): http://amp.gs/cn9d

В статье много наглядных примеров и в целом читается легко.

Крис отвечает на несколько вопросов:
— Что такое Fibers в целом и какие особенности в PHP в частности
— Станет ли PHP асинхронным с появлением Fibers? (спойлер: нет, но приближают нас к этому)
— Какую проблему решают Fibers? (спойлер: косметически/синтаксическую, код будет немного проще писать и читать)
— Что насчёт Promises и async/await?
— Повлияет ли появление Fibers в PHP на проект
ReactPHP?
— А на какое влияние на PHP в целом?
— Framework X? http://amp.gs/cn9q

Также Крис упоминает легендарную статью "What Color is Your Function?" описывающую всю боль от асинхронного программирования, дам ссылку сразу на перевод на Хабре: http://amp.gs/cn9u

Классический способ публикации PHP проектов: имеем текущую версию кода в некоей директории директории /app/version1 и символическую ссылку /app/current -> /app/version1.

Настройки nginx таковы, что код запускается из /app/current (т.е. по символической ссылке).

Пришло время вложить новую версию: заливаем на сервер в директорию /app/version2 и после этого переключаем символическую ссылку /app/current -> /app/version2.

Атомарно? Не факт!

Есть несколько дополнительных факторов, которые нужно учитывать при деплое:
- OPCache
- realpath_cache
- А начиная с PHP 7.4 ещё и preload

И сразу возникают вопросы:
- Нужно ли делать сброс OPCache при такой схеме деплоя с двумя директориями и символической ссылкой? А если нужно, как это сделать правильно: php-fpm restart vs php-fpm reload vs gordalina/cachetool?
- Нужно ли сбрасывать realpath_cache или достаточно использовать $realpath_root в настройках nginx?
- Приводит ли php-fpm reload к сбросу realpath_cache?
- А если используем preload (PHP 7.4+), то выходит в любом случае придётся делать php-fpm reload? Или php-fpm restart?

Сознательно опускаю вопросы миграции базы данных и специфичные кеширующие механизмы тех или иных фреймворков.

Что рекомендую прочитать:

1. Не плохая статья-расследование с заголовком «Во всём виноват PHP OPCache?» http://amp.gs/cPeI
Спойлер: в этом случае OPCache не виноват, проблема была в realpath_cache

2. Подробности про работу realpath_cache: http://amp.gs/cPej

3. 5 способов деплоя PHP-кода в условиях хайлоада: http://amp.gs/cPeT
В этой статье специфика проекта, с которой вряд ли придётся столкнуться 99% разработчикам: «2 000 серверов, на которых 150 000 файлов объемом по 900 Мб PHP-кода и стейджинг-кластер на 50 машин». Однако написано хорошо и, безусловно, есть полезная информация и для разработчиков обычных, не столь нагруженных проектов.

После прочтения данной заметки, возможно, у вас появилось ещё больше вопросов, чем было! Будем разбираться дальше.