Всё началось с того, что мы задумали веб портал для продажи мебели. Это веб портал для продажи предметов мебели и интерьера, и что у меня самого есть множество идей, которые мы должны реализовать в рамках будущего портала. Все эти идеи были похожи на интернет-магазин, но при этом они не совсем укладывались в рамки обычного магазина. Например, товары мы должны показывать в красивых интерьерах реальных квартир — это интересно, а главное удобно для покупателя. Значит, у нас на сайте должны быть отдельно карточки и интерьеров и товаров, которые образовывают структуры. Вот еще задачка: сам портал не имеет своего склада и логистики, а только агрегирует информацию: собирает, анализирует, красиво показывает и генерирует продажи у партнеров. Значит нужно ввести различных поставщиков, показывать различные условия доставки и т.д. Поэтому перед нами встал вопрос: что мы можем использовать, чтобы создавать портал не с нуля, но при этом иметь большую гибкость при кастомизации выбранных решений. Итак, что же у нас получилось.
Выбор LAMP
Вначале мы выбрали общий стек технологий. Здесь было просто: ведь наиболее распространённый выбор технологий для веб-порталов — это LAMP (Linux, Apache, MySQL, PHP). Мы не хотели изобретать велосипед, писать все с нуля, так как это и дорого и долго. Нам нужно было максимально быстро создать портал с использованием каких-либо библиотек/фреймворков, возможно CMS/E-commerce систем. Если LAMP технологии наиболее распространены — то значит, мы сможем найти большое количество различных open-source решений, а из них сможем выбрать что-то подходящее для «фундамента» своего портала.
Готовые E-commerce системы
Как только мы выбрали PHP и все, что с ним связано, мы начали смотреть, что уже есть готового по нашей тематике. Конечно же, мы сразу начали думать про готовые E-commerce системы, например, набирающую популярность Magento. Нашли нескольких партнеров Magento, которые занимаются кастомизацией и внедрением этой системы. Попросили сделать примерную оценку того, во сколько нам обойдется «заточить» Magento под все наши требования, включая оптимизацию быстродействия, с которым у Magento, как оказалось, есть сложности, особенно у бесплатной версии. Наши расчеты показали, что по стоимости работ и дальнейшей поддержке в краткосрочном периоде — это будет даже дороже, чем, если бы мы писали все с нуля на чистом PHP. Мы посмотрели другие E-commerce решения: osCommerce, ZenCart, PrestoShop. Здесь ситуация была примерно такая же, а может даже хуже. Таким образом, мы вернулись в исходную точку поиска.
Фреймовики и библиотеки
Тогда мы решили смотреть в сторону более общих решений: фреймворков и библиотек. Мы решили остановиться на выборе 3-ех наиболее популярных фреймворков: Zend 1.11, Symfony 2 и Yii. Здесь у нас был более технологичный подход к выбору: мы хотели полную поддержку PHP 5.3, причем, желательно, чтобы сам код фреймворка предполагал стиль написания PHP 5.3, а именно как можно больше ООП, ведь нам же это все еще поддерживать потом. От Zend отказались сразу. Он очень монструозный, а нам нужно процентов 20 от его функциональности. К тому же ожидаемый 2.0 тогда был еще в форме идей на сайтах основных разработчиков. Yii был еще очень свежий на тот момент (осень 2011 года), а мы знаем, чем бывают чреваты эти «горячие пирожки» (как показало время – версия Yii 2.0 с полной поддержкой PHP 5.3 пишется до сих пор). И мы решили не рисковать и взять наиболее готовый и стабильный продукт – Symfony 2.
ORM решения
Итак, у нас были выбраны и платформа и фреймворк: LAMP + Symfony2. Нам также нужно было решить проблему с уровнем хранения и представления данных в нашем портале. Наверное, хорошо написать что-то специфическое для себя – это и работает быстрее и меньше кода. Однако основная наша проблема была в том, что мы делали свой продукт, и у нас не было четкой и постоянной спецификации. Улучшения же (читай: частые изменения) в сущностях, их взаимосвязях и бизнес-логике, требовали какого-то гибкого решения, которое мы могли бы быстро изменять и не бояться получить массу regression багов. В данном случае мы пошли хорошо проторенной дорогой. Сейчас большую популярность набирают различные ORM решения. Это не зависит от стека технологий или домена приложения. Посему после недолгих рассуждений мы выбрали ORM Doctrine 2. Тем более что она входит как стандартный модуль в Symfony 2. К тому же, мы понимали, что с ростом объемов данных и взаимосвязей между сущностями при работе на портале, мы перейдем к использованию нереляционной СУБД, например, MongoDB, а с выбранной ORM – Doctrine это также просто реализуется.
Итого у нас получился интересный набор технологий:
LAMP + Symfony 2 + Doctrine 2.
Неявным плюсом комбинации этих технологий оказалось то, что нам было очень легко в дальнейшем мотивировать сотрудников к работе в нашей команде, так как технологии, которые мы выбрали, очень свежие и перспективные. Конечно, за исключением LAMP.
Symfony
Теперь немного подробнее про детали использования Symfony для создания веб-порталов. Данная тема уже хорошо раскрыта в посте: “Symfony 2: полезные библиотеки и бандлы”. Кстати, когда мы увидели этот пост, то оказалось, что мы практически все уже используем в своей работе. Приятно, что наш выбор совпадает. И все-таки мы хотели бы вкратце перечислить те бандлы (плагины), которые мы использовали, а также причины для этого выбора.
SonataMediaBundle – мы используем для работы с картинками, видео, swf объектами – 360, панорамы. Если вам нужно работать с медиа контентом – то очень советую. Бандл легко кастомизируется и настраивается. Сейчас мы храним контент на том же сервере, что и код. Этот бандл позволит нам легко перейти на Amazon или другие облака. Причем сделать это можно будет буквально за пару часов. Если вы используете исключительно картинки, то вам понадобится какая-нибудь обертка для стандартных PHP модулей – gd, imagick. Мы использовали Imagine и AvalancheImagineBundle. Можно конечно и что-то другое, но сколько вы знаете хороших PHP библиотек такого плана?
FOSUserBundle – изначально мы использовали его как быстрый способ начать работать с пользователями. Многие скажут, что он слишком большой для задач вроде простой авторизации. Я же скажу, что он просто немного более гибкий, чем некоторым нужно. У нас этот бандл используется совместно с сервисом Loginza. Типичный пользователь чаще заходит через vkontakte или facebook (я, например, через twitter).
FOSRestBundle – мы только начинаем его активно использовать. Могу сказать, что админка в том виде, который нам нужен, идеально вписывается в REST. Тут как стандартные операции, вроде «обнови», «удали», так и вывод в разных форматах данных.
KnpMenuBundle – легко заменил весь наш код для навигации – меню, хлебные крошки. Думаю, каждый PHP программист писал для себя нечто подобное. Долой велосипеды! Даешь простое меню!
TwigBundle – потому что нравятся шаблоны, не нравится писать их на PHP и, конечно, очень не нравится Smarty. Да, мы знаем, что есть Smarty 3, который тоже что-то может. Однако не зря же их выкинули с smarty.php.net.
SwiftMailer — слишком тяжелая для нас библиотека. В наши планы входит переход на что-то более легкое и простое. Из плюсов отличная интеграция в Symfony2.
FOQElasticaBundle — не любим Sphinx. Шутка. У нас сейчас не тот объем контента, в котором тяжело искать. Потому мы решили, что Elastica будет более правильным решением. Из коробки автообновление индекса на все CRUD операции. Быстро и дешево.
Коллеги, кто занимался созданием и развитием порталов, поймут меня сейчас — работа не заканчивается никогда. И сейчас у нас множество задач и планов по техническому развитию ресурса, не считая всех фантастических идей инвесторов. Наиболее важные задача сейчас для нас — это настроить поиск и кэширование данных, оптимизировать быстродействие, перевести хранение статического контента на соответствующие сервера. Об этом, если хватит времени, позже напишу отдельно.
Я надеюсь эта статья будет интересной для тех, кто задумывает или уже создает новый успешный и технически грамотный портал, удачи вам в этом деле!
Выбор LAMP
Вначале мы выбрали общий стек технологий. Здесь было просто: ведь наиболее распространённый выбор технологий для веб-порталов — это LAMP (Linux, Apache, MySQL, PHP). Мы не хотели изобретать велосипед, писать все с нуля, так как это и дорого и долго. Нам нужно было максимально быстро создать портал с использованием каких-либо библиотек/фреймворков, возможно CMS/E-commerce систем. Если LAMP технологии наиболее распространены — то значит, мы сможем найти большое количество различных open-source решений, а из них сможем выбрать что-то подходящее для «фундамента» своего портала.
Готовые E-commerce системы
Как только мы выбрали PHP и все, что с ним связано, мы начали смотреть, что уже есть готового по нашей тематике. Конечно же, мы сразу начали думать про готовые E-commerce системы, например, набирающую популярность Magento. Нашли нескольких партнеров Magento, которые занимаются кастомизацией и внедрением этой системы. Попросили сделать примерную оценку того, во сколько нам обойдется «заточить» Magento под все наши требования, включая оптимизацию быстродействия, с которым у Magento, как оказалось, есть сложности, особенно у бесплатной версии. Наши расчеты показали, что по стоимости работ и дальнейшей поддержке в краткосрочном периоде — это будет даже дороже, чем, если бы мы писали все с нуля на чистом PHP. Мы посмотрели другие E-commerce решения: osCommerce, ZenCart, PrestoShop. Здесь ситуация была примерно такая же, а может даже хуже. Таким образом, мы вернулись в исходную точку поиска.
Фреймовики и библиотеки
Тогда мы решили смотреть в сторону более общих решений: фреймворков и библиотек. Мы решили остановиться на выборе 3-ех наиболее популярных фреймворков: Zend 1.11, Symfony 2 и Yii. Здесь у нас был более технологичный подход к выбору: мы хотели полную поддержку PHP 5.3, причем, желательно, чтобы сам код фреймворка предполагал стиль написания PHP 5.3, а именно как можно больше ООП, ведь нам же это все еще поддерживать потом. От Zend отказались сразу. Он очень монструозный, а нам нужно процентов 20 от его функциональности. К тому же ожидаемый 2.0 тогда был еще в форме идей на сайтах основных разработчиков. Yii был еще очень свежий на тот момент (осень 2011 года), а мы знаем, чем бывают чреваты эти «горячие пирожки» (как показало время – версия Yii 2.0 с полной поддержкой PHP 5.3 пишется до сих пор). И мы решили не рисковать и взять наиболее готовый и стабильный продукт – Symfony 2.
ORM решения
Итак, у нас были выбраны и платформа и фреймворк: LAMP + Symfony2. Нам также нужно было решить проблему с уровнем хранения и представления данных в нашем портале. Наверное, хорошо написать что-то специфическое для себя – это и работает быстрее и меньше кода. Однако основная наша проблема была в том, что мы делали свой продукт, и у нас не было четкой и постоянной спецификации. Улучшения же (читай: частые изменения) в сущностях, их взаимосвязях и бизнес-логике, требовали какого-то гибкого решения, которое мы могли бы быстро изменять и не бояться получить массу regression багов. В данном случае мы пошли хорошо проторенной дорогой. Сейчас большую популярность набирают различные ORM решения. Это не зависит от стека технологий или домена приложения. Посему после недолгих рассуждений мы выбрали ORM Doctrine 2. Тем более что она входит как стандартный модуль в Symfony 2. К тому же, мы понимали, что с ростом объемов данных и взаимосвязей между сущностями при работе на портале, мы перейдем к использованию нереляционной СУБД, например, MongoDB, а с выбранной ORM – Doctrine это также просто реализуется.
Итого у нас получился интересный набор технологий:
LAMP + Symfony 2 + Doctrine 2.
Неявным плюсом комбинации этих технологий оказалось то, что нам было очень легко в дальнейшем мотивировать сотрудников к работе в нашей команде, так как технологии, которые мы выбрали, очень свежие и перспективные. Конечно, за исключением LAMP.
Symfony
Теперь немного подробнее про детали использования Symfony для создания веб-порталов. Данная тема уже хорошо раскрыта в посте: “Symfony 2: полезные библиотеки и бандлы”. Кстати, когда мы увидели этот пост, то оказалось, что мы практически все уже используем в своей работе. Приятно, что наш выбор совпадает. И все-таки мы хотели бы вкратце перечислить те бандлы (плагины), которые мы использовали, а также причины для этого выбора.
SonataMediaBundle – мы используем для работы с картинками, видео, swf объектами – 360, панорамы. Если вам нужно работать с медиа контентом – то очень советую. Бандл легко кастомизируется и настраивается. Сейчас мы храним контент на том же сервере, что и код. Этот бандл позволит нам легко перейти на Amazon или другие облака. Причем сделать это можно будет буквально за пару часов. Если вы используете исключительно картинки, то вам понадобится какая-нибудь обертка для стандартных PHP модулей – gd, imagick. Мы использовали Imagine и AvalancheImagineBundle. Можно конечно и что-то другое, но сколько вы знаете хороших PHP библиотек такого плана?
FOSUserBundle – изначально мы использовали его как быстрый способ начать работать с пользователями. Многие скажут, что он слишком большой для задач вроде простой авторизации. Я же скажу, что он просто немного более гибкий, чем некоторым нужно. У нас этот бандл используется совместно с сервисом Loginza. Типичный пользователь чаще заходит через vkontakte или facebook (я, например, через twitter).
FOSRestBundle – мы только начинаем его активно использовать. Могу сказать, что админка в том виде, который нам нужен, идеально вписывается в REST. Тут как стандартные операции, вроде «обнови», «удали», так и вывод в разных форматах данных.
KnpMenuBundle – легко заменил весь наш код для навигации – меню, хлебные крошки. Думаю, каждый PHP программист писал для себя нечто подобное. Долой велосипеды! Даешь простое меню!
TwigBundle – потому что нравятся шаблоны, не нравится писать их на PHP и, конечно, очень не нравится Smarty. Да, мы знаем, что есть Smarty 3, который тоже что-то может. Однако не зря же их выкинули с smarty.php.net.
SwiftMailer — слишком тяжелая для нас библиотека. В наши планы входит переход на что-то более легкое и простое. Из плюсов отличная интеграция в Symfony2.
FOQElasticaBundle — не любим Sphinx. Шутка. У нас сейчас не тот объем контента, в котором тяжело искать. Потому мы решили, что Elastica будет более правильным решением. Из коробки автообновление индекса на все CRUD операции. Быстро и дешево.
Коллеги, кто занимался созданием и развитием порталов, поймут меня сейчас — работа не заканчивается никогда. И сейчас у нас множество задач и планов по техническому развитию ресурса, не считая всех фантастических идей инвесторов. Наиболее важные задача сейчас для нас — это настроить поиск и кэширование данных, оптимизировать быстродействие, перевести хранение статического контента на соответствующие сервера. Об этом, если хватит времени, позже напишу отдельно.
Я надеюсь эта статья будет интересной для тех, кто задумывает или уже создает новый успешный и технически грамотный портал, удачи вам в этом деле!
