Интервью с Сергеем Жуком — автором книг и скринкастов по 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, который работает также на stream select, как ReactPHP из коробки.
Как ты связался с 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 и посмотреть интервью с другими гостями.
