При разработке любого программного продукта перед командой разработчиков прежде всего стоит задача грамотного выбора программной платформы, определяющей структуру программной системы.
Для этого нужно учесть достаточно большое количество характеристик, от «как быстро всё будет работать» до «а необходима ли нам эта фича?». И так каждый раз. Именно в моменты мозгового штурма команда сравнивает удобство фреймворка, скорость, набор фич, которые реализованы в нем или в совместимых с ним модулях.
Но какой же всё-таки лучше, быстрее и производительнее?
Разработчики постоянно проводят сравнение фреймворков, чтобы прояснить для себя этот вопрос. Например, в статье Lukasz Kujawa приведено сравнение PHP фреймворков. Одно «но» - статья за 2013 год. А ведь время идёт… Поэтому мы решили провести своё, актуальное сравнение фреймворков.
Для оценки производительности был использован PHP Framework Benchmark . Он предлагает для сравнения множество фреймворков (не только указанных выше), но автор не спешит добавлять в репозиторий новые версии проектов, что, конечно же, печально, хотя и не смертельно. При желании добавить новую версию не сложно.
Одной из основных целей данной статьи также является попытка практическим путем определить улучшения в производительности и эффективности новых версий PHP. Поэтому тестирование было проведено на РНР 5.6/7.0/7.1
Что будем сравнивать?
Для сравнения были выбраны следующие фреймворки:- slim-3.0
- ci-3.0
- lumen-5.1
- yii-2.0
- silex-1.3
- fuel-1.8
- phpixie-3.2
- zf-2.5
- zf-3.0
- symfony-2.7
- symfony-3.0
- laravel-5.3
- laravel-5.4
- bluz (версия 7.0.0 - для РНР5.6 и версия 7.4 для РНР7.0 и выше)
- ze-1.0
- phalcon-3.0
- производительность (throughput),
- занимаемая память (memory),
- время выполнения (exec time),
- количество подключаемых файлов (included files).
Методика тестирования и тестовый стенд
Машина, на которой производилось тестирование, обладает следующими характеристиками:Operation system: Linux Mint 17 Cinnamon 64-bit
Cinnamin Version 2.2.16
Linux Kernel: 3.13.0-24-generic
Processor: Intel Core i3-4160 CPU 3.60 Ghz X 2
Memory: 8 GB
Server version: Apache/2.4.7 (ubuntu)
Server build: Jul 15 2016
php 7.1 / php7.0 / php5.6
Вводим команду git clone https://github.com/kenjis/php-framework-benchmark - и фрейм уже на нашей машине. Поскольку мы использовали Mint, необходимо выполнить настройку:
# Added net.netfilter.nf_conntrack_max = 100000 net.nf_conntrack_max = 100000 net.ipv4.tcp_max_tw_buckets = 180000 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 10
Sudo sysctl -p
Немного о структуре самого php-framework-benchmark:
/benchmarks - содержит bash-скрипты, отвечающие за сбор информации о количестве запросов в секунду (при помощи утилиты ab), количестве информации, сколько времени было потрачено и сколько файлов вызывалось из файла «точки старта».
/lib - директория, в которой находятся файлы, отвечающие за обработку полученной информации после вывода страницы “Hello world”, вывод таблиц с результатами и построение диаграмм.
/output - директория, в которую добавляются логи после выполнения тестирования. Здесь находится по два файла для каждого протестированного файла: .ab.log - лог после работы утилиты ab, и.output - содержит информацию, которая была выведена на экран (обычно это hello world и данные по памяти, времени выполнения, использовавшимся файлам).
Остальные папки - это заготовки фреймов, в которые уже добавлен один контроллер, который вернет строку “hello world” при обращении по URI, составленному по правилам обращения к данному фреймворку.
Для запуска теста сначала нужно настроить фреймворки. Рассмотрим два подхода.
Команда bash setup.sh настроит те фремворки, которые описаны в файле list.sh. Вы можете его редактировать: добавлять и удалять папки для тестирования. То есть конфигурировать так, как вам необходимо.
Командой bash setup.sh fatfree-3.5/ slim-3.0/ lumen-5.1/ silex-1.3/ вы можете установить какие-то отдельные фреймворки, задав их параметрами к команде. В некоторых случаях это удобно, но мы использовали первый подход.
После произведенной настройки фреймворков, мы запустили тестирование при помощи bash benchmark.sh .
По окончании работы в терминале появилась таблица со списком протестированных фреймворков, количеством запросов в секунду, относительным значением, занимаемой памятью, а также относительными значениями этих показателей.
Для отображения графиков мы воспользовались ссылкой http://localhost/php-framework-benchmark/ .
Как вы понимаете, необходимо было произвести настройку Apache и заставить его смотреть в папку с фреймом. Всё это описано в readme, поэтому вопросов не возникает.
Результаты тестирования фреймворков
Каждый раздел имеет структуру, состоящую из двух форм представления результатов.Первая форма - это наглядный тип представления. Каждая характеристика содержит 4 диаграммы. Каждая диаграмма отображает сравнение фреймворков между собой, плюс накопительная диаграмма. Она была построена при использовании определенной версии РНР. Таким образом можно проследить эволюцию улучшений в PHP и фреймворках.
Вторая форма - это результат тестирования в виде таблицы (хватить наглядности, давайте говорить серьезно - дайте мне больше чисел!).
Производительность (throughput)
Применительно к нашей ситуации, характеристика throughput измеряется в количестве запросов, которые наш фреймворк может обработать в течении секунды. Следовательно, чем выше это число, тем более производительно наше приложение, поскольку оно сможет корректно обрабатывать запросы большого количества пользователей.Мы получили следующие результаты (запросы в секунду):
| php 5.6 | php 7.0 | php 7.1 | |
|---|---|---|---|
| phalcon-3.1.2 | 5058.00 | 5130.00 | 7535.00 |
| ci-3.0 | 2943.55 | 4116.31 | 4998.05 |
| slim-3.0 | 2074.59 | 3143.94 | 3681.00 |
| yii-2.0 | 1256.31 | 2276.37 | 2664.61 |
| silex-1.3 | 1401.92 | 2263.90 | 2576.22 |
| lumen-5.1 | 1316.46 | 2384.24 | 2741.81 |
| ze-1.0 | 1181.14 | 1989.99 | 1741.81 |
| phpixie-3.2 | 898.63 | 1677.15 | 1896.23 |
| fuel-1.8 | 1044.77 | 1646.67 | 1770.13 |
| bluz-7.3.1 | - * | 1774.00 | 1890.00 |
| zf-2.5 | 198.66 | 623.71 | 739.12 |
| zf-3.0 | 447.88 | 1012.57 | 1197.26 |
| symfony-2.7 | 360.03 | 873.40 | 989.57 |
| symfony-3.0 | 372.19 | 853.51 | 1022.28 |
| laravel-5.3 | 258.62 | 346.25 | 625.99 |
| laravel-5.4 | 219.82 | 413.49 | 600.42 |
Для наглядности построили графики для каждой версии PHP:
PHP5.6:
PHP7.0:
PHP7.1:
Занимаемая память (peak memory)
Эта характеристика (в мегабайтах) отвечает за количество занимаемой фреймворком памяти при выполнении поставленной перед ним задачи. Чем меньше данное число, тем лучше для нас и для сервера:| php 5.6 | php 7.0 | php 7.1 | |
|---|---|---|---|
| phalcon-3.1.2 | 0.27 | 0.38 | 0.37 |
| ci-3.0 | 0.42 | 0.38 | 0.38 |
| slim-3.0 | 0.61 | 0.55 | 0.55 |
| yii-2.0 | 1.31 | 0.91 | 0.91 |
| silex-1.3 | 0.74 | 0.65 | 0.65 |
| lumen-5.1 | 0.80 | 0.63 | 0.63 |
| ze-1.0 | 0.79 | 0.56 | 0.56 |
| phpixie-3.2 | 1.22 | 0.82 | 0.82 |
| fuel-1.8 | 0.7 | 0.6 | 0.6 |
| bluz-7.3.1 | - * | 0.69 | 0.69 |
| zf-2.5 | 3.06 | 1.34 | 1.34 |
| zf-3.0 | 2.12 | 1.09 | 1.08 |
| symfony-2.7 | 3.11 | 1.41 | 1.42 |
| symfony-3.0 | 2.86 | 1.30 | 1.32 |
| laravel-5.3 | 2.91 | 2.04 | 2.04 |
| laravel-5.4 | 3.04 | 1.45 | 1.49 |
* - bluz-7.3.1 не поддерживает php 5.6
PHP 5.6:
PHP 7.0:
PHP 7.1:
Сводная накопительная диаграмма (по фреймворкам):
Время выполнения
Время выполнения - время, затрачиваемое системой для выполнения поставленной задачи. Измеряется от начала выполнения задачи до выдачи результата системой.
Мы рассмотрели, сколько запросов в секунду может обработать фреймворк, сколько памяти он при этом занимает. Теперь рассмотрим, сколько нам нужно ожидать, чтобы получить ответ от сервера. Чем ниже это значение, тем лучше для нас , да и для нервной системы клиента нашего приложения.
Время приведено в миллисекундах (ms):
| php 5.6 | php 7.0 | php 7.1 | |
|---|---|---|---|
| phalcon-3.1.2 | 1.300 | 1.470 | 1.080 |
| ci-3.0 | 0.996 | 0.818 | 1.007 |
| slim-3.0 | 1.530 | 1.228 | 0.662 |
| yii-2.0 | 1.478 | 1.410 | 1.639 |
| silex-1.3 | 4.657 | 1.625 | 2.681 |
| lumen-5.1 | 2.121 | 1.829 | 1.228 |
| ze-1.0 | 2.629 | 2.069 | 1.528 |
| phpixie-3.2 | 9.329 | 4.757 | 1.911 |
| fuel-1.8 | 3.283 | 2.684 | 1.425 |
| bluz-7.3.1 | - * | 1.619 | 1.921 |
| zf-2.5 | 22.042 | 5.011 | 3.998 |
| zf-3.0 | 12.680 | 2.506 | 2.989 |
| symfony-2.7 | 6.529 | 3.902 | 2.384 |
| symfony-3.0 | 9.335 | 3.987 | 2.820 |
| laravel-5.3 | 19.885 | 4.840 | 2.622 |
| laravel-5.4 | 19.561 | 4.758 | 3.940 |
PHP 5.6:
PHP 7.0:
PHP 7.1:
Сводная накопительная диаграмма (по фреймворкам):
Подключаемые файлы
Характеристика, отвечающая за количество подключаемых файлов, которые описаны в файле «точки входа» фреймворка. Понятно, что система тратит какое-то время на поиск и подключение. Следовательно, чем меньше файлов, тем быстрее будет осуществляться первый запуск приложения, так как обычно в последующие разы фреймворк работает с кэшем, что ускоряет работу:| phalcon-3.1.2 | 5 |
| ci-3.0 | 26 |
| slim-3.0 | 53 |
| yii-2.0 | 46 |
| silex-1.3 | 63 |
| lumen-5.1 | 37 |
| ze-1.0 | 68 |
| phpixie-3.2 | 163 |
| fuel-1.8 | 53 |
| bluz-7.3.1 | 95 |
| zf-2.5 | 222 |
| zf-3.0 | 188 |
| symfony-2.7 | 110 |
| symfony-3.0 | 192 |
| laravel-5.3 | 38 |
| laravel-5.4 | 176 |
Разница в количестве подключаемых файлов между Laravel 5.3 и Laravel 5.4 может показаться странной и дать повод к обсуждениям, спорам и т.п. Спешим разъяснить ситуацию. Как вы знаете, с помощью команды
Php artisan optimize --force
В Laravel 5.3 можно сгенерировать файл compiled.php, и тем самым уменьшить количество подключаемых файлов, собрав их в один. Но есть одно «но»: команды для генерации этого файла в Laravel 5.4 больше нет. Разработчик решил удалить эту фичу, так как посчитал (https://github.com/laravel/framework/pull/17003), что для настройки производительности лучше использовать opcache.
Стоит ли обновляться?
Сводные данные по версиям более чем наглядно показывают, какой произойдет прирост производительности и эффективности использования ресурсов при переходе (или изначальном выборе) на новую версию PHP.При переходе с PHP 5.6 на PHP 7.0 средний прирост производительности составил почти +90%, при этом минимальный прирост производительности составил +33% для Laravel 5.3, а максимум - >200% для Zend Framework 2.5.
Переход с версии 7.0 на 7.1 уже не так шокирует, но всё же в среднем даёт почти 20% прирост производительности.
Сведя все полученные данные по производительности различных версий PHP, получим вот такие «матрасы»:
Забавный факт
: Laravel 5.3 показал наименьший прирост производительности при миграции с PHP 5.6 на PHP 7.0, но при этом наибольший прирост при миграции с версии 7.0 на версию 7.1, и как итог - производительность Laravel 5.3 и 5.4 на PHP 7.1 практически одинакова.
Потребление памяти тоже оптимизировали, так что переход с PHP 5.6 на PHP 7.0 позволит вашему приложению потреблять на 30% меньшем памяти.
Обновление с версии 7.0 до версии 7.1 практически не даёт прироста, а в последних Symfony и Laravel так и вовсе уходим в «минус», потому что они начинают чуть больше «кушать».
Осталось ещё посмотреть на время выполнения, и да, тут тоже всё отлично:
- переезд с PHP 5.6 на PHP 7.0 подарит вам ускорение в среднем на 44%.
- переезд с PHP 7.0 на PHP 7.1 подарит вам ускорение ещё на 14%.
Примечание. Тестирование при помощи ab - с чем мы столкнулись
«А что со slim и phpixie» - этот вопрос подтолкнул на расследование поведения утилиты ab при взаимодействии с этими фреймворками.
Выполним тест отдельно для Slim-3.0:
Ab -c 10 -t 3 http://localhost/php-framework-benchmark/slim-3.0/index.php/hello/index
Concurrency Level: 10
Time taken for tests: 5.005 seconds
Complete requests: 2
Failed requests: 0
Total transferred: 1800 bytes
HTML transferred: 330 bytes
Requests per second: 0.40 [#/sec] (mean)
Time per request: 25024.485 (mean)
Time per request: 2502.448 (mean, across all concurrent requests)
Transfer rate: 0.35 received
Что-то не так - количество запросов в секунду всего 0.4 (!)
Ab -c 10 -t 3 http://localhost/php-framework-benchmark/laravel-5.4/public/index.php/hello/index
Concurrency Level: 10
Time taken for tests: 3.004 seconds
Complete requests: 1961
Failed requests: 0
Total transferred: 1995682 bytes
HTML transferred: 66708 bytes
Requests per second: 652.86 [#/sec] (mean)
Time per request: 15.317 (mean)
Time per request: 1.532 (mean, across all concurrent requests)
Transfer rate: 648.83 received
Дело было в Keep Alive соединении, подробнее можно узнать тут.
“When you make requests with «Connection: keep-alive» the subsequent request to the server will use the same TCP connection. This is called HTTP persistent connection. This helps in reduction CPU load on server side and improves latency/response time.If a request is made with «Connection: close» this indicates that once the request has been made the server needs to close the connection. And so for each request a new TCP connection will be established.
By default HTTP 1.1 client/server uses keep-alive where as HTTP 1.0 client/server don’t support keep-alive by default.”
Таким образом, тест для Slim должен выглядеть так:
Ab -H "Connection: close" -c 10 -t 3 http://localhost/php-framework-benchmark/slim-3.0/index.php/hello/index
Concurrency Level: 10
Time taken for tests: 3.000 seconds
Complete requests: 10709
Failed requests: 0
Total transferred: 2131091 bytes
HTML transferred: 353397 bytes
Requests per second: 3569.53 [#/sec] (mean)
Time per request: 2.801 (mean)
Time per request: 0.280 (mean, across all concurrent requests)
Transfer rate: 693.69 received
Заключение
Как и стоило ожидать безоговорочным лидером по производительности (но не скорости разработки) является Phalcon. Второе место, - а на самом деле первое среди PHP-фреймворков (а не C, на котором написан исходный код Phalcon) - занимает CodeIgniter 3!Конечно же, не стоит забывать, что каждому инструменту своё предназначение. Если вы выбираете небольшой и легкий фреймворк и собираетесь написать на нём что-то отличное от простейших приложений или REST API, то, скорее всего, вы столкнётесь с проблемами при расширении функционала. И наоборот - избыточность полнофункциональных, больших фреймворков повлечёт за собой финансовые издержки на содержание хостинга даже для элементарных приложений под большой нагрузкой.
Это тестирование проводилось для того, чтобы убедить/рассказать/укрепить позицию языка РНР версий 7.0 и 7.1 в вашем сознании и в будущих проектах, донести информацию о том, что производительность действительно возросла.
Рефакторинг внутренних структур данных и добавление дополнительного этапа перед компиляцией кода в виде абстрактного синтаксического дерева - Abstract Syntax Tree (AST), - привели к превосходной производительности и более эффективному распределению памяти. Результаты сами по себе выглядят многообещающе: тесты, выполненные на реальных приложениях, показывают, что PHP 7 в среднем вдвое быстрее PHP 5.6, а также использует на 50% меньше памяти во время обработки запросов, что делает PHP 7 сильным соперником для компилятора HHVM JIT от Facebook.
Тесты полностью подтверждают и вдвое ускорившуюся обработку запроса в РНР7, и уменьшенное количество используемой памяти.
Введение
По ходу эксплуатации различных современных фреймворков я понял, что недостаточно понимаю, как все устроено внутри; не осознаю, почему разработчики выбрали то или иное решение; обращаю внимание только на текущую задачу и не смотрю «выше, глубже и дальше». И, как вариант для профессионального роста, я выбрал создание собственного проекта.
Как показала дальше практика: читать, знать, слышать о чем-либо, и уметь самому это реализовать - совершенно разные вещи. Теоретизировать можно бесконечно, но только настоящее практическое задание позволяет понять, на каком уровне ты находишься. Всвязи с этим и было начато «написание собственного велосипеда». Каким он получился - судить вам)
Процесс разработки
Разработка фреймворка велась следующим образом: изначально было некое простейшее веб-приложение, которое дорабатывалось, переписывалось, меняло структуру, обрастало новыми классами и компонентами и т. д. Несколько месяцев назад у меня появилось свободное время, много энтузиазма и решительности таки доделать фреймворк «по-серьезному». На написание данной версии я потратил в совокупности 3-4 недели (работая в среднем 1-3 часа в день, 3-4 дня в неделю).
По мере разработки стандарты и требования я сознательно завышал для себя, искал оптимальные решения много раз переписывал код. Так, например, работу с конфигурацией я переделывал раз 5-6 (причем несколько раз кардинально), роутинг - 3-4 раза. В качестве примеров я брал код из статей, публикаций, руководств, фреймворков (Yii2, CodeIgniter, Zend, Phalcon, Bun) и т. п.
Анализ требований
Все начинается с анализа требований и пожеланий к итоговой системе.
Фреймворк должен:
- позволять быстро создать сайт «с нуля»
- иметь в себе ряд уже реализованных базовых технических решений и инструментов
- содержать разделенный frontend и backend
- отвечать современным требования по коду, технологиям, применяемым техническим решениям и т.п.
- содержать уже в базовой комплектации демо-приложение, на основе которого можно вести свою разработку
- быть модульным и расширяемым
- иметь понятную документацию, техподдержку (в идеале - сообщество)
Применяемые технологии
Список таких решений напрямую зависит от того, о чём знаете и что применяете в своей реальной практике. Т.е. подходим к необходимости постоянного мониторинга новинок и изменений в сфере ИТ.
Практики и технологии:
Структура папок
Приведу структуру файлов и папок в фреймворке (также можно посмотреть код на GitHub):
Код
В приложении есть одна единственная точка входа . Привожу код файла index.php из корневой публичной папки веб-сервера.
Session_start(); $loader = require(__DIR__ . "/../../vendor/autoload.php"); $loader->addPsr4("framework\", __DIR__ . "/../../system/"); $loader->addPsr4("frontend\", __DIR__ . "/../"); $loader->addPsr4("common\", __DIR__ . "/../../common/"); $config = array_merge(require(__DIR__ . "/../config/main.php"), require(__DIR__ . "/../../common/config/main.php")); $appication = new frameworkcoreApplication(); $appication->run($config);
Код метода run($config) из класса frameworkcoreApplication() . Производится загрузка необходимых классов приложения и производится вызов соответствующего контроллера (в методе execute() ).
/** * * @param array $config */ public function run($config = ) { $this->benchmark = new Benchmark(); $this->environment = Environment::get(); $this->config = new Registry($config); $this->response = new Response(); $this->request = Request::getInstance(); $this->assets = new Asset($this->config->assets); $this->setParams(); $this->router = new Router($this->config->routes); $this->execute(); }Код метода execute() из класса frameworkcoreApplication() . Нужный контроллер на данном этапе уже выбран, производим инициализацию этого контроллера, обработку хеадеров, вывод контента. В случае ошибки - бросаем 404 Not Found .
Public function execute() { $controllerName = $this->router->getControllerName(); try { $controllerClass = "\" . $this->config->name . "controllers\" . $controllerName . "Controller"; if (class_exists($controllerClass)) { $controller = new $controllerClass; if ($controller instanceof Controller) { $controller->setApplication($this)->run(); } } else { throw new CoreException("Controller "" . $controllerName . "" not exists: " . Request::getInstance()->server["REQUEST_URI"]); } } catch (CoreException $e) { $e->logError(); $this->response->setHeader("HTTP/1.1 404 Not Found"); $this->router->error404(); $this->execute(); exit(); } foreach ($this->response->getHeaders() as $header) { header($header); } echo $this->response->getContent(); }
Улучшения и планы на будущее
В качестве адаптера для коннекта к БД я использовал PDO . В ходе работы PDO мне не очень понравился - сложно отлаживать запросы, хочется комфорта использования ORM. Можно установить Eloquent ORM - это современное и готовое решение (применяется в фреймворке Laravel), да и к тому же оно хорошо документировано и может быть установлено из composer за несколько минут.
Так же думал о расширении базового функционала фреймворка: хотел добавить поддержку модулей. Т.е. чтобы можно было написать например, блог как отдельный модуль (со своими контроллерами, вьюверами, моделями и т.п.). И потом подключать этот модуль в любом месте приложения.
Можно расширять и базовый «джентельменский» набор классов в ядре, усложнять систему логирования, обработки ошибок, конфигурирования, писать полноценный демо-сайт со всем функционалом и т.д.
Заключение
Буду рад услышать критику кода, архитектуры, изначальных требований и прочего. Комментарии буду активно читать, постараюсь ответить на вопросы.
Так же хотелось бы реализовать какой-либо проект на базе данного фреймворка. Так сказать опробовать инструмент в работе. Понятно, что поиск заказчиков - это совсем не к данному разделу, но хотел бы услышать, можно ли на данном решении стартовать реальный проект? Популярные фреймворки «из коробки» дают функционал в 50-100 раз качественнее и масштабнее, конкурировать с ними сложно.
1. За последние несколько лет количество фреймворков в мире веб-разработки резко выросло, причем за каждым из них стоит большое количество людей, которые убеждают, что это лучший инструмент в своей области. Как выбрать правильный и подходящий фреймворк или набор фреймворков на проект?
Александр Макарчук
,
qb
У каждого фреймворка есть огромное количество поклонников и противников. При выборе фреймворка необходимо учитывать несколько факторов. Во-первых, фреймворк должен иметь ровно столько возможностей, сколько необходимо проекту. Излишний функционал не нужен, но при этом никогда не должно возникать ограничений при доработке проекта. Во-вторых, время разработки сайта не должно увеличиваться за счет выбора того или иного фреймворка. В-третьих, фреймворк должен быть достаточно распространен, для того чтобы проект можно было передать другому разработчику. Наконец, безопасность фреймворка - один из важнейших показателей. Все фреймворки хороши, если находятся в правильных руках.
Алексей Зубань
,
Wow
На одной чаше весов - сэкономленное время за счет решений, предлагаемых фреймворком. На другой - время, потраченное на изучение новой платформы. Выбирать нужно технологию, позволяющую в минимальные сроки решить вашу задачу. С оглядкой на риски, которые несет в себе новая для вас технология: внутренние ошибки, слабая поддержка и документация от разработчика, непроработанность решений под ваши задачи.
Александр Макаров
,
Yii
Нужно проанализировать задачу, понять, что нужно от фреймворка, выбрать топ-5 подходящих, написать на них небольшое приложение и оставить тот, что показал себя лучше остальных.
,
ADV
Надо оценивать степень соответствия функционала «из коробки» требованиям проекта, а также горизонт применения данного решения (как скоро закончится готовый функционал). При этом необходимо оценивать экспертизу команды и наличие на рынке специалистов, которые работают с данным фреймворком. Обязательно надо обратить внимание, поддерживает ли решение обратную совместимость, если создатели фреймворка меняют от версии к версии все API тогда использовать его точно не стоит.
Александр Смирнов
,
Greensight
Выбрать из известного набора фреймворков несложно, так как при проектировании сразу видна потребность в тех или иных технологиях. Далее стоит вопрос увеличения известных фреймворков, но тут уже каждый по-своему подходит. Мне кажется, что стоит в первую очередь изучить фреймворки, которые охватывают разные технологии и наиболее отличаются друг от друга. Например, какой-нибудь классический MVC фреймворк и что-нибудь с другим подходом.
Алексей Федоров
,
«Одноклассники»
Как и с любыми инструментами, ответ сильно зависит от сроков проекта. Если проект короткий, берите или то, с чем можно быстро стартовать (например, Bootstrap), или то, что хотите изучить и с чем вы хотите «поковыряться». Если проект длинный, лучше собирать собственную библиотеку компонентов.
2. Фреймворки содержат большое количество готового функционала и заметно ускоряют разработку проектов. По сути у технических руководителей проектов встает вопрос уже не какие языки выбирать, а какие фреймворки. Продолжится ли эта тенденция? Какие за этим кроются риски?
Александр Макарчук
,
qb
Зачастую встроенный готовый функционал позволяет собрать достаточно неплохую «коробку». При каком-либо отклонении приходится либо «костылить», либо «перепиливать» функционал. Тенденция будет усиливаться, так как время разработки - очень важный показатель. Но это приведет к тому, что в интернете будет появляться все больше и больше «кривых» сайтов.
Единственный плюс готового функционала - он часто помогает избежать рутинного программирования.
Александр Макаров
,
Yii
Да, продолжится. Риски, главным образом, в найме специализирующихся на одном фреймворке сотрудников. Как только задачи выйдут за рамки фреймворка или возникнет необходимость в использовании другого фреймворка, такой сотрудник может показать себя плохо.
Алексей Персианов, Михаил Парфенюк
,
ADV
Если сегментация технических решений будет углубляться, то так и будет. Но в данный момент большинство фреймворков поддерживают схожий функционал, и сегментация не слишком высока. Специфичные решения есть только для самых массовых видов задач.
Александр Смирнов
,
Greensight
Да, выбор технологического решения напрямую зависит от потребностей проекта, изученного техническим руководителем инструментария и его способности сопоставить одно с другим. Выбор языка - это скорее вопрос ресурсов: насколько легко найти разработчика в команду, если будет потребность ее расширения и т.п.
Алексей Федоров
,
«Одноклассники»
Языки и фреймворки, особенно на поздних стадиях развития, это ортогональные вещи. В развитых экосистемах фреймворки, как правило, имеют API для работы с несколькими языками и наоборот: языки с большой экосистемой имеют множество фреймворков, готовых для использования.
В современных условиях при старте проекта с нуля выбор фреймворка действительно часто стоит на первом месте, еще до выбора языка. Если же вам достался legacy-проект, то, как правило, большого выбора у вас нет и язык вам достается «в наследство».
Микросервисы, один из главных архитектурных трендов сегодняшнего дня, пытается решить в том числе и эту проблему - «освободить» разработчиков от использования конкретного языка или фреймворка, чтобы каждая часть проекта разрабатывалась на наиболее подходящих для нее технологиях.
3. Какие факторы дают гарантию надежности и стабильности фреймворка? Что позволит смело использовать инструмент на продакшне?
Александр Макарчук
,
qb
Гарантия надежности фреймворка - его отказоустойчивость. Правильная разработка, оптимизация запросов, хорошее кеширование - вот залог успеха. Можно ли выпускать сайт в продакшн, расскажет нагрузочное тестирование.
Александр Макаров
,
Yii
Наличие стабильных релизов, большое количество пользователей, наличие автоматизированных тестов, наличие активности, open source.
Алексей Персианов, Михаил Парфенюк
,
ADV
Поддержка фреймворка, его совместимость с предыдущими версиями и комьюнити.
Александр Смирнов
,
Greensight
Грубыми, но, как правило, работающими показателями стабильности и качества фреймворка являются размер сообщества разработчиков, возраст фреймворка, количество успешных кейсов, аналогичных поставленной задаче, частота изменений и количество звездочек (лайков) в репозитории фреймворка. Конечно, это грубая оценка, но с нее можно начать, и углубляться в обзоры, отзывы и т.д.
Алексей Федоров
,
«Одноклассники»
Во-первых, это open source, то есть открытый код. Это некоторая гарантия того, что если у вас что-то сломается в продакшне, вы сможете починить это своими руками. Во-вторых, вендор. Вендор языка или фреймворка может давать вам те или иные гарантии, часто подкрепленные контрактом. В-третьих, обратная совместимость. На практике это выливается в использование правильных версий языков и библиотек. Не стоит тащить в ваш продакшн библиотеку версии 0.7: как правило, если у языка или фреймворка версия ниже, чем 1.0, то нет никаких гарантий обратной совместимости.
4. Каково направление развития фреймворков, как они будут изменяться в дальнейшем?
Александр Макарчук
,
qb
Как ни прескорбно, но, на мой взгляд, фреймворки будут двигаться по пути «облегчения» разработки. Типовые решения, готовые модули и прочее - все для того, чтобы неподготовленный человек смог развернуть сайт.
Алексей Зубань
,
Wow
Для многих популярных платформ период наращивания функциональности прошел. Сейчас развитие сфокусировано на увеличении быстродействия. Это справедливо и для frontend-, и для backend-фреймворков. В качестве частного решения может служить разбивка фреймворка на логические модули. Для проекта должен собираться комплект библиотек, решающих только необходимые задачи. А также ожидаю решений, все плотнее связывающих клиентскую и серверную часть, фреймворков с единым синтаксисом и логикой работы с контентом.
Алексей Персианов, Михаил Парфенюк
,
ADV
Я не вижу явного тренда, кроме того, что востребованные функциональные ниши заполняются решениями. К сожалению, очень медленно.
Александр Смирнов
,
Greensight
Каждый фреймворк развивается по-своему, но основные изменения касаются закрытия его слабых мест и упрощения процесса разработки и поддержки.
Алексей Федоров
,
«Одноклассники»
Упрощение или, говоря более строго, коммодитизация. Фреймворки становятся все сложнее и навороченнее внутри, но все проще для пользователя. Такое упрощение - отличный способ для авторов снизить порог входа в их разработку с тем, чтобы увлечь своим языком или фреймворком как можно больше пользователей.
5. Какие еще фреймворки могут появиться? Какие области еще не закрыты и ждут появления своего удобного инструмента?
Александр Макаров
,
Yii
Абсолютно любые. Всегда можно сделать лучше.
Алексей Персианов, Михаил Парфенюк
,
ADV
Не хочу «суфлировать» разработчикам готового ПО. Таких областей масса, но надо оценивать их емкость. Очевидно, емкие ниши уже протаптываются, а остальные пока потенциальных поставщиков не привлекают.
Александр Смирнов
,
Greensight
Развитие фреймворков зависит от потребностей рынка и возможностей браузеров и пользовательских девайсов. Развитие фреймворков напрямую зависит от развития и появления новых платформ: Canvas, WebGL, Node.js - как только появлялись эти технологии, в скором времени появлялись и фреймворки по работе с ними. Как только появляется новая технология, она сразу обрастает соответствующими фреймворками.
Алексей Федоров
,
«Одноклассники»
Сейчас идут активные разработки вокруг контейнеризации. Подобные продукты еще очень далеки от идеала, с ними много проблем, поэтому многие большие проекты разрабатывают собственные решения в этой области для работы с большими инфраструктурами.
6. Сейчас фреймворками называют довольно широкий набор решений и библиотек. Может ли это измениться, появится ли более конкретная терминология? В рейтинге мы разделили фреймворки на frontend и backend. Как еще можно типизировать все это множество фреймворков?
Александр Макарчук
,
qb
Можно, но необходимости в этом не вижу.
Александр Макаров
,
Yii
Терминология есть и давно. API-фреймворки, REST-фреймворки, фреймворки-грабберы, фреймворки для мобильной разработки, модульные сетки, адаптивные фреймворки, фреймворки для модульной верстки. Перечислять можно бесконечно.
Алексей Персианов, Михаил Парфенюк
,
ADV
Да, фреймворками называют как «монстров», так и маленькие библиотеки с единственной функцией. В ближайшее время придет понимание, что такое фреймворк и библиотека, и появится четкое разделение. Что касается типизации, то на данный момент как раз и есть две ветки.
Алексей Федоров
,
«Одноклассники»
Типизировать можно кучей способов. Есть фреймворки для связи с базами данных, есть фреймвоки для связывания компонент, есть фреймворки для работы с сетью и еще для сотни-другой задач. Поэтому я бы не говорил о каком-либо строгом разделении.
7. Использование фреймворков в работе - временная мода или необходимость? Какие существуют доводы «за» и «против» использования фреймворков?
Александр Макарчук
,
qb
Безусловно, необходимость. Писать с нуля то, что написано во фреймворке и потом «латать дыры» - это наступать на чужие «грабли».
Алексей Зубань
,
Wow
Фреймворки, не навязанные извне технологии. Большинство из них создается коллективно заинтересованным сообществом разработчиков. И они вполне успешно решают актуальные проблемы, стоящие перед разработчиками. Фреймворки - добро. Другое дело, если инструмент используется неправильно или в неподходящих условиях, но это не минус технологии, это вопрос образования разработчиков.
Александр Макаров
,
Yii
Необходимость. Достичь той же скорости и качества без популярных решений сейчас трудно. На разработку с нуля аналога того же качества уйдут годы.
Алексей Персианов, Михаил Парфенюк
,
ADV
Использование фреймворков - это необходимость, которая ускоряет, стандартизирует и удешевляет разработку. Доводами «за» и «против» является распространенность фреймворка и его реальная необходимость проекту.
Александр Смирнов
,
Greensight
Использование фреймворков - это скорее неизбежность. Даже если вы решите писать приложение сложнее «Hello, world» с нуля, в результате все равно получится какой-нибудь фреймворк.
Алексей Федоров
,
«Одноклассники»
Использование готовых решений, с одной стороны, сильно ускоряет разработку и внедрение, а с другой - вносит в ваш проект чужой legacy-код с кучей своих багов и ограничений. Фреймворки - это слой, на котором работает ваше приложение. Под этим слоем лежит ваш рантайм, под ним - операционная система, а под ним - железо. И все это, заметьте - готовые решения. Я не вижу тренда ухода с готовых процессоров на процессоры собственной разработки или тренда перехода с готовых операционных систем на что-то самописное. И для фреймворков я такого тренда тоже не вижу.
8. Когда при разработке веб-проекта наступает уровень, после которого уже сложно и неперспективно для дальнейшего развития проекта использовать CMS и лучше писать проект на одном из фреймворков?
Александр Макарчук
,
qb
Выбирать платформу нужно на этапе проектирования, а не в какой-либо другой момент жизненного цикла проекта.
Алексей Зубань
,
Wow
Понятие CMS и фреймворка не конфликтуют между собой. CMS - это шаблонный интерфейс по управлению приложением. В основе CMS вполне могут быть использованы фреймворки. И решение о необходимости использования или создания такого интерфейса должно опираться на функциональность приложения. Нетиповые вещи сложнее реализовывать в шаблонных рамках. Большая гибкость фреймворков может быть полезна, когда над проектом работает несколько команд и/или необходимо внедрять системы непрерывной интеграции.
Александр Макаров
,
Yii
Никогда. Есть проекты, которые вписываются в CMS. Есть проекты, которые не вписываются в CMS. Инструмент надо выбирать по задаче, а не задачи подгонять под инструмент.
Алексей Персианов, Михаил Парфенюк
,
ADV
Когда становится понятно, что в обозримом плане развития проекта слишком много задач приходится писать практически с нуля.
Александр Смирнов
,
Greensight
Когда CMS не хватает гибкости и приходится ее ломать, чтобы реализовать задачу. Это же касается и фреймворков: при длительном развитии проекта не всегда хватает гибкости и приходится переходить на другое решение или переписывать ключевые его части.
Алексей Федоров
,
«Одноклассники»
Когда затраты на разработку и поддержку становятся слишком большими.
Поделюсь своими рассуждениями и вставлю свои пять копеек. В статье не будет ни множества цифр, ни графиков (всяких Google Trends), только личные наблюдения.
Так вот, с выходом последних версий PHP и появлением новых версий популярных PHP-фреймворков (Zend Framework 2, Yii2 (альфа) и т.д.) — интерес к языку PHP усиливается. К слову на текущий момент язык чрезвычайно популярен. В основном среди начинающих веб-разработчиков (на данный момент он используется более чем на 80% всех веб-сайтов), и среди ресурсов со средней посещаемостью.
Есть разумеется примеры сайтов мирового масшатаба, использующих PHP:
Вернемся к вопросу PHP-фрейморков и выбору какой же из них сейчас популярен, востребован и какой следует изучать. Если говорить о западном рынке, то там безусловными лидерами по востребованности и частоте упоминания являются: Zend Framework , CodeIgniter и стремительно набирающий популярность Yii . На крупнейших мировых биржах фрилансеров oDesk и Elance кроме этой тройки часто упоминаются CakePHP и Symfony .
На просторах пост-советского пространства популярны по степени убывания:
- Zend Framework
- CodeInginter
- Symfony
- Kohana
- CakePHP
Если резюмировать, то наиболее популярные в мире PHP-фреймворки по предпочтениям программистов и запросам работодателей это Zend Framework , CodeIgniter и Yii . Последний стремительно набирает популярность. Среди разработчиков фрилансеров распространены также Symfony и CakePHP.
Несмотря на рост популярности других скриптовых языков (вроде Python и Ruby), крупные корпорации в большинстве своем все еще останавливают свой выбор на PHP. И руководствуются при выборе платформы такими критериями как мастарибуемость, популярность фреймворка и наличие на рынке специалистов по данной платформе. В области HiLoad язык PHP немного уступает и видимо достиг своего предела. Но появляются компилируемые решения на его основе вроде kPHP, HipHop и т.д.
Что же изучать и на что ориентироваться?
Если у вас есть базовые знания PHP, вы хотели бы развиваться в этом направлении и вы хотите чтобы ваши навыки были полезными для работодателя — стоит в первую очередь присмотрется к первой тройке фреймворков: Zend , CodeIgniter , Yii . Далее стоит определится с тем какой из них будет для вас более «мил» и прост в изучении. И наконец, протестировать их.
Мое личное отношение к феймворкам следующее:
— Zend Framework — популярен но монструозен, есть проблемы с производительностью. Со знанием данного фреймвока найти работу вы сможете без труда, другой вопрос получится ли у вас «легкой войти» в него. Как по мне он сложен в изучении и начинать с него не стоит, ИМХО.
— CodeIgniter — прост и быстр. Но очень отстал в плане функционала от своих конкурентов. С него очень хорошо начинать чтобы разобраться с MVC и прочими премудростями. Но со временем функционала из коробки вам будет не доставать.
— Yii — нечто промежуточное. Чуть менее производителен чем CodeIgniter, зато содержит в себе гораздо больше функционала. Есть хорошая документация, и в целом значительно более дружественен чем Zend.
— Остальные упомянутые выше фрейморки так же достойны внимание, но я личного контакта с ними не имел, а поэтому мутить воду не буду.
Я начинал с изучения CodeIgniter, полюбил его. Затем мне стало не хватать функционала и я начал искать альтернативу. На текущий момент изучаю и использую в работе Yii. Если вопрос какой PHP-фреймворк выбрать для изучения поставить ребром — то я бы все таки склонился к изучению Yii 1.1. И пусть вас не смущает активная работа над обратно-несовместимым Yii2, до его выхода в продакшн ой как далеко.
Надеюсь я был вам полезен.
Выбор правильного фреймворка для проекта на PHP - первый шаг для его успешной реализации. Из нашей статьи вы узнаете о лучших PHP-фреймворках 2016 года.
Slim
Slim - микрофреймворк, идеально подходящий для небольших проектов или приложений, где полноценный фреймворк покажется лишним. Его используют многие PHP-разработчики для создания RESTful API и сервисов. Среди функций Slim - кэширование HTTP на стороне клиента, URL-маршрутизация, шифрование сессий и cookie, а также мгновенные сообщения по HTTP-запросам. Документация полная и сделана качественно.
Phalcon
Phalcon был создан в 2012 году и быстро стал популярным среди PHP-разработчиков. Его считают очень быстрым, так как он написан на C и C++, чтобы достигать наивысшего возможного уровня оптимизации производительности. Но не волнуйтесь, учить С не придется - вся функциональность заключена в PHP-классы, которые можно использовать для любых целей.
Так как Phalcon изначально был создан как расширение на С, его архитектура оптимизирована на низком уровне, что значительно снижает расходование ресурсов, типичное для приложений, основанных на схеме MVC. Phalcon не только повышает скорость выполнения, но и снижает уровень затрат ресурсов. У этого PHP-фреймворка есть и много других замечательных функций: универсальный автозагрузчик, менеджмент ресурсов, безопасность, перевод, кеширование и т. д. Документация для Phalcon довольна обширна, а использовать его несложно.
Интересный факт: еще в году Phalcon был вторым по популярности фреймворком, согласно данным sitepoint.com. А уже в 2015-м он заметно сдал позиции и переместился ближе к концу списка.
CakePHP
Фреймворку CakePHP уже десять лет, а он все еще в топе. Работе с ним легко обучиться, а шаблонирование - быстрое и настраиваемое. Встроенная функция CRUD очень помогает при взаимодействии с базой данных. В последнем релизе - CakePHP 3.x - улучшилось управление сессиями и модульность (они разъединили несколько компонентов), а также расширились возможности создания большего количества отдельных библиотек.
Среди проектов, реализованных на CakePHP, - сайты BMW и Hyundai . Выбирайте его, если вашему веб-приложению требуется высокий уровень безопасности, потому что функций для этого здесь предостаточно:
- валидация ввода;
- Защита от атак с использованием внедряемого SQL (SQL injection);
- предотвращение межсайтового скриптинга;
- защита от подделки межсайтовых запросов и многое другое.
Zend Framework 2
Zend Framework 2 - фреймворк с открытым исходным кодом, использующийся для разработки веб-приложений и сервисов на PHP 5.3+. Он использует на 100% объектно-ориентированный код и большинство новых функций PHP 5.3: пространства имен, позднее статическое связывание, лямбда-функции и замыкания. Zend - надежное решение со множеством вариантов конфигурации. Обычно его не рекомендуют использовать для небольших приложений, а вот для крупных проектов это самое то.
Среди функций Zend Framework 2: инструменты криптографического кодирования, простой в использовании drag-and-drop-редактор с поддержкой фронтенд-технологий (HTML, CSS, JavaScript), мгновенная онлайн-отладка, инструменты для unit тестирования, мастер конфигурации базы данных. Создатели этого фреймворка учли методологию Agile, что позволяет создавать высококачественные приложения для корпоративных клиентов.
В партнерах Zend - IBM, Microsoft, Google и Adobe. Год назад Zend объявил о следующем крупном релизе - Zend Framework 3, оптимизированном под PHP 7, но все еще поддерживающем PHP 5.5 и выше. Все ждали новинку еще осенью 2015-го, но и сейчас, в апреле 2016-го третьей версии все нет.
Yii 2
Выбирайте Yii , чтобы повысить производительность сайта. Он быстрее всех остальных PHP-фреймворков, так как использует технологию загрузки по требованию (lazy loading). Yii 2 полностью объектно-ориентированный и основан на принципе Don’t-Repeat-Yourself («не повторяйся»), так что основа для кода будет чистая и логичная.
Yii 2 интегрирован с jQuery и поставляется с набором AJAX функций. Механизмы скиннинга и выбора тем здесь просты, так что фреймворк понравится тем, кто ранее занимался фронтенд-разработкой. Здесь также есть мощный генератор исходного кода - Gii , который способствует объектно-ориентированному программированию и быстрому прототипированию, а также предоставляет веб-интерфейс, в котором можно интерактивно генерировать нужный код.
PHPixie
PHPixie - сравнительно новый фреймворк, созданный в 2012 году для сайтов-визиток. Как и FuelPHP, PHPixie поддерживает схему HMVC. Он построен на независимых компонентах , которые можно использовать даже без самого фреймворка. Модули компонентов PHPixie полностью протестированы и требуют минимум других компонентов для своей работы.
На официальном сайте PHPixie есть обучающее видео, в котором заявляют, что обучиться работе с фреймворком вы сможете всего за полчаса . В их блоге также много практический кейсов. Среди функций:работа с БД на уровне объектов (ORM), кеширование, валидация ввода, аутентификация и возможности для авторизации. Можно использовать язык разметки HAML, легко вносить изменения в структуру БД, а также есть продуманная система маршрутизации.
Интересный факт о PHPixie: согласно исследованию Sitepoint 2015 года, это любимый фреймворк украинских PHP-разработчиков. Компания «Культпросвет» тоже находится в Украине, но мы почему-то не можем поставить этот фреймворк на первое место, рука не поднимается. PHPixie также популярен среди группы респондентов до 18 лет. Мы думаем, это благодаря картинке с феечкой на сайте:D
CodeIgniter
CodeIgniter - PHP-фреймворк с десятилетним стажем и очень простым процессом установки, требующим минимальной конфигурации, так что начать будет просто. Хороший выбор, если есть риск конфликта разных PHP-версий: он идеально работает практически на всех платформах виртуального и выделенного хостинга.
CodeIgniter не совсем опирается на схему MVC. Использование контроллеров обязательно, а моделей и представлений - нет, так что можно применять собственные стандарты оформления кода и найменований. Этот фреймворк подойдет тем, кому тесно в рамках, - тут море свободы. По сути это простой фреймворк на 2 МБ, но при желании можно добавлять сторонние плагины, если требуется более сложная функциональность.
Symfony 2
Компоненты фреймворка Symfony 2 используются во многих замечательных проектах, например , phpBB и Laravel - (внимание, спойлер!) победителе нашего рейтинга. Symfony может гордиться обширным сообществом разработчиков и большим количеством преданных поклонников.
Компоненты Symfony - это PHP-библиотеки, которые можно использовать повторно и выполнять с их помощью множество задач: создание форм, конфигурацию объектов, маршрутизацию, аутентификацию, создание шаблонов и много чего еще. Любой компонент можно установить с помощью Homestead , которая по сути является надстройкой над Vagrant.
Сравнительная таблица PHP-фреймворков
| Laravel | Symfony 2 | Codeigniter | PHPixie | Yii 2 | Zend Framework 2 | CakePHP | Phalcon | Slim | Fuelphp | |
|---|---|---|---|---|---|---|---|---|---|---|
| требуемая версия php | 5.5.9 | 5.5.9 | 5.4 | 5.3 | 5.1.0 | 5.3 | 5.5.9 | 5.3 | 5.5 | 5.3.3 |
| ТИПы поддерживаемых баз данных | MySQL Postgress SQLite SQL Server | MySQL Postgress SQLite Qracle | MySQL Postgress | MySQL PostgreSQI SQLite MongoDB | MySQL Postgress Qracle Sqlite | MySQL SqLite SQL Server Oracle Postgress | MySQL SQLite Postgress SQL server Oracle | MySQL SQLite Postgress Oracle | MySQL SQLite Postgress Oracle (через плагин Slim-PDO) | MySQL SQLite Postgress |
| Облачное хранилище | Amazon S3 Rackspace | Amazon S3 (плагин) | Amazon S3 (плагин) | - | Amazon S3 | Amazon S3 Rackspace Windows Azure | Amazon S3 (плагин) | Amazon S3 (плагин) | - | Amazon S3 (плагин) |
| документация на официальном сайте | Пошаговое руководство, справка по API, видеоуроки | Пошаговое руководство, справка по API | Небольшое пошаговое руководство, справка по API | Пошпговое руководство | Пошаговое руководство, справка по API | Пошаговое руководство, подробная справка по API с |
