PHP и не Highload приложение
Нужно обосновать выбор PHP для разработки следующего проекта - информационная веб система, в которой будет 30-40 пользователей, одновременно активных штук 7 (то есть работают одновременно штук 7, а авторизированы почти все). Один человек предложил обосновать выбор так "PHP так как пишем не HighLoad приложение". Но почему конкретно PHP "хорош" в разработке не highload приложений? (по идее такая информационная система будет же являться не хайлоад?)
Ответы (1 шт):
На PHP у вас есть возможность очень быстро насобирать MVP функционал, абстрагироваться от написания бойлерплейта и сконцентрироваться на доменной логике. Пара фреймворков, которые снизят головную боль и ускорят разработку в разу: Symfony, Laravel. Если взять Symfony, то несравнимый + это Doctrine ORM, такого мало где можно найти с аналогичным кол-вом сахара.
Доступность человеческих ресурсов + не сильно высокий порог вхождения. PHP занимает очень крупный процент в WEB-е, соответственно, проблем с кадрами быть не должно и заменить тоже в пределах реального. Так же, данный язык довольно прост для понимания, что позволит нанять более низкоквалифицированного разработчика, но который уже сможет потянуть поддержание и доработку функционала.
Нельзя конечно сказать, что на PHP не пишут Highload, т.к. нынче у вас Nginx, FPM, JIT, perloading, асихрон (RebbitMQ/Apach Kafka) и подобные плюшки доступны, т.е., можно потянуть порядочные нагрузки. Но в контексте высокой нагрузки, часто требуют скорость отклика в пределах каких-то цифр + держать RPS на постоянном уровне, вот тут, уже есть смысл задуматься.
Так же, грех не сказать, что хорошо работает с HTTP протоколом, нативно разбирает данные из запроса в суперглобальные массивы, что облегчает реализацию Rest-a допустим.
Куча репозиториев и либ, которые помогут в работе с нетривиальными вещами, собрать ZIP, распарсить Xlsx, обработать и снизить качество видео, интегрироваться с разными платежными системами и т.д, и т.п.
P.S. Пыху очень давно и упорно точат под то, чтоб быстро и качественно собирать более или менее тривиальные дешбоарды и т.д., в таком случае, нужно смотреть на необходимость в дальнейшем поддерживать систему, расширять и дорабатывать на долгом промежутке времени.