«7 причин перейти с Drupal на Yii» (Eric Kennedy)

Представляю вашему вниманию перевод статьи «7 reasons to switch from Drupal to Yii«. Ее автор Eric Kennedy (технический директор сайта RealSelf.com) делится своим мнением по поводу переходу с Drupal нa Yii.

drupal-training-wheels
После выпуска Drupal 7 многим компаниям надо решить следует ли им переходить на новую версию или остаться на Drupal 56. Drupal хорош если вы создаете много web-сайтов, если вам надо быстро создавать новые web приложения с небольшим объемом кодированием или например если вам нужен блог с большим объемом контента.

Выбирая работу с Drupal вы как бы выбираете для жилища трейлер заместо традиционного дома (такой компромисс для человека который не может позволить себе нормальный дом). Но если у вас есть сайт который начал свое развитие с Drupal и вырос достаточно чтобы занять разработчика на полный рабочий день, то вам нужно подумать о переводе вашего сайта на PHP фреймворк Yii (Конечно если вы не любите PHP то можете выбрать Python с его фреймворком Django. Хотя это займет больше количество времени связи с перехода на другой язык программирования)

Я технический директор сайта , который перешел с Drupal на Yii c 30 апреля 2010 года. Когда мы вели дебаты следует ли переписывать сайт было трудно найти нужную информацию (ведь даже не существовало ни одной книг по Yii). Существовали несколько заметок по поводу перехода с Drupal на Yii, но они не были достаточно содержательны что бы успокоить меня. Я волновался что Yii может оказаться медленнее, чем наш сильно оптимизированный Drupal. Поэтому я решил переписать 20% ядра ​нашего сайта (который покрывал 80% наших функционала) в течение 30 дней. Мне казалось это отличным способом проверить производительность фреймворка. Если Yii не привел бы к улучшениям после месяца работы мы могли бы безболезненно вернутся к Drupal скопировав новые данные за этот период.

Yii оказался для нашего сайта(150 000 страниц данных и 50 000 посетителей в день) намного быстрее, чем Drupal. Да, мы работали сумасшедшее количество времени в течение этих 30 дней (да и следующие 15 дней тоже), но оно того стоило. Теперь для времени, которое мы ранее тратили для улучшения медленных запросов в Drupal, можно найти лучшее применение. При этом не надо забывать о гораздо большем удовольствие при разработке с Yii, чем на Drupal. Реальное преимущество Yii мы почувствовали позже, когда занимались редизайнингом нашего сайта. С MVC Yii нам достаточно было изменить 2 файла макета, заместо нескольких десятков в Drupal.

Я только жалею что мы не перешли на Yii годом ранее. И вот что мы узнали:

1. Drupal это не лучший способ начать разработку с нуля.

Основной причиной разработчиков использования Drupal является мысль «а зачем нам делать свою собственную CMS?». Как и многие разработчики, я писал все веб-приложения с нуля (в 1999 и 2000 ) и высоко ценю возможность сосредоточиться на специфическом функционале, а не писать свой собственный код отвечающий за авторизацию пользователей, валидацию форм, предотвращение SQL инъекций и многое другое. В начале 2007, в компании которую я помог основать, был создан прототип Web-сайта на Drupal после отказа от использования Ruby On Rails. Повальное увлечение Ruby напомнил мне увлечение Java в 1997 году. В 1997-99 я проходил стажировку в WebEx competitor. Производительность их серверов была убита путем кодирования на Java в угоду маштабированности. PHP доказала свою состоятельность в таких проектах как Friendster и Facebook, и наши пользователи не хотят видеть кита с птичками , если мы столкнемся с проблемами масштабированости в Ruby.

Конечно начальный старт проекта на Drupal легче чем кодирование нужного функционала на PHP. Но связка PHP 5 с фреймворкам запущенным в разработку в 2008 году дали положительный результат уже в 2009 году. И в настоящее время, разработчик PHP, начиная работу над веб-приложением (и работая полный рабочий день только на этом сайте) будет выбирать фреймворк или стараться начать с нуля используя сторонние PHP библиотеки (PECL и PEAR).

2. Если Drupal является фреймворком, то только Руби Голдберг может любить его.

Drupal был разработан так, чтобы быть расширяемым без особого программирования на PHP. Это прекрасно, если вы имеете сайт с простым контентом или малы трафиком. А если вы работая полный рабочий день и пишите модули настройки форм, добавляете нужную функциональность,то Вы будете тратить больше времени на борьбу с Drupal чем на реализацию нужных функций в том же фреймворке. Yii имеет противоположный подход: например вы можете использовать Ruby on Rails-подобные конструкции если вам надо написать быстро код доступа к базе, а для оставшегося 10% запросов применить оптимизацию и обратиться к MySQL «напрямую».

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

На сегодня существует слишком много дополнительных модулей к Drupal. И если вы работаете разработчиком с этой CMS то вы, вероятно занимаетесь решением проблем совместимости ваших модулей со сторонними . Отличный пример, это модуль Drupal`a отвечающий за кеширование и изменения размера изображений. Поскольку модуль предназначен для общего использования (так что он может взаимодействовать с произвольным числом других модулей!), он включают в себя тонны функционала которого вы никогда не будете использовать. В нашем случае что бы просто сделать эскизы изображений нужного размера вам потребуется воспользоваться бинарной версией ImageMagick. Нам «всего то» надо включить 4 модуля: ImageAPI, ImageAPI for ImageMagick, ImageCache и ImageCache UI в кучу php файлов. А затем выполнить команды для генерации эскизов в 2 таблицы базы данных. Если эта система вдруг перестанет работать при обновление, то у вас займет кучу времени диагностика проблемы. В отличие от того случая когда вы бы построили систему только на том что вам действительно нужно.

Yii тоже имеет расширение для изменение размеров изображения (адаптированное из Kohana Image Library), но она не включает в себя ненужную функциональность (Вращенние! Переворот!) и осложненно только тем что позволяет Вам легко переключаться между ImageMagick и GD. (GD имеет проблемы изображения больше 2 МБ ). Несмотря на все это, он не позволяет нам изменять размер изображений на лету, используя RewriteRule, если миниатюры не существовало. Поэтому я создал простой файл index.php, что бы делать ручками обратный вызов (callbacks ) RewriteRule на обнаруженном изображение на виртуальном хостинге и посылать Shell команду для конвертации. Это значит что обратный вызов RewriteRule не проходят через файл Yii index.php снижая накладные расходы и время, необходимое для изменения размера изображений и кэш-операции. Только страница на PHP и аргумент посылаемый однажды для конвертации бинарных данных — это гораздо легче для тестирования и поддержки когда мы обновляем ImageMagick.

4. Багаж Drupal от PHP 4.

Когда я решил рассмотреть PHP фреймворки, я быстро понял, что хочу только 100% поддержку PHP 5 с ООП структурой. Вряд ли вы найдете много народу утверждающих что подход Drupal с процедурными «хуками» является ООП подходом. Хотя Drupal 7 требует PHP 5 (как и CodeIgniter и другие старые фреймворки PHP) он все еще несет тяжкий груз обратной совместимости. Вам нужен этот багаж?

5. Не хотите замедление сайта от перехода с Drupal 5 на Drupal 6 или 7? Будете бороться с устаревшим JQuery.

Мы действительно заботимся о скорости работы приложений, поскольку Google и Microsoft, показали, что пользователи более лояльны к быстрой сайтам. В 2009 году, когда Drupal 6 был создан, мы застряли на Drupal 5 связи с его преимущество в скорости. Проблема в том, что Drupal 5 включает JQuery 1.0. Вы можете обновится до JQuery 1.2 (и обновить Drupal функции, которые ссылаются на него), но это все равно старая версия. Забудьте о JQuery 1.3x и Drupal 5.

6. API Drupal`а и Content Construction Kit (CCK) будут сводить вас с ума т.к. они по прежнему часть ядра Drupal 7.

Зачем использовать $node->ip, когда вы можете использовать $node->field_ip[0][‘value’]. И если вы решите, что два типа контента (content types) должно иметь текстовое поле с одинаковым именем , то CCK поместит их в свою таблицу (content_field_ip) с восхитительным именем столбца (field_ip_value). Конечно, Drupal может разобраться во все этом беспорядке когда полностью загрузит узел с данными, но в базе это смотрится совершенно некрасиво. В запросе MySQL потребуется много джойнов присоединяющие все внешние таблицы CCK, а это усложнит запрос. В конечном итоге получим частое обращение медленного запроса. И вот случилось что мне надоело пытаться оптимизировать все эти медленные запросы и я решил избавиться от ССК, что и привело меня к PHP фреймворкам, а затем и к Yii.

Миграция наших данных в Yii заняла примерно столько же времени сколько понадобилось для освоения ССK в Drupal. Тем не менее, мы смогли начать с чистой БД без всех дополнительных таблиц которые Drupal использует для внутренних целей. В нашей старой БД было 173 таблицы, а в новой 54.

7. Drupal НАМНОГО медленнее, чем Yii.

/webmaster-tools-download-time
Сравним Drupal если ВСЕ кэши имеют Memcached и APC, а все медленные запросы переписаны. Кэширование особенно важно, если вы используете раскрутку сайта (SEO) с перенаправлением для каждой полученной ссылки, поскольку каждая функция обращается к базе сепаратно. Таким образом средняя страница выполняет более 50 запросов, по сравнению с 3-5 в Yii. После перехода, наше среднее время загрузки страницы уменьшилось с 162 мс до 67 мс (данные получены Google Webmaster Tools). Еще лучше показала себя связка Yii + APC. Работает все настолько быстро, что у нас нет необходимости использовать memchached, тем самым упрощается и наш код.

Наша статистика серверов говорят сами за себя — при том же количество одновременных запросов посетителей (считалось количество процессов Apache), загрузка базы данных и загрузки процессоров уменьшилась. Использование памяти осталось примерно на том же уровне. За последний год наш трафик увеличился на 60% (до 1,5 млн. посещений за месяц) в то же время количество запросов к MySQL упал на 66%

drupal-performance

«7 причин перейти с Drupal на Yii» (Eric Kennedy): 5 комментариев

  1. Иван

    Убедило полностью.
    Более 2-ух лет мучаюсь с друпалом как программист и понял — пора делать ноги, жаль что не раньше.
    Смысл друпала (и его логика) — чтобы создавать некий сайт без программиста используя готовые модули с орга.
    При этом эти модули программисты должны писать БЕСПЛАТНО.
    И эти модули писать очень непросто и долго, все время борешься с друпалом и решаешь паззлы, вместо просто создания функционала. Модули с орга и их функционал пишутся месяцами, ты под свой проект так не попишешь.
    Поэтому свои модули под проект писать — экономически как правило не выгодно, да и заказчики не хотят за это платить. И хотят чтобы как то настройкой существующих модулей все нужное «ПОЛУЧИЛОСЬ». А это вообще нудная работа не относящаяся к программированию.
    Ну может при темизации еще программист немного потребуется, но за это копейки платятся….

  2. ikenfin

    Сейчас пишу средний проект с применением Yii. Непривычно после drupal’a. Пробовал django — вот это вещь скажу я вам!

  3. Cruitly

    Создана самая незаметная таблетка от импотенции

    Подробнее тут: http://edrussia.uol.ua/text/5244400/sozdana-samaya-nezametnaya-tabletka-ot-impotentsii/

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *