Marco Pivetta – From helpers to middleware

Yoskaldyr

.
Партнер клуба
Длиннопост и немного баттхерта...

Я тут на днях посмотрел выступление Марко Пиветты

Хотелось бы обсудить выводы (само выступление разве что поржать, но лично мне интересен был конец с выводами). С одной стороны выводы очень красивые типа вообще не нужны DI контейнеры юзаем передачу всех параметров через конструкторы или аргументы методов и по факту получаем практически функциональное программирование (а если более точно то получаем True OOP то что активно пропагандирует Егор Бугаенко).
Все это хорошо на бумаге, и на небольших тестовых приложениях, но в реальном приложении получаем что абсолютно все зависимости, т.е. абсолютно все внутренности должны быть проинициализированы при старте приложения.
Пример (очень упрощенный):
PHP:
$route('/form')->pipe(
    new AuthMiddleware(),
    new CheckFormData(),
    new DomainMiddleWare(),
    new SomeOtherMiddleWare(new SomeDes(), new OtherDeps())
);
на практике же будет совсем другое (названия классов совсем и тоже очень упрощенно, реальное дерево зависимостей всегда глубже раз в 5 и разветвленнее, особено когда используются стратегия или подобные паттерны):
PHP:
$dbConnection = new DbConnection();
$config = new Config($dbConnection);

