Интервью с Сергеем Жуком — автором книг и скринкастов по ReactPHP

    Мир IT полон интересных людей, что стало причиной создание проекта MoreView где я беру интервью у разных людей и познаю IT. Я достаточно давно связал свою жизнь с PHP и уже брал интервью у разработчика фреймворка Yii. Чуть более 7 лет назад в мир ворвался асинхронный PHP с библиотекой ReactPHP.


    7 лет прошло и технология продолжает развиваться. В этот раз я взял интервью у Сергея Жука (seregazhuk) — автора книг, статей и скринкастов по ReactPHP.



    Запись онлайн-трансляции интервью доступна на YouTube, аудио запись с самым важным можно послушать здесь а ниже представлена расшифровка интервью.


    Некоторые вопросы задавали гости трансляции и они помечены как (YouTube)


    Про Сергея


    Расскажи, чем ты сейчас занимаешься? Как ты оказался в IT?


    Меня зовут Жук Сергей, я backend разработчик в Skyeng. По поводу IT — со школы у меня была тяга к компьютерам. Еще в 10-11 классе я пытался что-то ковырять, покупал книжки и ничего в них не понимал. Пошел в профильный университет, отучился 5 лет, особо знаний оттуда не вынес и все уже забыл. Сразу после университета устроился разработчиком PHP и уже 10 лет не изменяю ему.


    (YouTube) Как программист ощутил ли ты изменения в связи с коронавирусом?


    Нет. Мое непосредственное руководство работало удаленно и до эпидемии. Так что в моей ситуации не изменилось ничего, процессы удалённой работы были уже хорошо отлажены.


    Чем занимаешься в Skyeng?



    Пишу backend для мобильных приложений, который агрегирует в себе все сервисы Skyeng — личный кабинет, биллинг, расписание. Мы все это прячем и отдаем нашим мобилкам.


    (YouTube) какие задачи в Skyeng решаются на PHP?


    В Skyeng на 99% все написано на PHP. Под капотом Symfony, Postgres, Rabbit, Redis.


    Давно работаешь в Skyeng? Все время удаленно?


    3 года уже, все время работаю удаленно. Один раз мы хотели всей командой поехать на конференцию в Сибирь. Как разработчика меня в офис не отправляли, как правило, отправляют лидов и это сильно зависит от команды.


    (YouTube) Как решаются асинхронные задачи в Skyeng если существующие PHP решения не готовы для production?


    Если нужна асинхронность, то мы используем Rabbit — кладем задачу и другой сервис её забирает. Мы недавно столкнулись с проблемой — на главном экране приложения много информации, которую мы собираем из разных сервисов. Мы не решились интегрировать ReactPHP и поставили асинхронный Guzzle.


    Как ты связался с ReactPHP?


    Жизнь заставила:) Был кейс — надо было реализовать звонилку и сократить время ожидания оператора. Проект был страшным легаси на PHP в виде долгоживущего CLI скрипта. Изучать NodeJS времени не было и мы нашли ReactPHP. По нему не было толком ничего — ни документации, ни примеров кода. Поковырялись в нем пару недель, написали, запустили и остались довольны результатами.


    Получив первый опыт ReactPHP ты двинулся в сторону его глубокого изучения?


    Глубоко в ReactPHP я погружался уже в свободное от работы времени. Было интересно и я отношусь к этому философски — асинхронный PHP это такая область, которую в мире ковыряют человек 30. Я погружаюсь туда и там океан непознанного. “Как можно из PHP, по сути, сделать NodeJS?”.


    (YouTube) Почему ReactPHP, а не Swoole или AMP?


    На тот момент ничего другого не было или было совсем в зародыше в умах людей, которые собирались это написать. Часто спорят, что Swoole — это расширение, больше похоже на GoLang, есть корутины и это круче. Примерно тоже самое говорят про AMPHP. Для меня более важна не красота кода, а сообщество. Если ты решаешь погружаться в асинхронный PHP, то сообщество будет для тебя играть решающую роль. Если столкнешься с нерешенной проблемой и ты обратишься к мейнтейнерам. В ReactPHP самое живое сообщество — они активно отвечают в твиттере и есть свой канал в Gitter


    Если у тебя продуктовая разработка и ты решился на асинхронный PHP, то в сложных ситуациях может получиться так, что ты создаешь issue на GitHub со срочной проблемой и неактивное сообщество может долго отвечать, а руководству не скажешь что: “Оно у нас не работает, потому что мне кто-то на вопрос не отвечает”.


    В феврале должна была пройти конференция по асинхронному PHP. Пригласили разработчиков AMP и Swoole. Разработчики AMP не отвечали ни по одному из возможных контактов в течении месяца. Я понимаю, что если я подключу в свой продукт AMP и у меня что-то не будет работать, меня могут игнорировать и мне придется отказываться от его использования.


    (YouTube) У тебя есть кроме ReactPHP какие-нибудь планы развития?


    Я думал больше погрузиться в развитие DriftPHP, чтобы была возможность написать высокоуровневые приложения на асинхронным PHP, используя под этим базу Symfony с его богатым сообществом. Сам ReactPHP очень низкоуровневый — я пробовал написать асинхронный клиент для memcached и это было крайне трудозатратно. Мне это не интересно, мне интересно писать бизнес-логику. Было бы здорово сделать production-ready фреймворк на асинхронном PHP.


    (YouTube) Хочется послушать про Брянское IT. Стоит ли оставаться и что делать если ты родился программистом в Брянске?


    Я особо не интересовался жизнью сообщества в Брянске. У нас была хорошая конференция кодишь.рф. Но это единственное мероприятие за 8 лет. Если сообщество будет развиваться, то я буду принимать участие в активностях, а создавать сам не стал бы.


    Про ReactPHP



    Если говорить об экосистеме, ты в курсе как появился ReactPHP?


    В 2019 году им исполнилось 7 лет. Начиналось всё с того, что Igor Wiedler решил попробовать что-то похоже на Event Loop на PHP. У него получилось — создали репозиторий и назвали его React (и он был до того, как появился React от Facebook). После выхода реакта от FB пришлось переименоваться в ReactPHP. Автор проекта его забросил, но появились новые ребята, которые начали активно его поддерживать.


    (YouTube) Сколько времени в среднем в день уделяется разработчиками на ReactPHP?


    У меня не такой информации. Насколько я общался с Кристианом Люком, у него есть спонсоры, которые ему платят деньги за разработку самого ReactPHP — так что, я думаю, он достаточно времени уделяет этому проекту и им это воспринимается как работа.


    Как получилось технически реализовать работу асинхронного PHP?


    PHP — блокирующий и основная идея в том, чтобы операции ввода-вывода отправить на выполнение операционной системе. Мы отдаем команду операционной системе, PHP не блокируется и выполняет дальше свои строчки кода. После выполнения операционная система вернет ответ и так мы обрабатываем все медленные операции ввода-вывода.


    В PHP сейчас есть низкоуровневый stream_select, которая позволяет эти операции выполнять в фоне — подписываться на события ОС и т.д. В ReactPHP реализовано несколько имплементаций цикла событий. Самый простой из коробки, который работает нативно — полноценный цикл событий, но вы можете упереться в лимит операционной системы. Также есть реализации на расширениях PHP, которые работают заметно быстрее. При запуске ReactPHP смотрит какие расширения в системе установлены и выбирает лучший вариант.


    В какую сторону ты бы советовал смотреть? Идти по нативному пути или ставить расширение ReactPHP если речь о новом проекте?


    Если речь идет о новом проекте, то я бы писал на NodeJs или GoLang:) С нуля я бы не стал писать на ReactPHP. Он уместен в ситуациях, когда уже есть какой-то PHP проект со своей командой, есть свой стек и добавлять в него другой язык тяжелее, чем вставить ReactPHP. Если нам нужная асинхронность с нуля, то лучше использовать Go.


    Но почему же тогда есть целая инфраструктура для ReactPHP, если не стоит его использовать для проекта с нуля?


    Это все больше Proof of concept. Если говорить о чистых ReactPHP компонентах, то это все достаточно низкоуровневые элементы. Не получится взять и сразу написать веб-приложение, так как там нет роутов, контроллеров. Придется с нуля писать всю инфраструктуру рядом, бизнес за это вряд ли будет платить.


    Получается какое-то количество людей работает над тем, чтобы можно было запускать проекты с нуля и это не имеет смысла для разработчиков? Зачем тогда в целом такая возможность?


    Насколько мне известно сообщество очень небольшое. Я общался с основным мейнтейнером — он делает свои проекты на ReactPHP. Если у него возникнут проблемы, то он сможет их решить и ему за это заплатят. Он писал систему для сбора информации для скорых и другие проекты, очень серьезные системы уже работают на ReactPHP. Но это речь о людях, которые имеют непосредственное отношение к коду. Все упирается в сообщество. В том же Symfony-сообществе, если ты создашь issue, то ты достаточно быстро получаешь обратную связь.


    В твоем твиттер-аккаунте ты Member of DriftPHP. Не противоречит ли существование DriftPHP тому, что ты говоришь?


    ![](


    Идея DriftPHP в том, чтобы натянуть Symfony поверх ReactPHP. Запускается асинхронный http-сервер на PHP, инициализируется Symfony kernel. Можно сказать, что мы получаем асинхронный Symfony. Но этот проект — Proof of concept. Разработчик этого фреймворка на сайте сам пишет, что не стоит использовать его в боевых условиях. Дело в том, что встроенные компоненты Symfony используют какие-то нативные функции РНР, которые, изначально, блокируют поток. Чтобы добавить компонент в свой фреймворк, ему надо просмотреть весь код компонента и убедиться, что код не блокирующий.


    Какое ты имеешь отношение к DriftPHP?


    Внутрь фреймворка мы подключили мой PHP Watcher. Мы решили интегрировать мою разработку внутрь фреймворка, чтобы упростить процесс разработки. Также я участвовал в интеграции DBAL — слой общения с БД. Сейчас можно в асинхронном Symfony ходить асинхронно в базу (поддерживаются Postgre, MySQL и SQLite). Так я стал частью команды DriftPHP.


    Если сравнивать устойчивость к нагрузке ReactPHP и стандартный стек с PHP-FPM — какие результаты бенчмарков? Если у нас будет простое приложение, отдающее “echo 1”, то какая будет разница?


    На ReactPHP будет работать быстрее даже через stream_select (без сторонних расширений). Но можно упереться в количество одновременных запросов — ОС в один момент не разрешит открыть еще один поток, чтобы писать данные. А если мы смотрим в сторону расширений PHP, то это будет еще быстрее.


    Почему бы не запускать приложение на RoadRunner для прироста скорости?


    Я не понимаю, почему меня постоянно спрашивают про RR — это разные вещи, как я вижу. ReactPHP предназначен для того, чтобы асинхронно обработать ввод-вывод, чтобы все тяжелые операции в PHP выполнялись асинхронно, а вычисления быстро. А RoadRunner это, по сути, про bootstrap — Symfony медленно стартует, мы погружаем его в RoadRunner и решаем эту проблему. Эти инструменты решают совершенно разные проблемы.


    Например, тебе нужно сделать сервис загрузки тяжелых файлов. На RoadRunner ты так и будешь записывать файл синхронно, а ReactPHP заберет 1000 параллельных загрузок и отдаст это ОС, которая уже будет обрабатывать загрузку файлов.


    Книги, Youtube и другое


    Как ты пришел к тому, что начал писать книги?


    Когда мы столкнулись с ReactPHP, информации по нему практически не было. Я набрался опыта и решили поделиться им. Получился список статей и я понял, что некоторым людям неудобно читать все по статьям. Я их собрал, адаптировал, чтобы была логическая связь и оформил в книгу. Опубликовал на Leanpub.


    Почему ты решил делать скринкасты по ReactPHP?



    Когда я изучаю новую технологию, то мне удобнее посмотреть видео — читать статью скучно. А с видео ситуация другая, мне гораздо больше зашёл формат, где открыта IDE и пишется код с пояснениями. Я взял свои статьи в качестве сценария, включил запись экрана и начал писать код и комментировать то, что я делаю. Сделать решил изначально на английском языке, чтобы охватить максимум аудитории


    Ты ранее говорил, что бессмысленно писать сервисы с нуля на ReactPHP, а сам даешь скринкасты по разработке REST API на ReactPHP. Зачем?



    Это все proof-of-concept. Посмотреть, можно ли такое сделать на ReactPHP — асинхронный сервер с интеграцией БД, загрузкой файлов, аутентификацией и другим. Все можно — в итоге получается сервер, написанный на PHP без Apache и Nginx.


    Сколько времени уходит на производство скринкастов?


    Уходит очень много времени. Сначала садишься и придумываешь идею — о чем хочешь рассказать в видео. После чего пишешь код и проверяешь — работает ли она. Изначально с REST API был фейл — в середине курса я понял, что я не могу сделать аутентификацию через токен. Я остановил курс и только спустя месяц понял, как это можно сделать и вернулся к проекту.


    Сначала записываю код, отдельно озвучиваю и монтирую. 1 минута видео ~ 1 час работы.


    Как родилась идея подкаста “Между Скобок”?



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


    Но интервью ты уже брал на английском языке. Например у Марка. Планируешь ли брать англоязычные интервью?


    У меня есть пара идей. Скорее всего это будет в рамках ютуба — буду раскрывать тему асинхронного PHP. У нас была идея записать серию интервью с мейнтейнером асинхронного PHP, но мы пока не дошли до реализации.


    Английский изучал целенаправленно?


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


    Ты в 2019 году выступил впервые. Зачем?


    Побороть страх публичных выступлений на реальной публике — мне до сих пор страшновато выступать. Мне очень понравилась движуха после выступления — это больше всего и цепляет.


    Какие дальше планы? Планируешь дальше в этом плане развиваться?


    Планы были грандиозные — были планы выступить в Барселоне, Дрездене и Амстердаме. Но в связи с текущей ситуацией я буду выступать только в Голландии и только онлайн.


    (YouTube) Планируешь писать книги еще?


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


    Заключение


    На этом закончилось наше интервью с Сергеем Жуком. Послушать аудио версию интервью и ознакомиться с полезными ссылками по теме можно здесь. Также можно прочитать про проект MoreView и посмотреть интервью с другими гостями.


    Следующее интервью будет в пятницу в 19.00. В гостях Роман Поборчий — тренер по публичным выступлениям.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 3

      0
      Есть же swoole
        0

        Да, сейчас в сообществе есть несколько популярных решений: Amp, ReactPHP и Swoole. Я свой выбор за ReactPHP сделал из-за максимально открытого и дружелюбного сообщества вокруг этого проекта.

        0
        сообщество у swolle, тоже очень открытое. Реагируют на issue github очень быстро. Посмотрите бенчмарки, посмотрите поддержку. В чём Реакт лучше час swoole

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое