Web Dev Talks: нам точно нужен фреймворк?

Вводные

Александр, часто критикуют PHP. Часто в сравнении с другими языками программирования. Особенно в сравнении с Python. С чем это может быть связано?

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

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

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

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

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

Как правило, PHP сегодня критикуют те, кто выбирал свой первый язык программирования в те давние времена, когда PHP был еще очень плох, а та же Java — уже взрослой. И все их представления о PHP отстали лет на 10, а то и больше.

А как на счет молодых программистов?

Молодые программисты продолжают критиковать PHP в основном по инерции. Возможно, в университете преподаватели нелестно отзывались о PHP, говорили, что Python или Ruby — наше все.

Где PHP проявляет себя лучше всего?

Современный PHP — отличный инструмент, но не для всех задач. Он прекрасно подходит для веб-разработки, прототипов и API. Если брать статистику, то по этим направлениям он является лидером. На PHP написано больше всего готовых инструментов именно под веб. Это различные CMS, CRM, вики-движки, форумные движки и так далее. Даже у компании, которая занимается исключительно Java, сайт, вероятно, будет сделан на WordPress.

А вот для машинного обучения и аналогичных задач PHP не очень подходит. Здесь принято использовать Python, C, Golang или Rust.

Какие бы вы назвали достоинства и недостатки PHP?

Если говорить в целом, то PHP выглядит очень не плохо рядом с другими языками программирования.

Под него есть мощные IDE, где можно эффективно работать. Те же PHPStorm и VSCode прекрасно PHP поддерживают. Не хуже, чем Java, во всяком случае.

У PHP есть строгая типизация. Есть дополнительный статический анализ, который примерно как в Python можно сверху навесить. Да, он не идет из коробки, но ставится за одну минуту поверх IDE.

В этом плане никаких проблем нет. Есть нюансы.

Во-первых, PHP плох и хорош одновременно порогом входа - с ним легко начать и даже что-то делать, имея минимальный опыт.

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

Кроме всего прочего, низкий порог входа объясняет, почему стили программирования серьезных и начинающих разработчиков сильно отличаются.

С другой стороны, перед бизнесом не всегда стоит задача построить что-то крутое и масштабное, что проживет 10 лет. Иногда нужно сделать просто, понятно, быстро и дешево. В отдельных случаях с использованием минимальных навыков в программировании. Например, какой-то прототип или MVP для стартапа. И для этих целей PHP отлично подходит.

Во-вторых, PHP плох и хорош одновременно своей моделью запуска.

Допустим, мы открываем в браузере какую-то страницу. Что происходит? Формируется соответствующий запрос от браузера на сервер, какая-то логика на сервере его отрабатывает, ответ отдается браузеру, после чего абсолютно все уничтожается. В следующий раз повторяется то же самое с самого начала. Так работает классический PHP.

Почему это плохо? Потому что производительность при этом не самая лучшая. Мы тратим время не только на само приложение, но и на поднятие окружения с нуля.

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

Здесь прослеживается тот самый эволюционный путь, когда условная команда разработчиков, которая взялась за проект на старте, изначально не задумывается о том, что через год его надо будет масштабировать. Как обычно бывает? Если прилетел в работу PHP проект, в паре мест его правят, выводят в продакшн, а когда нагрузка растет, вкладываются в сервера. И в этом случае, как правило, на то, чтобы выстрелил MVP или бизнес в моменте выдержал какую-нибудь супер масштабную акцию, сильно много времени не затрачивается.

Наконец, по производительности PHP не так крут, как компилируемые языки. На том же Golang можно написать код, который будет обрабатывать гораздо больше запросов и выдавать больше ответов в секунду, чем PHP. Для последнего это минус, да. Но Golang сложнее и не такой выразительный, а значит и квалификация программистов, пишущих на нем, должна быть выше, что увеличивает трудозатраты. Поэтому большие проекты на Golang гораздо дороже делать.

Есть же тесты, где PHP в сравнении с другими языками программирования быстрее?

Да, есть. Если мы берем интерпретируемые языки, такие как Python, PHP, Ruby, Lua и другие, то вопреки всем слухам PHP в последних версиях самый быстрый из них. Все дело в Дмитрии Стогове и Никите Попове, которые несколько лет назад замечательно все оптимизировали, и дошли до того, что PHP стал, пожалуй, самым быстрым интерпретируемым языком.

Это классно, но все равно он не дотягивает до того, что компилируется.

Programming Language Benchmark v2 (plb2) оценивает производительность 25 языков программирования для четырех задач, интенсивно использующих CPU. Реализации для тестовых задач основаны на одних и тех же алгоритмах. Задачи заключаются в следующем:

• nqueens: решение задачи расстановки 15-ферзей (включает в себя вложенные циклы и целочисленные битовые операции);
• matmul: умножение двух квадратных матриц размером 1500х1500;
• sudoku: решение 4000 сложных судоку (20 головоломок повторяются по 200 раз) с использованием алгоритма Кудоку;
• bedcov: определение пересечений двух массивов из 1 000 000 интервалов.

На самом деле самая большая проблема даже не в этом. Если мы возьмем софт на Python, то он вполне может давать больше запросов в секунду, чем PHP. Не потому, что он быстрее работает. Python, как правило, медленнее. Дело в том, что фреймворки на Python написаны иначе, они не инициализируются при каждом запуске.

В PHP, кстати, появились способы делать так же, что положительно сказывается на производительности. К сожалению, пока это не получило повсеместного распространения.

Когда выбирать PHP?

PHP подходит для решения практически любых задач, разве что не для «молотилок данных». Бизнес должен исходить из своих потребностей и имеющихся ресурсов.

Для веб-разработки, для API, будь то корпоративный сайт, интернет-магазин, CRM или что-то подобное, PHP отлично подходит. Если бизнес хочет проверить гипотезу, разработать прототип или быстрое готовое решение, причем, сделать это относительно недорого, то также подойдет PHP.

В Big Data, Machine Learning и других подобных сферах лучше брать какие-нибудь языки типа Golang или Python.

Можно сказать, что PHP — мастхэв для веба?

Пожалуй, нет. То, что умеет PHP, можно и на других языках сделать. PHP - один из вариантов. И это хороший вариант.

Почему?

Во-первых, PHP-разработчиков много. Есть рынок, где их можно нанять.

Во-вторых, по PHP существует огромное количество самой разной документации.

В-третьих, сообщество PHP одно из самых дружелюбных из всех. Если founder или команда стартапа решили программировать свой продукт самостоятельно, но у них есть пробелы в соответствующих навыках, то PHP для них — отличный выбор. Им проще будет вкатиться. Но если они с этим же багажом знаний придут в сообщество Java и спросят там что-нибудь, то единственное, что им скажут — идите, почитайте книжек.

Вопрос выбора

Что такое фреймворк и для чего он нужен?

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

Плюс у фреймворков есть документация. То есть понятно, как с ним работать. Это позволяет менее болезненно менять команду разработчиков.

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

Фреймворк — это такой каркас.

Чистый PHP или фреймворк? Так вопрос может стоять?

Может. Чистый PHP будет работать быстрее, чем фреймворк. Если только мы внутри этого чистого PHP не будем писать свой фреймворк, а сделаем все просто. В таком случае у нас будет меньше кода, он будет проще, он не будет отрабатывать все варианты использования, а будет делать только то, что задумывалось. И это будет работать в разы быстрее.

Для случаев, когда нужно что-то очень быстро «отдать», чистый PHP подходит очень неплохо.

Также чистый PHP подходит, если какое-то программное решение нужно запустить в течение короткого периода времени. Например, идет какая-нибудь акция, надо небольшую цифровую геймификацию запустить, и мы точно знаем, что по завершении акции все можно будет удалить.

Это вопросы поддержки, когда первоначально небольшое приложение обрастает кодом, а возможно еще и не задокументированным кодом?

Да, верно. То, что приложение обросло кодом с различными костылями — это большой технический долг. И нам придется его отдать.

То, что мы взяли сразу фреймворк, тоже в какой-то степени технический долг, так как мы притащили достаточно сложное решение для простой задачи.

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

Хорошо. CMS или фреймворк?

Как бы банально это не звучало, но бизнес должен оценивать масштаб и содержание задачи, которая перед ним стоит, и использовать для ее решения соответствующие инструменты.

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

CMS представляет собой готовое шаблонное решение, которое позволяет со сравнительно небольшими затратами запустить стандартный корпоративный сайт или типовой интернет-магазин. Фреймворк требует более существенных вложений в разработку, но дает намного больше возможностей для реализации адаптированного под процессы компании продукта: того же интернет-магазина или веб-приложения.

CMS за вас решает, как вам работать с пользователями, с контентом, сам определяет структуру проекта, затрагивает бизнес-логику, процессы, под которые часто бизнесу приходится подстраиваться, о самой структуре бизнеса предположения делает, правда, не всегда правильно, имеет ограничение по функционалу, но предлагает платные или бесплатные плагины для его добавления. И все выше перечисленное доступно из коробки. С одной стороны, это хорошо, так как мы можем быстро запустить проект. С другой стороны — не очень хорошо, потому что, скорее всего, авторы CMS имеют свое представление о том, как все должно работать. Если ваше видение на 99% совпадает с их видением, то вам очень повезло, вы сэкономили много времени и денег, CMS идеально впишется в ваш бизнес. Если же нет, ждите беды, так как задачи, которые на фреймворке или на чистом PHP делаются за условные две минуты, на CMS будут выполняться по два дня.

В отличие от CMS, фреймворки почти не имеют ограничений в расширении функциональности. Фреймворки обладают более четкой структурой и много тестируются авторами и сообществом, что позволяет разработчикам лучше контролировать код, обеспечивать его качество и надежность, создавать масштабируемые проекты. Фреймворки также позволяют создавать веб-сервисы с более высокой производительностью и безопасностью.

Сам фреймворк может стать ограничением?

Да. Фреймворк, как я говорил, одной из своих задач ставит ограничение разработчиков от неосторожных действий, то есть не позволяет им делать то, что может погубить продукт.

Дело в том, что создатели фреймворка — ребята обычно опытные, работавшие над разными сложными и не очень проектами, поэтому они знают, что если вот «так» делать, то последствия для проекта будут плачевные. Даже несмотря на то, что «так» сделать проще, быстрее и удобнее. И для того, чтобы таких ситуаций было меньше, они эти ограничения в фреймворки и внедряют.

Таким образом, в фреймворках ограничения немного другого плана, не как у CMS. Здесь вряд ли будет жесткое ограничение того, «как делать». Здесь ограничения, скорее, связаны с тем, «что не делать» или «как не делать».

Ограничения в фреймворке более низкого уровня. Они не лезут непосредственно в бизнес и его процессы, в то, как вы авторизуетесь, как храните контент. Проще говоря, то, что специфично для бизнеса, они не трогают. Но они трогают все специфичное для инфраструктуры: как вы входите в базу данных, как запрашиваете чужие API и так далее.

Подведем итог. Нам точно нужен фреймворк?

Нам нужен фреймворк в большинстве случаев, в том числе, если у нас нет много-много времени и желания собирать свой, писать к нему документацию и потом поддерживать его. Если есть, то тут уже вопрос. Нужно считать, что выгоднее.

При всех его достоинствах, нам не всегда нужен фреймворк — это точно.

Нам не нужен фреймворк, если у нас небольшой проект.

Нам не нужен фреймворк, если мы хотим проверить гипотезу и запустить какой-то прототип. Особенно, если точно знаем, что будем его переписывать.

Нам не нужен фреймворк, если у нас какой-нибудь хобби проект. Допустим, доработка умного дома, чтобы какая-то особенная история там происходила.

Есть случаи, когда фреймворк мешает. Как правило, фреймворк нам мешает там, где мы упираемся в его производительность, либо делаем что-то супер нестандартное. В последнем случае надо понимать, что фреймворки заточены на какие-то более-менее стандартные вещи, когда прилетает классический запрос, с ним на сервере что-то происходит, возвращается ответ.

Про скорость и качество разработки.

На фреймворке, естественно, разработка идет быстрее, потому что фреймворк дает готовые блоки, из которых можно собирать полноценное веб-приложение. Иными словами, не надо писать много нового кода каждый раз, когда запускаешь новый продукт. Но это актуально, если команда разработчиков знакома с фреймворком. Если не знакома, то, естественно, процесс пойдет медленнее, так как придется учиться. Но как только обучение завершиться, темпы разработки возрастут. Фреймворк однозначно быстрее.

Качество разработки с использованием фреймворка тоже лучше. Нам не надо заново писать его код, так как он уже написан. Этот написанный код обычно выкладывается в open source, его просматривает куча разных компаний и программистов. Они его погоняли на куче разных сценариев. Он, вероятно, покрыт тестами. И ошибки из него давно вычистили. Не всегда, но чаще всего так и есть. Иными словами, на этот код можно полагаться и не волноваться, что что-то сломается или произойдет какая-то неприятная неожиданность.

PHP-фреймворки

Какие фреймворки сегодня актуальны?

На разных языках есть разные фреймворки. Если мы возьмем Java, то это Spring — достаточно известный фреймворк. На Python — это Django. На Ruby — Rails. На PHP несколько больших хороших фреймворков — Symfony, Laravel, Yii. Есть еще микрофреймворки типа Slim — тоже неплохие.

PHP-фреймворки каким-то образом отличаются от конкурентов, написанных на других языках программирования?

Задачи они решают примерно одинаковые. Способы решения чуть разные: отличается стиль, отличаются подходы. Где-то возможностей больше, где-то - меньше. В общем, фреймворки все похожи.

Александр, вы занимаетесь непосредственно Yii. Давайте на его примере разберем особенности PHP-фреймворков?

Если мы говорим про актуальную версию, то это пока еще Yii2. Его релиз состоялся в 2014 году. Это достаточно серьезный период для фреймворка — 10 лет. Yii2, скажем так, немного отстал по каким-то современным практикам, так как мы его не сильно меняли за это время. Да, что-то доделывали, некоторые части ломали и переделывали, но прямо радикально не меняли. Но он все еще сохраняет свою актуальность и по-прежнему используется в Enterprise проектах.

И с учетом возраста Yii2 продолжает сохранять некоторые особенности.

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

Он внутри простой, то есть его код легко читать.

Мы задокументировали практически все его компоненты. Комментарии также есть и в самом коде. Они не просто указывают на то, что делает та или иная конструкция, но и объяснют, для чего она нужна, какой в ней смысл. В итоге с ним приятно работать.

По возможностям.

Из уникального, наверное, назову генерацию кода, которая есть и в других фреймворках, но в Yii2 она действительно хороша. С ее помощью можно те же панели администратора делать за очень короткое время.

Опять же, вспомню про систему расширений, про Active Record и отличный слой для работы с базой, поддерживающий, в том числе, MSSQL и Oracle со всеми их особенностями.

Если сравнить Yii2 и Laravel, что вы можете сказать?

Как и все фреймворки, они похожи.

Laravel в целом неплох. У него есть свой набор плюсов и минусов, хоть и достаточно разбалансированный.

В Laravel есть интеграции практически под все, наверное, что вообще существует. Прототипы на нем делать классно. Когда берешь ту же Kafka, под нее точно будет и драйвер, и все остальное.

Сообщество у Laravel большое и достаточно приветливое — приятно находиться у них.

Очень много маркетинга — это и плюс, и минус. Плюс в том, что сообщество растет, а минус — оно стало походить на культ. То есть ребята забывают посмотреть по сторонам и ругают все остальное, говорят, что Laravel — единственная крутая вещь, которая только есть. Иными словами, Laravel собирает вокруг себя адептов Laravel, замыкаясь в себе.

Если брать Yii2 и Laravel, с точки зрения бизнеса можно провести какую-то линию, например, тут лучше использовать Laravel, а тут — Yii.

Очень сложно. Они рядом стоят. Здесь, скорее всего, вопрос команды, вкуса, каких-то начальных навыков, а также предпочтений исходя из того, кто и с чем работал. В итоге либо то, либо другое, либо вообще третье – бизнесу надо отталкиваться от задач и имеющихся вводных.

Если у вас есть проект и есть команда, которая ранее работала с Yii2 и только немного щупала Laravel, вывод очевиден: брать Yii2. Так и время сэкономите, и деньги будут целее. Если же у вас команда, которая всю жизнь работала с Laravel, то без веских причин лучше и не менять его.

Говоря о Yii2, не могу не вспомнить о долгожданной Yii3. Известно, что работа над новой версией идет уже давно и буквально в ближайшее время планируется релиз. Что в новой версии было переработано?

Все.

Фреймворк Yii3

Yii – это высокопроизводительный компонентный PHP фреймворк, предназначенный для быстрой разработки современных веб-приложений. Слово Yii [ji:] в китайском языке означает «простой и эволюционирующий». Также Yii может расшифровываться как акроним Yes It Is!

Подробнее

Тогда давайте по порядку.

Yii3 — проект амбициозный. В нем более ста пакетов. Некоторые пакеты очень большие. Работая над этим проектом, мы некоторым моментам уделяли особо пристальное внимание. Для начала мы сделали его строгим. Yii3 действительно очень строгий в плане того, что фреймворк не позволяет делать очевидно плохо.

Yii3 покрыт тестами на 100%, то есть он очень надежный. И вот это 100% покрытие тестами – это, наверное, единственное, что позволяет столь небольшой команде управляться с большим проектом. Если бы этого покрытия не было, то, скорее всего, он бы умер. В общем, это было хорошим решением. Замедлило оно нас очень сильно, но зато позволило завершить проект.

Такое покрытие тестами - это даже что-то про технический экстремизм (смеется).

Вы сейчас как раз эту дилемму озвучили: тратить время на покрытие тестами или нет. Некоторые до сих пор считают, мол, чем тесты писать, лучше напишу код, нам надо быстрее в продакшн выходить, гипотезу тестировать и так далее.

Да, но это до первой выкладки в продакшн. Естественно, код с тестами дольше пишется, а вот все, что потом, с тестами гораздо быстрее и уверенней, и меньше сюрпризов для команды разработчиков, а для бизнеса меньше потерь денег. Тесты — они оправдывают себя.

Вернемся к Yii3. Что еще из нового вы хотели бы озвучить?

Yii3 открыт всему PHP, он не замыкается в себе как Laravel или Yii2. Иными словами, в третьей версии нет той инфраструктуры, которая обитает отдельно от PHP. Компоненты фреймворка можно тащить в PHP-шный чистый проект, также в фреймворк можно свободно тащить любую библиотеку из PHP, и она отлично впишется.

Давайте об этом подробнее.

Если брать те же Laravel и Yii2, там фреймворк строит свой программный API. Внутри этого API есть свои конфигурации, которые работают только со своими компонентами. Система запроса-ответа, опять же, специфична для таких фреймворков. И все, что написано не для этих фреймворков, оно там по умолчанию не работает. Таким образом, нам надо на каждую библиотеку писать свой мост или адаптер. У какого-то фреймворка это может называться плагинами, у какого-то - экстеншенами или бандлами. Таким образом, фреймворк обрастает ими, а также сообществом их создателей. Это, в общем-то, здорово, но за пределами фреймворка все эти интеграции никому не нужны.