$route('/post-create')->pipe(
    new AuthMiddleware(new AuthProvider($config, $dbConnection)),
    new CheckFormData(new Form1Class(
           new FromDeps1( new FormDepsDeps ()),
           new FromDeps2($config)
    )),
    new DomainMiddleWare(),
    new SomePostMiddleWare(
           $config,
           new PostCreate(
                 new UserFactory($config),
                 new PostFactory(
                     new ThreadFactory(
                         new CategoryFactory($config),
                         $config),
                    $config),
                 new OtherDeps1(),
                 new OtherDeps2(),
    )
);
В современных фреймворках это все реализовано через DIC и по факту все это дерево зависимостей создается используя магию рефлексии в DIC, но Марко говорит - нафиг контейнеры лучше писать явно. Но в результате получается нечитаемая каша в одном месте инфраструктурные внутренности в перемешку с доменной логикой. И все равно это не решает одной из главных проблем - создания и инициализации всего до того как в действительности оно будет нужно
(а очень часто оно как раз и не нужно). И самый прикол что как раз Марко написал куча разных либ для облегчения тяжелой инициализации (тяжелая в плане времени выполнения, например, различные коннекты к БД, сокетам и т.д.) - разные прокси фабрики, constructorless фабрики, генерируемые фабрики, как раз чтобы избавится от тормозов тяжелых конструкторов до реального их использования класса. Но все это у него как раз и основано на магии и на неявном коде (типа делаем "явно" в одном месте, но делаем кучу магии в другом).

Т.е. с одной стороны все красиво в теории, но практике будет полная хрень. Я хочу заметить, что Марко предлагает полностью отказаться от DIC и передавать все зависимости явно (функциональный стиль). И это реально красиво, но только в теории или на очень небольших приложениях с минимальным деревом зависимостей :(
И как мне кажется, т.к. Марко - один из ведущих разработчиков в php коммьюнити, то с большой вероятностью подобные начинанию пойдуи проникать активно во фреймворки и т.д.

Лично я считаю что такой подход хорош для группирования больших структурных блоков приложения, а каждый блок уже сам решает как ему внутри создавать зависимые классы - хоть вообще без всяких контейнеров или магии - тупо через new. Для тестов в таких случаев есть softMocks и аналоги. Зато код получается в разы чище и читаемее. Хотя конечно это идет в разрез с "современными практиками".
Чтобы было понятно в примерах кода Марко как раз использует мидлвари как группировку верхнего уровня, но вот голосом говорит, что передавайте все зависимости явно, а не через DIC. Т.е. на слайде более менее красиво, на голосом советует немного другое...

И в завершении,
Вы все еще моете обычным порошком используете DIC? Если да, то Марко идет к вам!
 

jonjonson

Охренеть
Мой менеджер: Сделайте уже хоть как-нибудь!
Я про себя: Сделаю так, потому что это для меня проще.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@Yoskaldyr Так много слов ты написал по простому вопросу. С Марко понятно, так и надо выступать на конференциях, из личного опыта.
Давай не путать шоу и архитектуру. Низкоуровневая архитектура userland и фреймвоков имеет общего почти нисколько.
Чувак контрибьютит в доктрину и топит за свои либы - этот хохлосрач вечен, я сам в нем иногда участвую. Ты определи контекст - про userland с разовыми задачами, или про фреймвоки?
Если про userland - тут принцип простой. Когда я знаю, что реализация будет меняться - я делаю di, интерфейсы, все дела, если не уверен - прямой new в сервисном слое, типизация параметров по имени класса без интерфейса. Larvel продвигает идею интерфейса в каждой дырке - ну, за 20 лет мне лишняя гибкость ни разу не пригодилось.
Соответственно, в Оракле у меня на интерфейсах было почти все, DI в кастомном микроядре symfony с блекджеком и собственным логгером.
В стартапе - ничего.
 
Последнее редактирование:

Adelf

Administrator
Команда форума
Ну это я там заигрался с интерфейсами. В итоге выпилил их везде. Ларка вообще не принуждает к интерфейсам :)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
еще они фасады продвигают 🤪 аналогично лишняя сущность
 

Yoskaldyr

.
Партнер клуба
Ты определи контекст - про userland с разовыми задачами, или про фреймвоки?
Задача писать и поддерживать большой юзерленд и пофигу на каком фреймворке.
Чувак контрибьютит в доктрину и топит за свои либы
Проблема в том что это один из ведущих разработчиков в пхп коммьюнити и все что он говорит (даже полный бред) имеет вес - всегда найдутся последователи. Любое программерское коммьюнити это религия или секта со своими духовными лидерами и пророками.
И проблема как раз в том что у него на слайдах все красиво, но втирает немного другое... Наверное потому и бомбануло.
 

Adelf

Administrator
Команда форума
А по теме: ты прав. Никто не будет в здравом уме повторять весь конфиг из миддлварок для каждого роута. Я просто немного заларавеленный и у меня там обычно куча миддлварок подцеплено к каждому роуту плюс их очень удобно с помощью Route::group можно конфигурировать для групп роутов. Так что все эти фантазии хороши только для докладиков на конференциях.
 
Последнее редактирование:

Yoskaldyr

.
Партнер клуба
у него там вообще круче
firefox_2019-12-08_18-50-59.jpg
хотя по тексту это один роут только, а так типа сразу все приложение....
 

AmdY

Пью пиво
Команда форума
А по теме: ты прав. Никто не будет в здравом уме повторять весь конфиг из миддлварок для каждого роута. Я просто немного заларавеленный и у меня там обычно куча миддлварок подцеплено к каждому роуту плюс их очень удобно с помощью Route::group можно конфигурировать для групп роутов. Так что все эти фантазии хороши только для докладиков на конференциях.
так и пайпы можно объединять, как в laravel группы мидлварей. https://laravel.com/docs/master/middleware#middleware-groups не вижу особых проблем.
Единственное, почему $route('/form') роутинг же часть паплайна, причём для http и для cli он будет отличаться. Я на промотке глянул, вроде в докладе не было такого, это @Yoskaldyr придумал или я что-то важное промотал?
 

Yoskaldyr

.
Партнер клуба
@AmdY Я написал пример, т.к. перебивать все тупо. Потом дал скрин. По скрину видно что у него апп из одного экшена, я же в своих примерах с потолка сделал привязку к роуту, а не к приложению - да моя фантазия, но реального приложения из одного действия я не встречал.
И еще раз говорю по слайдам типа красиво, главное что он пытается впарить голосом...

P.S. Я ничего не имею против мидлварей, я против того чтобы вообще все внутренности и зависимости показывать и инициализировать на уровне роутов/бутстрапа приложения (а только так возможно с подходом что он втирает).
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Задача писать и поддерживать большой юзерленд и пофигу на каком фреймворке.
Это неправильная задача.
Проблема в том что это один из ведущих разработчиков в пхп коммьюнити и все что он говорит (даже полный бред) имеет вес - всегда найдутся последователи. Любое программерское коммьюнити это религия или секта со своими духовными лидерами и пророками.
И проблема как раз в том что у него на слайдах все красиво, но втирает немного другое... Наверное потому и бомбануло.
А это вообще не проблема. Его знает 0,0..01% разработчиков в мире. Скажи джависту или JS-нику, что автор доктрины предлагает не использовать DI. Секта?
Из доктрины я использовал только DBAL, и по возможности не планирую.
 

Yoskaldyr

.
Партнер клуба
@grigori я понимаю что ты любишь продвигать микросервисы, но не вся разработка состоит только из микросервисов.

Его знает 0,0..01% разработчиков в мире
Зато его знает большая часть пхп сообщества, особенно англоговорящая. Мы все-таки здесь пхп обсуждаем....
 

fixxxer

К.О.
Партнер клуба
1) DIC в этом примере никуда и не делся, просто его роль выполняет конфигурация мидлварей и из зависимостей. Очевидно, что в самих зависимостях в конструкторах указаны интерфейсы или абстрактные классы. Получился такой очень фиговый DIC с явным разрешением зависимостей в каждом месте, то есть маппинг FooInterface => Foo повторяется 100500 раз. Для совсем маленьких микросервисов может и нормально, но этот подход не масштабируется - с ростом объема этой конфигурации милдварей до неприличного сразу захочется делать фабрики, а там естественным образом появится DIC. То есть это такой шаг назад, на нем можно прекрасно продемонстрировать, зачем DIC нужен.
2) при упоминании Бугаенко можно сразу начинать ржать, это вообще удивительный пример действия принципа Питера.
 

Adelf

Administrator
Команда форума
2) при упоминании Бугаенко можно сразу начинать ржать, это вообще удивительный пример действия принципа Питера.
Егор икнул попивая смузи в своем домике в Сан-Франциско. "Опять вспоминают" подумал он и улыбнулся ласковому солнцу :)
 

fixxxer

К.О.
Партнер клуба
Смотрел последний сезон сериала Silicon Valley, где (спойлер) Big Head стал президентом Стенфорда? :)
 

Adelf

Administrator
Команда форума
Ага. Вчера. Вся серия хороший такой стеб )
 
Сверху