Так, фартаны. #ТоксикСреда. И новости подходящие :)

Пых: FrankenPHP переходит под крыло PHP!
Новость в блоге Саши Макарова

Не то, что это неожиданность, но давайте обсудим похейтим.

Какую проблему в PHP решали?

Пыхе нужен свой сервер со всеми современными свистоперделками (TLS, WebSockets, Early Hints, HTTP 1, 2, 3, 4g, 5g...). По понятным причинам FPM, как и встроенный dev-сервер, тут не подходят. Первый тупо менеджит воркеры и требует HTTP сервер типа nginx/angie, а второй не имеет свистоперделок.

Взяли франкен из-за Caddy. Получили свой сервер? Вообще, нет.
По мне, получили этакий костыль, который теперь будет отжирать внимание разработчиков ядра и, возможно, средства из фонда. Я бы не назвал это своим сервером. Просто нестабильный бридж на Caddy.
Знаю, что @samdark постоянно говорит, что у него франкен работает уже год, но не в воркер-режиме (т.е. как FPM), но стабильно. Если чутка подкопаться, то выяснится, что были кейсы с сегфолтами или отвалилось 50% статики. В общем тут вопрос терминологии:
- потерял запросы на сегфолте — нормально!
- "кадди отлетает наглухо при любом фризе скрипта" — нормально!
- отвалилась статика — тоже нормально!
Самый смак в том, что ты не можешь на это повлиять. Ведь причина не в высокой нагрузке, не в настройке окружения, не в ошибке в коде приложения. Тупо нестабильный сервер.

Какие были альтернативы?

Решил бы RoadRunner проблему? Нет. Он как бы в стороне, никому не мешает, и нет технической необходимости тащить его под крыло PHP, т.к. он не прибит к пыхе гвоздями.
Забавно, что RoadRunner — language-агностик решение, но решает проблемы именно пыхи.
Да и репозиториев много, переносить долго. В случае RR лучшим решением было бы сотрудничество или спонсирование, т.к. RR существует только в интересах PHP.

Если бы Swoole стал официальной частью пыхи, было бы интереснее. Родной сишный стек. Интероп нулевой. И RFC на TrueAsync был бы максимально в тему, т.к. половина костылей внутри свули отвалилась бы.
Походу, не договорились. Переход под крыло PHP означал бы и смещение контроля в сторону PHP. А там разброд: за RFC голосуют не только спецы, а вообще кто попало. Некоторые из них даже на PHP не пишут. Я бы на месте китайцев тоже отказался 🤔

Летом-осенью должно выйти решение от Angie (здесь могла быть Rapira) — такая же тесная интеграция в пыху, как франкен, но с более тонким и стабильным интеропом (не cgo). Но это часть продукта angie и под крыло PHP оно точно не ушло бы, ведь на нём скорее всего будет какая-то монетизация.
Выбирая себе сервер, между франкеном и Angie я бы выбрал Angie.

Выводы

Вот и получилось, что взяли на безрыбье. Зачем, если проблему не решили?
Набрать классов, набрать бета-тестеров, набрать спонсоров или из жалости.
Было бы неплохо, если бы Дунглас тащил франкен не в одно рыло, но я сомневаюсь, что это изменится.

Как итог: Дунглас становится лучшим инжектором костылей 21 века!
О да: Mercure, Франкен и воркараунды для файберов... да ещё и продавил это всё в массы.
Мой кумир! 😐

В нашей ламповой группе появился тред по охоте за головами (если ссылка не работает, то заходим сюда и клацаем 👨‍💻HR).

Последнее время всё чаще слышу от разработчиков, что они ищут работу.
Усугубляющие факторы:
- AI угрожает заменить всех разработчиков от мидла и ниже.
- Те разработчики, что выше мидла, неизбежно скуфеют. В PHP вообще остались одни старики. А эйджизм нынче популярен.

Работу я вам не предлагаю, но площадку для нытья — почему бы и нет? #ТоксикСреда всё-таки!

* В догонку к #ТоксикСреда

Преданный подписчик и фанат Нуно продолжает вести наблюдение.
Бранные слова заменил аналогами.