Мы решили сознательно от этого уйти. И это была одна из глобальных наших целей: отсутствие необходимости писать бесконечные прослойки. Чтобы можно было брать любой PHP-код или код, написанный по PSR-стандартам, и чтобы он сразу отлично работал.

Пожалуй, нам это удалось.

Есть ли что-то еще о Yii3?

Да, мы не только в вопросах тестирования занялись «техническим экстремизмом», но и в вопросах наследования. Мы сознательно от него отказались. Практически везде. Запретили его.

Наследование в университетах преподается как часть трех китов ООП, рассказывается про его важность, но на самом деле наследование — не очень хорошая штука.

Почему не очень хорошая штука?

Потому что наследование очень часто используют не по назначению. Не делают иерархии такие, которые в наследование впишутся. Наследуют как-то странно, как мы в Yii2 когда-то сделали. Сейчас понимаю, что это было ошибкой. Классной, рабочей, но ошибкой: мы ввели базовый объект, от которого наследуется вообще все. И это очень сильно отделило фреймворк от PHP в целом, потому что фреймворк начал на самом базовом уровне работать несколько иначе.

Наследование порождает достаточно много проблем. Например, связанность. Связанность плоха тем, что на пользовательском уровне она вызывает падение проекта в каком-то неожиданном месте, хотя код мы правили совсем в другом. Мы от этого в Yii3 максимально отходим сами и ограждаем пользователей.

Мы также запретили сервис-локаторы, которые обеспечивают доступ к ядру фреймворка из любого места в коде. В Yii3 мы сделали так, что если вам что-то нужно, например, получить кэш, то вы просите интерфейс в конструкторе своего класса.

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

Есть и цена за это. Чуть сложнее писать код, чуть выше требуется квалификация от разработчика. Но когда пару месяцев работаешь, все встает на свои места: скорость разработки выходит на прежний уровень, а иногда и улучшеается.

Обратная совместимость с Yii2 будет?

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

И все же, если с Yii2 мы хотим перейти на Yii3, нужно переписывать?

Скорее, да, придется переделывать весь проект. Я бы не стал, потому что Yii2 будет поддерживаться еще достаточно долго. Более того, сейчас ребята хотят сделать промежуточную Yii2.2 версию. Я не знаю, получится или нет, но у них команда сформировалась из сообщества Yii2, и они намереваются притащить в свою версию часть компонентов Yii3. Я туда захожу иногда, смотрю, что они делают. В общем, интересно.

Вы в этой команде участие принимаете?

Я в основном сосредоточен на Yii3.

Вот то, о чем вы говорите, — это общий тренд в современных фреймворках?

Частично - общий тренд, частично — уникальная особенность именно Yii.

Отказ от сервис-локатора, инверсия зависимостей — плюс-минус общий тренд. Жесткий отказ от наследования — не везде, но тоже имеет место. Такая же, как у Yii3 строгость покрытия тестами, чтобы на 100%, — это, пожалуй, уникально, хотя в целом проблема достаточно известная, и в других фреймворках ей по возможности уделяют внимание. Полное следование PSR — можно назвать фишкой Yii3, потому что частично фреймворки это реализовывают, но не все.

Как фреймворки проявляют себя в высоконагруженных проектах?

Я уже затрагивал, что горизонтальное масштабирование в PHP идет из коробки. Когда у нас становятся прям очень высокие нагрузки, все начинает упираться вообще не в фреймворк, а в то, как мы храним данные, в нашу инфраструктуру и так далее. В фреймворк — в последнюю очередь.

Но когда уже фреймворк начинает не справляться, или если проект больше не про хранение данных, а про какую-то очень сложную их обработку, то чаще PHP меняют на более производительные языки типа Golang или Rust. Также часто на PHP оставляют только логику, потому что логика в PHP укладывается отменно, а вот затратную обработку данных выносят в отдельные микросервисы, которые пишутся на других более производительных языках.

Пожалуй, гибрид PHP и Go — это популярная тема сейчас.

Как раз про микросервисы хотел вопрос задать. Микросервисы и PHP-фреймворки «совместимы»?

Можно писать микросервисы на PHP-фреймворках, никто не мешает. Но лучше не брать для этого тяжелые фреймворки с тяжелой инициализацией. К таким фреймворкам сегодня можно отнести Laravel и, в меньшей степени, Symfony.

Ах, как хочется вернуться, ворваться в монолит!

Кейс «Авито», в котором рассказывается, как монолитное PHP приложение компании шло к микросервисам.

Подробнее

Если возможно, то используйте либо чистый PHP, либо Slim, либо Yii3. Yii3 в данном случае хорош тем, что у него очень легкий «бутстрап», а компоненты можно поставить частично, чтобы не грузилось лишнее.

Какие-то можете назвать популярные Enterprise решения, которые работают на PHP и на PHP-фреймворках?

На самом деле много компаний выросло на PHP.

ВК на PHP вырос. Позже они сделали свой интерпретатор, но внутри все еще PHP. Это как раз тот случай, когда нужна супер производительность, а они не захотели ни на Go, ни на что-то еще идти, остались на PHP.

Мессенджер Slack на PHP был изначально написан. Они по тем же причинам, связанным с нагрузками, перешли на интерпретатор от Facebook, который, кстати, тоже разработан на PHP.

Магазины DNS на PHP прекрасно работают. Как раз Yii2 у них внутри, если я не ошибаюсь.

Несколько аэропортов сюда же. Например, аэропорт Казани бегает на Yii2. Тоже интересный факт.

Если брать большие проекты, то их много, мы знаем не про все.

PHP - это также много разных CMS и CMF: WordPress, Bitrix, Drupal и другие. Наверное, WordPress — это максимум вообще проектов, которые есть на PHP.

Безопасность

Александр, есть актуальные угрозы безопасности, характерные именно для PHP?

Угрозы специфичные для какого-то языка — они всегда есть. В PHP супер специфично, наверное, из-за того, что он интерпретируемый, – это все, что касается сериализации. Через нее можно код выполнить, если быть очень неосторожным в кодировании. Есть в самом PHP дыры, потому что он написан на C. Например, связанные с переполнением памяти.

В остальном я бы не сказал, что прямо что-то такое особенное есть. Ребята из PHP-foundation фиксят очень оперативно, если что-то обнаруживается.

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

Либо же это будет просто взлом инфраструктуры. Например, SSH сломают, еще что-нибудь такое.

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

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

Да, ибо на 100% защититься не получиться. Если человек поставит себе задачу сломать что-нибудь, он это сломает.

Даже если мы напишем идеальное решение на фреймворке или на чистом языке, причем, неважно на каком именно, всегда есть сервер, всегда есть операционная система, всегда есть железо.

Приведу пример с игровыми приставками Xbox. У них реализована отличная защита. Но умельцы-электронщики, у которых было очень много времени, каждый вечер экспериментировали и поняли, что если в момент инициализации системы на процессор, на его ножки, подать сигналы какой-то определенной последовательности, то его начинает глючить, и он позволяет обходить все свои защиты. Но это было в рамках хобби сделано и в течение очень долгого времени. Каким-то условным интернет-магазином маловероятно, что так заниматься будут.

Можно PHP назвать безопасным языком?

Безопасным языком? Вполне, да. В этом он не хуже других языков программирования, таких как Python.

И возвращаясь в начало, но в контексте этого разговора: native или фреймворк?

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

Так что проект на фреймворке гораздо безопаснее, чем на чистом PHP.