Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
Спасибо за статью. Было интересно почитать почему вы делаете интернет магазины на Angular, а например не на Битриксе или Magento. Ну и конечно бы хотелось кейса разработанного интернет-магазина — как делали, где сложности, зачем и почему))))
Мы делаем магазины на Angular чтобы избежать постраничности, постоянных переходов — таким образом пользователю приятнее пользоваться сайтом. Поэтому мы ушли с PrestaShop\Magento в сторону разработки переиспользуемых компонент на Angular (только сразу на втором). А дальше мы из них собираем фронт выбирая те модули что нам нужны в конкретном магазине. Все модули независимы друг от друга, но есть связующее звено DAL — data abstraction layer, через которое происходит работа с backend. На github есть коннектор к firebase как бэкэнду. Вообще скоро планируется статья отдельно про firebase, а потом ещк именно про сами компоненты для интернет магазинов с примерами (к этому моменту надеюсь напишем starter-project).
Angular 2 хороший конструктор, каждый компонент можно создать легко и правильно в архитектурном смысле, прописав все интерфейсы.
В Bitrix часто приходится делать костыли из модуля «новости» и засовывать все в инфоблоки, которые хранятся в базе, делая бутылочное горлышко еще уже.
Magento очень тяжелая и по ней мало специалистов, не все хотят иметь опыт по «cms N».
В Bitrix часто приходится делать костыли из модуля «новости» и засовывать все в инфоблоки, которые хранятся в базе, делая бутылочное горлышко еще уже.
Magento очень тяжелая и по ней мало специалистов, не все хотят иметь опыт по «cms N».
Это все про 4й Angular, он не такой хайпный, и совсем-совсем новый. Учли всю ту боль с которой мы жили используя 1й Angular. Новый Angular совсем-совсем модульный. Собственно из-за этого он намного более похож на конструктор, более чем плагины в той же magento.
+ разрабатывать интерфейс на нем намного комфортнее чем в шаблонах того же prestashop\magento, за счет большей кастомизируемости и гибкости.
Скажем так — по всем параметрам, кроме SEO, удобство решения на Angular выше чем у класического написания шаблонов для magento\prestashop.
А про то как решается вопрос с SEO как раз и расказанно в статье.
+ разрабатывать интерфейс на нем намного комфортнее чем в шаблонах того же prestashop\magento, за счет большей кастомизируемости и гибкости.
Скажем так — по всем параметрам, кроме SEO, удобство решения на Angular выше чем у класического написания шаблонов для magento\prestashop.
А про то как решается вопрос с SEO как раз и расказанно в статье.
Вечный холиварный вопрос — Angular with React да будет кровь!..
Банально дешвеле стоимость владения и больше перееиспользуемость между проектами. Очень помогает RxJS в разработке. Ну и кончено удобство работы с Firebase из Angular. На данный момент иной нежели Firebase конеектор не предусмотрен. С появление Firebase Functions разработка других конекторов становится менее приоритетной.
Банально дешвеле стоимость владения и больше перееиспользуемость между проектами. Очень помогает RxJS в разработке. Ну и кончено удобство работы с Firebase из Angular. На данный момент иной нежели Firebase конеектор не предусмотрен. С появление Firebase Functions разработка других конекторов становится менее приоритетной.
Конечно, но вопросы по теме статьи приветствуются в первую очередь. Если у вас есть вопросы об Angular Universal и том как его применять в живых проектах — будем рады.
В статье описанны те грабли с которыми мы столкунулись — возможно вы можете подсказать нам на какие мы еще не напоролись в Angular Universal?
В статье описанны те грабли с которыми мы столкунулись — возможно вы можете подсказать нам на какие мы еще не напоролись в Angular Universal?
spatNeHochu >
Нет, не имеете, ибо вы не написали ни одной статьи на хабре.
Хочешь понижать другому карму, оценивать коменты читателей и давать оценки статьям — напиши статью на Хабр. (С)
Хабр не место для дискуссий
Ну это как бы просто моё мнение если что и вроде как я имею право его выражать здесь, нет?
Нет, не имеете, ибо вы не написали ни одной статьи на хабре.
Хочешь понижать другому карму, оценивать коменты читателей и давать оценки статьям — напиши статью на Хабр. (С)
Хабр не место для дискуссий
spatNeHochu
Ясно. Готовьтесь к коментам в зависимости от кармы:
От −1 до −10 Можно комментировать лишь 1 раз в 5 минут
От −11 до −30 1 комментарий в час
От −31 до −100 1 комментарий в день
*От −100 и ниже 1 комментарий в неделю и значок «Тролль» *
Удачи! :-)
P.S. Или становитесь… писателем — им тут разрешено всё. Это их сайт. (С)
дали возможность комментировать буду писать комментарии, где буду мнение своё писать на что захочу (интерфейс сайта позволяет же), а ежели отберут — не буду.
Ясно. Готовьтесь к коментам в зависимости от кармы:
От −1 до −10 Можно комментировать лишь 1 раз в 5 минут
От −11 до −30 1 комментарий в час
От −31 до −100 1 комментарий в день
*От −100 и ниже 1 комментарий в неделю и значок «Тролль» *
Удачи! :-)
P.S. Или становитесь… писателем — им тут разрешено всё. Это их сайт. (С)
Вангую: потому что потом заказчик никуда не денется от их поддержки. Это вам не магентщика найти.
на самом деле нет — все компоненты в opensource. Второй Angular очень большой путь проделал по унификации и улучшению поддерживаемости, так что любой фронт разработчик знакомый с Angular сможет вносить правки в проект. А правки по оформлению может внести банально верстальщик за счет разделения кода шаблона и кода компонент.
Наше столкновение с Magento как раз показало что получается дорого и малость отстало с точки зрения фронтэнда. Конечно Magento2 уже дружит с Symfony, что безусловно пойдет ей на пользу (особенно в плане удешевления разработки под нее и уменьшения количества плохо написанных дополнений).
Наше столкновение с Magento как раз показало что получается дорого и малость отстало с точки зрения фронтэнда. Конечно Magento2 уже дружит с Symfony, что безусловно пойдет ей на пользу (особенно в плане удешевления разработки под нее и уменьшения количества плохо написанных дополнений).
А я и не говорил, что компоненты закрыты или ваше решение проприетарно. Я лишь говорю о том, что найти специалиста по поддержке ваших решений вне вашей компании будет сложно.
на самом деле нет — все компоненты в opensource
Однако это никак не опровергает тезис, что разработчика со знанием Magento намного проще, чем для модулей, которые в опенсорсе 11 дней как
найти разработчика на Angular 2 в скором времени будет проще чем найти толкового разработчика Magento. Как раз потому что область применения Angular шире чем область применения Magento.
И статья не об этом, а о новой технологии которая позволяет еще более расширить область применения Angular на сферу в которой он изначально не был применим из-за проблем с индексацией поисковиками.
И статья не об этом, а о новой технологии которая позволяет еще более расширить область применения Angular на сферу в которой он изначально не был применим из-за проблем с индексацией поисковиками.
Наше столкновение с Magento как раз показало что получается дорого и малость отстало с точки зрения фронтэнда.
А можно поподробнее раскрыть тезис про "отстало"? В коворкинге смузи не нальют?
Кстати, интересно. Админка для ваших магазинов так же на Angular, или использовали что то другое? И есть ли вообще админка? Используете одну и туже для все проектов или пишите каждый новую под требования конкретного магазина? Есть ли проблемы с интеграции платежных систем и доставки, так же используете что то готовое или каждый раз пишите заново?
Про сами компоненты чуть позже будет отдельная статья.
Сейчас все наши магазины это витрины к разнообразным учетным системам. То есть в бэкэнд данные попадают через демон импортер из 1c\google sheets\yandex.yml или иной системы. Общая концепция состоит в том что ненужно создавать еще одну монстроадинку с складом\налогами\доставкой, а интегрироваться с существующими решениями для управления складом и учетом. Чаще всего у клиентов уже есть какие-то способы управления\организациию Для посмотреть\поиграться или просто маленького магазина проще всего google sheets. Как оказалось небольшие магазины и так ведут в нем склад и продажи, так что им удобно — просто теперь данные из sheets синхронизируются с магазином (+попадаются просто зубодробильные формулы по расчету цены реализации).
А вот аналитика помимио стандартных google analytics собирается в бд, отдельно по всем действиям пользователя — устройства, сессии, клики, показы и т.д.
По поводу платежных систем — пишем универсальные модули по мере запросов от клиентов (stripe, 2checkout, w1 etc). С ними проблем нет. По поводу систем доставки — пока все статичные, будут запросы на какие-то сервисы — сделаем и с ними интеграцию.
Вообще вся корзина это просто метод композиции из модулей платежек и способов доставки, просто с учетом экспортируемых ими требований (к примеру PayPal не требует выбора адреса доставки, а наложенный платеж Новой Почтой не требует указания ничего кроме адреса)
Сейчас все наши магазины это витрины к разнообразным учетным системам. То есть в бэкэнд данные попадают через демон импортер из 1c\google sheets\yandex.yml или иной системы. Общая концепция состоит в том что ненужно создавать еще одну монстроадинку с складом\налогами\доставкой, а интегрироваться с существующими решениями для управления складом и учетом. Чаще всего у клиентов уже есть какие-то способы управления\организациию Для посмотреть\поиграться или просто маленького магазина проще всего google sheets. Как оказалось небольшие магазины и так ведут в нем склад и продажи, так что им удобно — просто теперь данные из sheets синхронизируются с магазином (+попадаются просто зубодробильные формулы по расчету цены реализации).
А вот аналитика помимио стандартных google analytics собирается в бд, отдельно по всем действиям пользователя — устройства, сессии, клики, показы и т.д.
По поводу платежных систем — пишем универсальные модули по мере запросов от клиентов (stripe, 2checkout, w1 etc). С ними проблем нет. По поводу систем доставки — пока все статичные, будут запросы на какие-то сервисы — сделаем и с ними интеграцию.
Вообще вся корзина это просто метод композиции из модулей платежек и способов доставки, просто с учетом экспортируемых ими требований (к примеру PayPal не требует выбора адреса доставки, а наложенный платеж Новой Почтой не требует указания ничего кроме адреса)
Еще раз спасибо за прекрасную статью и развернуты ответ. Была бы возможность поставить плюсы, поставил бы под каждым постом)) Я бы сказал что у вас не обычный подход, так как принято считать что Angular и Node вообще больше подходит для «штучных» сервисов и в основном используется так. Редко кто использует его для клиентских проектом. Но вы показали как его можно использовать для клиентских проектов, появилось сразу 100500 идей, а руки зачесались сделать какой нибудь магазин на angular))))
Единственное мне кажется все же какая то админка должна быть, потому что помимо склада есть еще и маркетинг и это достаточно большой пласт. Но делать еще одну монструозную админку, действительно не выход.
Но учитывая тенденцию микросервисов, можно сделать решение «между». Какая то общая админка для всех клиентов в которую интегрируется по API большое количество уже существующих решений, в основном связанные с маркетингом ( рассылки, аналитика, crm). На мой взгляд это бы коммерчески выгодным.
Единственное мне кажется все же какая то админка должна быть, потому что помимо склада есть еще и маркетинг и это достаточно большой пласт. Но делать еще одну монструозную админку, действительно не выход.
Но учитывая тенденцию микросервисов, можно сделать решение «между». Какая то общая админка для всех клиентов в которую интегрируется по API большое количество уже существующих решений, в основном связанные с маркетингом ( рассылки, аналитика, crm). На мой взгляд это бы коммерчески выгодным.
Собственно благодаря Universal надеюсь в скором времени произойдет перелом в сторону клиентских проектов, а не только админок. (Хотя и они никуда не уйдут — уже сейчас сделали пару админок на angular 2 + firebase и очень довольны).
Для маркетинга и аналитики выбран чуть иной путь. Все данные из firebase переливать в bigquery. Заказы, клики, просмотры, все-все. А дале по датасету в bigquery можно делать анализ и для любителей красоты и дашбордов есть google data studio. В нем удобно именно маркетологам работать.
Да, для работы с бд есть DataAbstractionLayer — который как раз и дает такое API и должен позволить нам в случае необходимости заменить firebase на couchdb к примеру. А так да — есть observer server сейчас, который загружает плагины, которые уже оформляют подписки на нужные события и отправляют их в интегрированные сервисы. Пример такого сервера будет в стартере в следующем месяце.
Соберетесь делать интернет магазин — милости просим :) мы будем стараться помогать всем пользователям компонент, сейчас сделали документацию на базе compodoc, далее в планах стартер для желающих быстро запустить демо магазин (правда быстро будет включать в себя докер, что увы как оказалось многих может остановить)
Для маркетинга и аналитики выбран чуть иной путь. Все данные из firebase переливать в bigquery. Заказы, клики, просмотры, все-все. А дале по датасету в bigquery можно делать анализ и для любителей красоты и дашбордов есть google data studio. В нем удобно именно маркетологам работать.
Да, для работы с бд есть DataAbstractionLayer — который как раз и дает такое API и должен позволить нам в случае необходимости заменить firebase на couchdb к примеру. А так да — есть observer server сейчас, который загружает плагины, которые уже оформляют подписки на нужные события и отправляют их в интегрированные сервисы. Пример такого сервера будет в стартере в следующем месяце.
Соберетесь делать интернет магазин — милости просим :) мы будем стараться помогать всем пользователям компонент, сейчас сделали документацию на базе compodoc, далее в планах стартер для желающих быстро запустить демо магазин (правда быстро будет включать в себя докер, что увы как оказалось многих может остановить)
Да. Сначла мы работали на MEAN стэке, потом пару раз столкнулись с Parse. У нас ранее был проект с закрытым кодом, в который мы через GTM инжектили скрипты для AB тестов, промоакций, трекинга событий и просто банальна фиксы дизайна. Соотвтетственно нам нужно было решение для храниния настроек и состояний без бд. Потом появился FireBase с возможностью подписки на изменения что позволило существенно расширить функционал. А далее мы выяснили что FireBase был куплен Google, который ни о ком не заботясь сделал релиз 3й версии, который заставил нас много всего переписать. Собственно далее мы стали его использовать как бэк для мобильных приложений, чтобы не заботится о масштабировании. Пототм для админ панелей. А сейчас вообщем-то используем для большинства новых проектов. Плюс недавний релиз функций может позволить нам избавится от oserver сервисов.
Ну и у firebase есть бесплатный хостинг — что нравистя многим клиентам, да и нам — настроил и забыл.
Ну и у firebase есть бесплатный хостинг — что нравистя многим клиентам, да и нам — настроил и забыл.
На данный момент слияния проектов еще не произошло, и пока не ясно, когда произойдет (или как итоговый вариант будет совместим с текущей реализацией)
Уже произошло https://github.com/angular/universal
Да, особенно радует роадмап:
— Write documentation for core API (In Progress)
на самом деле мы уже пытаемся запустится с новым, если получится то выложим к концу недели обновление с работающим новым Universal в компоненты уже.
+ скоро запустим эксперимент с индексацией (делаем мультистор сайта с magento на наших компонентах — сравним индексацию)
— Write documentation for core API (In Progress)
на самом деле мы уже пытаемся запустится с новым, если получится то выложим к концу недели обновление с работающим новым Universal в компоненты уже.
+ скоро запустим эксперимент с индексацией (делаем мультистор сайта с magento на наших компонентах — сравним индексацию)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дружим Angular с Google (Angular Universal)