[Разработка веб-сайтов, PHP] Ты решил написать свой фреймворк. Стоило оно того?

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
03-Сен-2020 17:36

Цитировать

Как говорили классики, «я знал, что рано или поздно мы дойдем и до этого». Вот и я спустя много лет спокойной жизни с Symfony в рабочих и ReactPHP в пет-проектах вписался в создание своего фреймворка.
Но его история только начинается. А как было у тех, чье детище доросло до продакшн-уровня, но так и осталось нишевым решением? Я нашел человека, который знает ответ на этот вопрос — автора и ведущего разработчика аспектно-ориентированного фреймворка.
Привет! Перед вами частичная расшифровка моего подкаста «Между скобок» — интервью с интересными людьми из мира PHP. В этом выпуске поговорим с Александром Лисаченко, создателем фреймворка, основанного на идеях из Java, который часто гуглят гоферы.

Если вам удобней слушать — в аудиоверсии есть больше технических примеров.

Скорее всего, не все из нас сталкивались с такой вещью, как АОП — аспектно-ориентированное программирование в PHP. А Саша упоролся и сделал свое решение для втаскивания этой штуки в наши приложения.
Сергей Жук, Skyeng и DriftPHP: Давай начнём с азов — что такое АОП и какую проблему оно решает?
Александр Лисаченко, PHP Russia и Go! AOP: Идея не нова. АОП придумали в Xerox, чтобы решить проблему сквозной функциональности. И в мире Java подход активно используется, чтобы проверять такие функциональности, как авторизация, аутентификация, кэширование, логирование, управление feature toggle-ами, circuit breaker-ами.
Очень большой спектр задач можно решить с помощью аспектов. Давай на примерах:

Мы хотим сделать транзакцию. Перед началом надо написать, что мы в неё входим. Если она завершилась успешно, написать, что всё хорошо. Иначе — написать, что ошибка.
Другой пример — кэширование. Мы хотим проверить, есть ли у нас что-то в кэше. Если нет, то прогреваем кэш в методе, сохраняем что-то в кэш и потом возвращаем значение уже из него.
Профилирование: зачастую непонятно, что происходит внутри каждого конкретного респонса, приложение на проде начало тупить. А включать Xdebug — опасно или не дадут.
Еще одна хорошая и интересная возможность, которая реализуется с помощью аспектов — это circuit breaker, когда нам нужно проверять, что метод не падает, а если падает, то быстро его выключить и перестать ожидать ответ.

Если мы посмотрим на приложение, то увидим, что подобные участки кода попадаются везде и с этим не очень удобно работать. Это так называемая сквозная функциональность — она присутствует во всём приложении.
И нет никакого хорошего способа, чтобы её как-то вынести за скобки с помощью традиционного объектно-ориентированного программирования.
Да, конечно, мы можем попробовать взять декоратор — но если мы хотим, чтобы наш класс имплементил тот же самый интерфейс, необходимо реализовать или сгенерировать каждый метод прямо в декораторе. То есть, иметь декораторы под все классы, которые мы хотим закэшировать.
Сергей Жук: Ок, понял. Но для этого уже были какие-то PECL-расширения, фреймворк даже был. Почему ты решил написать свой?
Александр Лисаченко: Да, ты правильно заметил, — уже существовал ряд решений. Но, как мне показалось, они обладали значительными недостатками.
Часть решений пыталась трансформировать исходный код, сразу встроить в конкретный класс конкретный advice — участок кода, который повторяется из одного метода в другой. С помощью xlt они генерируют один класс и кладут туда абсолютно всё. В общем, этот код лучше не открывать совсем)
Второй класс решений — это экстеншены. Например, PHP AOP — он, в принципе, довольно функционален, но делает всё в runtime. Когда мы добавляем один advice, вроде как всё хорошо, но добавляем второй — и скорость начинает пропорционально уменьшаться. Соответственно, на десяти advice-ах приложение начинает подтормаживать, а если мы добавляем ещё пару десятков, всё — гарантирован timeout.
Как-то так сложилось, что я увидел, как в фреймворке Lithium была реализована идея под названием «фильтры» — такой прообраз современных middleware-ов. Мы создаём какие-то заранее известные точки в программе, и к этим точкам можно применять фильтры — как до вызова, так и после. Эта идея показалась настолько интересной, что я решил написать приложение и вынести сквозную функциональность с помощью этих фильтров. Начал изучать, как это сделано в Java.
И понял, что в PHP это с наскоку не удастся реализовать. То был, наверное, самый интересный момент.
В целом, весь процесс написания фреймворка был постоянной борьбой с «нельзя» и «невозможно». Казалось бы, я не мог реализовать фундаментальные вещи, но тем интереснее было с ними разобраться.
Сергей Жук: Я просто не могу не спросить. Почему Go AOP? Первый релиз фреймворка состоялся в начале 2013-го, язык Go тогда уже был, а у тебя PHP. Это чтобы было как с JavaScript и Java, да?)
Александр Лисаченко: Первый коммит не равняется началу локальной разработки на моём компе) В тот момент Go ещё не был популярен. Я погуглил, увидел, что есть какая-то внутренняя разработка Google, она занимает какую-то свою нишу… И не стал заморачиваться.
Само название фреймворка я выбрал, исходя из внутреннего, так сказать, пожелания. От go — «иди», «вперёд», «делай».
Сергей Жук: А переименовать потом не было мыслей?
Александр Лисаченко: Формально, полное название фреймворка Go! AOPPHP. Но со временем я убрал PHP, потому что это ставится через Composer и, кажется, нет смысла делать масло масляным.
Пока я получаю дополнительный трафик: многие, кто пытается найти АОП для Go, попадают на мой фреймворк для PHP. Возможно, в какой-то будущей версии придется сделать акцент, что это не про Go. Пока issue на GitHub-е на этот счет мне никто не заводил. Никаких претензий от Google или сообщества тоже не было.
Сергей Жук: Ок, а как это реализовано с точки зрения клиентского кода? Вот у меня есть приложение, например, на Laravel-е, есть пара интеграций со сторонними сервисами, я хочу эти вызовы логировать.
Александр Лисаченко: Под Laravel уже есть специальный модуль. Он поставит тебе всё необходимое в систему, настроит. Тебе необходимо будет написать аспект — это будет сервис, ты его протегируешь и он автоматически подхватится ядром АОП. В самом аспекте тебе необходимо понять, в каких точках приложения, в каких классах и методах ты хочешь реализовать функционал кэширования. Ты можешь указать метод прямо сигнатурой (но вариант не особо гибкий, потому метод можно переименовать, а в аспекте он останется), либо пометить метод аннотацией. Второй вариант более гибкий: там, где надо закэшировать, просто пометил cacheable, а движок за тебя сделает кэширование и вызовет callback, который находится в коде аспекта.
В момент загрузки твоего класса Composer-ом фреймворк вмешивается и проверяет, есть ли к этому классу готовая версия в кэше со встроенным аспектом. Если есть, он сразу её отдаёт, в runtime-е никаких проверок дополнительных не производится. Если же кэша нет, то мы построим AST-дерево, а поверх этого дерева создадим класс рефлекшена, но без его загрузки в память. И в этот момент мы сможем изменить его так, как хотим, то есть вплести код аспекта внутрь этого класса.
Я не люблю лапшекод внутри аспектов и решил делить класс на две части.
Оригинальный класс остаётся практически неизменным — меняется только название. И появляется второй класс с оригинальным названием класса, который экстендит тот основной и может при необходимости переопределить несколько методов.
Почему, собственно, наследование. Есть очень много методов и классов, которые возвращают instance обратно. Например, известный всем chain-метод: мы вызываем цепочку методов у объекта, он возвращает $this. Если мы задекорируем, то первый вызов он отработает, но вот дальше аспект отвалится. Заодно с наследованием экономится память — потому что instance в памяти по-прежнему один.
Сергей Жук: Вся эта архитектура, движок, — ты с самого начала все продумал или?
Александр Лисаченко: Было много вещей, в которые пришлось погружаться. Например, я не был хорошо знаком с AST, поэтому изучил много дисциплин, связанных с описанием грамматик. И если посмотреть на мой фреймворк, то pointcut у меня реализует полноценную грамматику и имеет свой синтаксис — это, наверное, одно из больших достижений. Можно написать сколько угодно сложные выражения, например, “вызов любого публичного метода, не начинающегося с asset, имплементирует интерфейс такой-то внутри space-а такого-то”.
Также я много копал внутрь PHP. Смотрел, где какие экстеншены, как они работают. Где-то сидел с профайлингом, что-то оптимизировал, тюнил: зато сейчас, если просто подключить АОП-фреймворк, приложению добавятся какие-то смешные 7-10 миллисекунд. На уровне классических 100 миллисекунд ответа даже незаметно, что вызывается подкапотно такой огромный фреймворк.
Сергей Жук: А есть специфика под разные PHP-фреймворки?
Александр Лисаченко: В принципе, АОП-фреймворк задумывался как общая библиотека, не требующая специфической обвязки. Основное условие — использовать Composer. Но вот с Symfony оно не очень дружит.
В Symfony слишком много чёрной магии, и когда она схлестывается с магией в моём фреймворке, побеждает сильнейший — Symfony.
В целом идея Symfony в том, что есть контейнер, надо им пользоваться и не изобретать отдельные фреймворки, чтобы получить функциональность АОП. Есть более традиционные способы: подключить бандл — скажем, JMS AOP или мой Symfony Go AOP bundle.
Сергей Жук: Давай поговорим про сообщество и конкурентов. Есть ли они у тебя?
Александр Лисаченко: Фреймворков, насколько мне известно, сейчас три. Есть Ray. Aop, но он не пригодится для продакшена, потому что не умеет эффективно работать с Composer-ом. Авторы Flow подают свой фреймворк под соусом, что у нас тут есть АОП. Есть еще что-то ещё рядом с китайскими фреймворками, поверх Swoole есть обвязки, — но это всё на уровне экстеншенов, а экстеншены могут админы по соображениям безопасности не пропустить. У меня всё-таки классический фреймворк, и он остаётся живым на любых версиях.
Что касается сообщества. Тех, кто разбирается и понимает хорошо, наверное, всего человека четыре: я, один парень из Сербии и два человека с моей бывшей работы, которые участвовали во всём том, что я делал. Я им показывал, естественно, все свои наработки, результаты. Последние пару месяцев, как я менял работу, вкладывал в open source очень мало сил и энергии, но оно живёт и работает автономно.
Возможно, кто-то знает мою другую библиотеку Z-Engine — c ней мы можем иметь доступ ко всем структурам в памяти, классам, методам и всему что угодно в PHP.
Я планирую, как только освободится время, продолжить работу над Z-Engine и сделаю следующую версию фреймворка, базирующуюся уже на внутренних структурах самого языка. Оно будет работать практически как джавовский AspectJ. Цель — прийти к этому к восьмой версии PHP.
Сергей Жук: Это же почти полностью переписывать фреймворк?
Александр Лисаченко: Нет, у меня всё декомпозировано. Изменяется только процесс внедрения кода: буквально несколько классов, которые отвечают за то, чтобы внести правки в конкретный класс. И в данном случае этот класс будет делать не файлики в кэше с разными структурами, а будет в этот момент в runtime-е изменять OPcache и модифицировать структуры PHP в памяти.
Сергей Жук: А какое вообще отношение PHP-сообщества к этой теме? Я вот увлекаюсь асинхронным PHP, он мало кого оставляет равнодушным. У тебя как с этим дела?
Александр Лисаченко: Всегда найдутся те, кто скажет, что мы можем это сделать и без АОП, зачем нам это в приложениях. Я отвечаю: если вы не работаете в энтерпрайзе, аспекты вам не пригодятся. И если вы считаете, что у вас энтерпрайз, но у вас один сервис и 2-3 разработчика, — вам тоже такое не подойдёт) АОП хорошо работает в командах, где есть несколько десятков человек, каждый из них пишет в своём стиле, есть, как правило, несколько приложений, и, как правило, микросервисная архитектура.
Я знаю точно, что есть ряд крупных компаний, которые используют фреймворк у себя: французские, российские. Бывает, на почту прилетают какие-то сообщения с благодарностями: мол, думали, нам на месяц работы, но раскопали твой фреймворк и за пару дней сделали ту задачу. Ребята месяц работы своих разработчиков сэкономили, это здорово.
Сергей Жук: А ты ведешь какую-то просветительскую деятельность? Фреймворк у тебя достаточно взрослый, но я бегло поискал туториалы — негусто. Кажется, спроси у десяти человек, что такое АОП, девять скажут, что не знают.
Александр Лисаченко: Да, верно.
Сергей Жук: Хотя, может, хорошо, что не знают?
Александр Лисаченко: Это спорный вопрос) Но есть проблема, которая у меня была и есть — это документация. Я по своей природе не люблю писать документацию. Могу написать крутые решения, могу изобретать какие-то необычные вещи, библиотеки, но с документацией — это прямо боль.
Мне даже в один момент друг из Сербии предлагал: давай напишем. И даже начал её писать, но через некоторое время запал тоже закончился… Так и получилось, что документацией не богаты, скажем так.
Сергей Жук: Получается, естественный отбор? Самые стойкие, кто залезли, поковырялись, те и юзают…
Александр Лисаченко: Да, и это те люди, которые имеют достаточный уровень, чтобы не накосячить.
Сергей Жук: А ты получал какой-то фидбек от людей, которые использовали фреймворк так, как ты бы не догадался?
Александр Лисаченко: Да, были такие кейсы. Например, Михаил Боднарчук, который написал AspectMock. Он взял фреймворк и понял, что с его помощью можно решить проблему моканья финальных методов, классов и даже функций.
Еще одну историю подкинули ребята, которые рефакторили старое приложение, и у них не было тестов — в общем, всё по классике. С помощью моего фреймворка они записали, с чем вызывается каждый конкретный метод, и сделали глобальный аспект. Перед вызовом всех публичных методов во всех классах в этой папке записывалось, что вызывается и с чем возвращается: какие типы, какие значения. Затем они начали это приложение гонять под нагрузкой, чтобы получить все возможные состояния кода. У них получился автоматический набор значений, допустимых для каждого из методов, и возвращаемые значения. То есть они заснепшотили всё состояние, а потом натравили обратный аспект, который вызывал метод и проверял, изменилась ли логика.
По сути, им удалось реализовать автоматический рефакторинг кода без покрытия его тестами.
Это была настолько крутая идея, что я какое-то время думал, как сделать инструмент для legacy-приложений, чтобы можно было все классы зафризить, посмотреть, с чем и как они вызываются, а потом при рефакторинге проверять, что существующие связи не нарушены. Но реализовать ее в каком-то инструменте, который можно было бы заопенсорсить, пока не получилось.
p.s. Спасибо, что дочитали и дослушали! Другие выпуски подкаста можно найти здесь.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_razrabotka_vebsajtov (Разработка веб-сайтов), #_php, #_php_podkast (php подкаст), #_aop, #_aspektnoe_programmirovanie (аспектное программирование), #_frejmvorki_php (фреймворки php), #_blog_kompanii_skyeng (
Блог компании Skyeng
), #_razrabotka_vebsajtov (
Разработка веб-сайтов
), #_php

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 17:24
Часовой пояс: UTC + 5