Ещё этот посмотрел и поржал.
он делает код ревью, х*** [проекта] на пять строчек и говорит "как же это классно, когда все классы разложены по типам по папочкам", типа модели в одной папочке, контроллеры — в другой. Зашел в модели и видишь все модели и понимаешь как приложение устроено.
Он еще своими экшенами подз*** [надоел].
Короче, это — не синьорное ревью, это — говноревью, где чел просто смотрит на код и сверяет его с тем, как в доке L*** [фреймворка для новичков]. Да это б*** [вообще] не ревью!

———

Вчера в перделке компетентные профессионалы вспомнили про хайповый нынче подход SOSAL. Из статьи:

Для меня название – это не самое важное в подходе, более важным критерием оценки является эффективность и возможность оптимизации процессов в команде. Были также предложены различные варианты названия, такие как LASSO и LASOS.

А ещё вчера по работе мне довелось поближе познакомиться с RAFT.
И как-то это всё сложилось в желание написать, что название — всегда важно.

Вот представьте:
🔥 Алгоритм назывался бы не RAFT, а FART. Тогда спеку читали бы через смех, но от того она и запомнилась бы лучше. FART over cluster.
🔥 Наш канал назывался бы PHP RAFT TIME. Да я бы сам от него отписался!
🔥 А Buggregator был бы, прости хоспаде, Ray Server или каким ни будь Error Catcher. Без изюминки и характера.

Было время переспать с мыслями по Yii3 App.
Хвалебных слов не будет, ибо #ТоксикСреда. Но ребята и так знают, что они молодцы 🫡
Мой технический разбор из двух частей в дополнение к стриму:

🖼️ Массивы уже не айс. Всё-таки времена PHP 7.4 позади.

Обратите внимание на то, что параметры (params) очень хорошо ложатся на DTOшки. DTOшки тоже хорошо сериализуются и десериализуются, кладутся куда угодно, версионируются по semver.
Бонусы очевидны: типизация, автокомплит, не надо знать "путь" до нужного конфига во всеобщем $params. В DTO также можно добавлять атрибуты для настройки мерж-планов или даже авторезолвинга альясов.

# Было
/**
 * @var array $params
 */
Foo::class => static function() use ($params): Foo {
    return new Foo($params['foo/bar']['option']);
}

# Стало
Foo::class => static function(FooConfig $config): Foo {
    return new Foo($config->option);
}

🖼️ Про кашу параметров и структуру: мы вынесли тезис, что в куче параметров чёрт ногу сломит. Хрен найдёшь то, что ищешь.
Однако, я знаю как этого избежать. Всё дело в структуре проекта!

Предлагаемая структура "как в Laravel" проклята. Группировка по типу классов, мол "тут контроллеры, тут хендлеры, тут ещё что-то", — тупиковый путь.
Вот если бы сразу сгруппировать по фичам или модулям, то что получится? Можно раскидать и перегруппировать не только контроллеры/сервисы/etc , но и параметры с конфигами DI.
Ребята, поработайте над структурой!

🖼️ Нельзя получить Request из контейнера: надо сначала получить RequestProvider, затем дёрнуть на нём метод get.

Оно понятно, почему так:
- Мало кто знает, но PSR контейнер по спеке должен быть идемпотентным: на один и тот же id возвращать всегда один и тот же результат. Там не предусмотрены non-singleton биндинги.
- А раз в контейнере всё синглтон, то реквест туда не положишь из-за его динамической натуры: в long running реквест будет каждый раз другой, также он может измениться в PSR мидлварях.

Но не понятно, почему платить за это должны разработчики. Как по мне, плата высокая.
Решить, кстати, эту проблему можно кучей разных доступных способов. Решайте! :)

🖼️ Чтобы уметь работать в неумираемом режиме, Yii опирается на два столпа: дедовские ресеттеры и иммутабельность. Ресеттеры полагаются на события PSR EventDispatcher.
Я доку не читал (а кто её вообще читает?), но надеюсь, что диспетчер событий не навязывается для использования в юзер-ленде.
И если ресеттеры — удел фреймворков, которые не смогли в архитектуру, и для исключительных случаев, то иммутабельность — очень хорошо. Я бы рекомендовал использовать больше иммутабельности и одноразовых объектов, чтобы стейты юзеров не текли, и им не приходилось писать ресеттеры, которые они всё равно писать не будут.
То, что мы видели на стриме мне не понравилось: стейт контроллера протекает. Да, я бы сам не писал такой код, но мы же говорим про фреймворк общего назначения уровня "домохозяйка+". Ну и напомню: если висит ружьё, то оно обязательно выстрелит.