Использование Symfony2 для создания e-commerce портала с нуля

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

    Выбор 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 операции. Быстро и дешево.

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

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

    Comments 23

      +3
      Не хотите выложить в open source свой движок?
        –1
        Вопрос так вопрос:) Честно не думали об этом, думаю он еще сыроват, причесывать и причесывать:) Чтобы потом не стыдно было:)
          +2
          Если честно, а зачем? Просто проект, я так понял, большой, кастомный, полностью никому (кроме них) особо и не нужный. Ну максимум почитать код на симфони. Намного полезнее если разработчики будут выкладывать отдельные бандлы собственного производства.
          –1
          оптимизировать быстродействие

          Этот пункт тоже особо интересует. Раз уж вы упомянули, скажите, сколько у вас времени обычная страница грузится? А то почему-то на текущем Симфони2 проекте в дев режиме задержки по 5-10 секунд идут. На продакшне тоже не «летает» :(
            0
            Я сейчас доделываю магазин, страничка с фильтрами и разнообразно получаемыми тегами(где 20-30 запросов SQL) генерится в prod — 60-100 мс, в dev — ~200-500мс (это генерация динамики). Всё стараюсь делать аннотациями, ибо так удобнее.

            P.S. Проверьте сколько длятся запросы к БД у вас через профайлер и для APC насколько фрагментирована память для начала…
              0
              Кстати да, я гонял запрос профайлером, судя по всему аннотации, если работать с файловым кешем, отжирают очень много. Там по одному файлу на каждое поле идет. То есть это первое что я вижу, ну и для аутолоадера APC тоже заюзаю.
              +4
              В дев режиме нет кеша, поэтому все работает в нем медленно и это нормально. Если полностью снести кеш, то 5-10 секунд для первого запуска это быстро. На продакшне все на порядок быстрее. Точных замеров не делал, потому что задачи ускорения быстродействия пока не стоит. Если кеш есть, то в секунду даже в самом худшем случае укладываться должно.

              Для симфони жестких оптимизаций несколько:
              — APC
              — Он же для всякого мелкого кеша вроде автолоада, DQL
              — Memcache для доктриновского result cache и хороший алгоритм его инвалидации
              — Проверьте как у вас настроен логгер и что падает в лог апача
              — Хорошо настроенный HTTP cache. ESI с reverse proxy мы пока не используем, но для начала хватает стандартного AppCache
              — Если много рутов, можно покопаться в нете и найти для них Apache Dumper. Dumper создаст по рутам htaccess правила.
              — Когда устоится схема БД, пересмотреть связи в доктрине. Тут правило одно — как можно меньше bidirectional связей и событий. У доктрины есть в доках немного про оптимизацию
              — Если можно на странице обойтись голыми данными, пусть их доктрина и возвращает. Большой объект с множеством связей создается долго, простой массив — быстро.
              — События ядра симфони тоже стоит использовать с умом

              Я бы посоветовал прогнать ключевые страницы через какой-нибудь профилировщик. Симфони достаточно гибок, поэтому быстрым из коробки быть не может. Но и медленным я бы его не назвал. По опыту могу сказать, часто проблемы в медленных клиентских скриптах и слишком тяжелой разметке и стилях. PHP скрипт отрабатывает достаточно быстро.
                +1
                Если много рутов, можно покопаться в нете и найти для них Apache Dumper. Dumper создаст по рутам htaccess правила.

                Зачем? Есть же app/console route:dump
                  +1
                  Спасибо за отличные советы.

                  В дев режиме нет кеша, поэтому все работает в нем медленно и это нормально.


                  Медленно не может быть нормально. За те 7 секунд я уже пол-вконтактика перечитать успею. Вроде как и читать его не хотел, вроде как хотел работать, но пока дождешься… Считаю, что перспектива за фреймворками типа Phalcon phalconphp.com/. Но пока попробовать его не было возможности, хотя выглядит вкусно.
                    0
                    О, спасибо за ссылочку. Многообещающая штука!
                      0
                      Ещё есть порт ZF на C от китайских братьев — Yaf.
                  +2
                  > Yii был еще очень свежий на тот момент (осень 2011 года), а мы знаем, чем бывают чреваты эти «горячие пирожки» (как показало время – версия Yii 2.0 с полной поддержкой PHP 5.3 пишется до сих пор).

                  Это что у вас прикол такой про очень свежий? 2.0 версии еще нет, но за последний год было 5 релизов версии 1.1 и Yii прекрасно работает на PHP 5.3.

                  > И мы решили не рисковать и взять наиболее готовый и стабильный продукт – Symfony 2.

                  Ну это вообще смех. Я дат не помню кончено, но Symfony 2 из beta вылез вроде прошлым летом?

                  P.S. Не в коем случае не говорю, что Symfony 2 — плохо, просто ваши доводы — чушь.
                    +2
                    По качеству решений Yii уже проигрывает Symfony. Опять же Yii 2 положение дел не изменит.
                      0
                      Прошлым летом он зарелизился, но к тому моменту его уже активно использовали. На сайте симфони где-то есть страница с… success stories. Так вот некоторые из этих проектов стартовали еще до релиза стабильной версии фреймворка.

                      На самом деле не стоит искать в этой статье какую-то агитацию) Каждому нравится свое. Нам тогда показался это выбор правильным и сейчас ничего не изменилось.
                        +3
                        Yii отлично всплыл на том, что разработчики (мягко говоря) забили на symfony1 и Yii занял его нишу.
                        Звучит холиворно, но по сути это так. Оба фреймворка Rails-Django-подобные. Но у symfony намного больше база кода, больше библиотек. Вот только сейчас он стал не нужен, ибо появился архитектурно и концептуально другой Symfony2.
                        0
                        Сколько у вас в команде программистов? Изучали Symfony 2 по ходу работы или изначально набирали людей с опытом? Проще говоря, можно ли в Москве найти хороших программистов на Symfony 2 или проще обучить/вырастить у себя?
                          0
                          Если в резюме будет написано: 8 лет опыта разработки на Symfony2, то что-то тут не так )
                          В Москве, наверняка, можно. Но и вырастить тоже вполне. От Zend или symfony до Symfony2 не такой уж и большой скачок, но месяц-два придется тщательно курить мануалы.
                            0
                            Сначала мы искали, потом решили взять и обучить:)
                            +1
                            Вел разработку E-commerce системы на Silex (почему-то казалось тогда хорошим решением) + mongodb (инзачально был MySql, но нашему опыту интернет-магазин не очень укладывался в реляционную модель) + sphinx для поиска.
                            Также разрабатывалась общая админка для этих магазинов. Общение между админкой и магазином реализовывалось через REST API.
                            К чему я это? На мой взгляд, Symfony2 отличное решение для E-commerce системы (в свою очередь мы выбрали более легкий ее вариант), да и в целом, хороший фреймворк, остальное за реализацией.
                              0
                              Киньте хоть ссылку на то, что получилось в итоге
                                –1
                                remmart.ru/ — вот тут можно посмотреть:)
                                0
                                Пробовали github.com/Sylius или github.com/vespolina?
                                  0
                                  Пробовали.
                                  Оба достаточно сырые. Vespolina тянет слишком много лишнего. Sylius в этом плане нам больше подходит. Мы рассматриваем возможность замены части нашей системы на один из этих наборов бандлов (или его часть) после релиза Symfony 2.1.

                                  Если вы интересуетесь Symfony, то должны знать что из себя представляет проект CMF. Так вот Vespolina (как более продуманный в плане архитектуры набор бандлов их этих 2х) лично мне кажется еще сырее CMF. А его пока используют только в sandbox проектах и для презентаций (тут возможно я что-то упускаю ибо не было времени посмотреть презентации с Symfony Live Paris 2012, а там доклад от этих ребят был).

                                Only users with full accounts can post comments. Log in, please.