Комментарии

Сейчас время экосистем, так как это не только удобно но и дает организации преподнести все свои продукты в рамках единой платформы, что несомненно удобно и выгодно

Спасибо интересно, сейчас в нашей компании решаем на какой технологии строить экосистему и скорее всего расмотрим либо Ларавел, либо ДСТ платформ

Зарегистрировался из за этой статьи, большой, подробный и серьезный обзор, автору большое спасибо. Сейчас в нашей компании решаем на какой технологии строить экосистему и скорее всего расмотрим либо Ларавел, либо ДСТ платформ

Об Ангуларе много слышал и наши айтишники о нем все время говорят, но как по мне слишком сложен для российских реалий, нам нужно что по проще и по скромнее

Честно говоря все эти новомодные фреймворки слишком не приминимы в Российских реалиях, тут людям нужно что по проще и по скромнее

Хорошая статья, плюсую

Хотелось бы почитать о монетизации маркетплейса более подробно, какие есть варианты и способы, заранее благодарю

Хорошая статья, тоже считаю что сейчас время нишевых маркетрлейсов, так как обще тематические уже монополизированны и понятно кем

Насчёт: Существует два варианта, как вы можете создать онлайн-маркетплейс: написать код с нуля, например, на современном фреймворке Laravel или использовать готовую платформу, например, DST Platform с индивидуальной доработкой функционала.

На Laravel конечно это можно создать, вот только автор не написал что для этого понадобится от года до полтора времени, что совершенно по моему не рационально

Тут сразу можно добавить что еще недостаточно гибкая архитектура

Инфоблоки в 1С-Битрикс — набор элементов, который обладает фиксированными характеристиками и может быть иерархически выражен с помощью разделов. Каждый элемент инфоблока связан с другими через специальное свойство. Если говорить просто — сколько разных инфоблоков надо связать, столько свойств надо сделать.

За пример возьмем простой элемент «Документ», который обладает характеристиками:

тип;
дата формирования;
автор;
наличие подписи;
кем подписан.

Он хранится в разделе «Заявления», подраздел «Запросы на справку».

Поле «Кем подписан» связано с инфоблоком — справочником сотрудников. Предположим, что данные поступают из внешней базы данных. Стандартный механизм импорта данных не предусматривает возможности обновления — только стирание и запись заново.

При этом, пока мы не добавим элементы в один инфоблок, не сможем получить уникальные идентификаторы, чтобы установить связь. Это приводит к тому, что при обмене необходимо передавать избыточное количество данных об этих связях.

Для двух-трех инфоблоков — не страшно, но когда их десятки, то происходит следующее:

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

Главное в Битриксе это проблемы масштабирования

Современные фреймворки сразу поддерживают возможности масштабирования системы в случае ее роста. Например, в рамках концепции связанных микросервисов. Для 1С-Битрикс рост нагрузки всегда приводит к длительным доработкам, часто с привлечением сторонних продуктов, как уже было описано ранее.

Тяжелая интеграция с современными средствами разработки публичной части сайта (верстки)

Современные решения: VueJS, Angular, React и т. п. позволяют ускорить и разработку сайта, и саму работу. Интеграция с 1С-Битрикс возможна, но она, наоборот, увеличивает время разработки.

А потому что битрикс сделан не как набор лего-конструктор из которого можно лепить что угодно. А как монолит в который впрыскиваются настройки, соответственно везде настройки не сделаны, и из такого не удобно ничего делать кастомного.
Изначальный подход был не верный, и такого софта большинство к сожалению.

Про запросы к БД в цикле, как будто стандартные компоненты так не делают. Битрикс можно заставить работать быстро, если не использовать стандартные компоненты, нот тогда чем он лучше любого другого фреймворка? Наличием админки только если, но и эта админка не так уж хороша.

Типичная ситуация, когда знакомишься с новым проектом на Битрикс, первым же делом лезешь в php_interface, чтобы посмотреть сколько костылей поверх Битрикса поставили предыдущие разработчики. А почему? А потому что без них нельзя, писать модуль для расширения стандартного функционала будут только мазохисты.

И да, после меня в php_inerface останется ещё пара костылей, так принято, такие у нас традиции…

Докину ещё парочку «остроумных инженерных решений»:

1. Если в публичке в константе SITE_ID содержится id сайта, то в админке эта константа будет содержать id языка ( то есть «ru» вместо «s1» ).

2. (скорее всего, следствие из п.1) в админке не подключаются файлы раздельных init.php для сайтов ( то есть, например, /local/php_interface/s1/init.php )

3. некоторые методы в классах ядра объявлены как final, так что нельзя просто взять, отнаследоваться и переопределить; приходится подниматься выше по цепочке наследования и копипастить не совсем нужное.

Вот мои не «типичные аргументы о недостатках платформы»:

Инфоблоки без сомнения являются «сердцем» Битрикс, на них построено очень много решений, в частности каталог товаров в стандартных компонентах магазина. Чтож, попробуем создать инфоблок, заполяем замечательные поля NAME, CODE, IBLOCK_TYPE_ID и т.д.
А потом попробуем получить инфоблок — по названию (NAME) находит, по коду (CODE) находит, а по типу (IBLOCK_TYPE_ID ) — нет. Ну как так? А оказывается, для фильтра по типу нужно использовать ключ TYPE, а не IBLOCK_TYPE_ID. Почему, а главное, зачем?

О, документация, любимица всех битриксойдов! Получение списка элементов инфоблока, чуть ли не основной метод Битрикса — в первом же примере кода ошибка.
Описание части методов вообще утрачено, пример.

Придумали D7, несколько лет назад, до сих пор создать элемент инфоблока нельзя. Зато у нас «ко-пилоты» и BI-аналитика в последнем обновлении.

Про обновления, кстати. В статье ошибкой номер 1 указано «создание самописных компонентов». А вот без самописных компонентов на чистом Битрксе, да на том же Аспро — ставишь обновление — пропадают цены у товаров. Купить ничего нельзя, в корзину добавить нельзя, все товары недоступны — это так называемая обратная совместимость. Каждое обновление как пороховая бочка — сперва на тесте, потом на тесте теста, потом тестирование теста… ну вы поняли. В итоге придумали параметр «COMPATIBLE_MODE», везде пойди проставь, при обновлении-то нельзя автоматически это сделать.

Или вот, хочешь например сделать в инфоблоке свойство-привязку к разделу. Например что бы показывать сопуствующие товары для элемента, или комплектующие какие-нибудь — к этому же инфоблоку товаров привязать нельзя через админку. Ну почему? А потому что если ты вдруг это сделаешь, сломается непонятно что непонятно где, т.к. часть стандартных механизмов не умеет работать с отдельными свойствами-разделами, а сразу по всем смотрит. Ладно, делаешь отдельный инфоблок «сопутки» — так в некоторых компонентах нельзя 2 инфоблока выбрать\подключить.

Компанию по email получить нельзя… Email и телефоны в отдельную таблицу засунули, ладно многие-ко-многим, понятно. Но почему в эту же таблицу засунули и Email-ы контактов и лидов, всё в кучу.

Или вот еще, допустим, была у вас на сайте форма, создающая лиды в портале. Простой понятный процесс — форму заполнил, лид создался. Обновляешь портал — файлы из формы не грузятся. А почему? Потому что выпилили загрузку файлов в лидах! Как говорится в статье, «встает вопрос «Кто виноват?» »…

Ух наболело, разошелся я что-то. Вот вам последняя загадка.

Как называется таблица в которой хранится URL сайта (для многосайтовости)?
Варианты:
1. b_site
2. b_url
3. b_domain
4. b_lang

Это если есть компетентный менеджер со стороны заказчика, заинтересованный в результате.

А так: взяли битрикс, взяли шаблон «Аспро», вкатили изменения в дизайн настройками Аспро, воткнули одно в другое, отдали — и пусть изучают в реальности, что им на самом деле от интернет-магазина надо.

А «программист» тут нужен для маркетинга.

Написать интернет магазна yii с нуля и интегрировать его с 1с, складом, доставкой, оплатами, с любым дизайном займет много меньше времени чем отлаживать Битрикс

При том, что я достаточно хорошо отношусь к битриксу, проблемы всё же у него обычно отмечаются совсем другие.

1. Существующие на маркетплейсе модули (действительно сильное маркетинговое преимущество битрикса для разработчиков и для клиентов) частенько реализованы через жопу или с применением хаков и трюков для обхода ограничений существующего ядра Битрикс (что вызовет проблемы при смене ядра, а вы потом устанете искать ошибку);

2. Стиль программирования в 1С-Битрикс совершенно особенный, конечно, и далёк от лучших практик;

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

Если нужна стандартная функциональность и можно отказаться от всего, что долго, дорого и больно реализовывать на битриксе — выбор норм. Программистов на битриксе много, предложение на рынке РФ бьёт почти любое другое, по доступности. Цена ошибки не очень велика, скорость запуска и надёжность работы — достаточны.

Как только нужно что-то уникальное (иногда на полшага в сторону от типовых потребностей, буквально) — разработка на Yii или Symfony может оказаться быстрее, надёжнее и дешевле.

Не люблю Битрикс и не в коем случае не хочу проводить тут активно рекламу, приведу лишь кейс из практики

К нам пришел крупный клиент из ювелирной тематики, у которого очень медленно работал сайт.

Провели технический аудит и обнаружили:
— Низкое качество программной реализации.
— Несоблюдение стандартов разработки на 1С-Битрикс и отсутствие документации.
— Множество источников скрытых ошибок.
— Уязвимости для безопасности сайта.
— Места с повышенной нагрузкой.
— Легаси от нескольких подрядчиков с различными стилями написания кода и отсутствием единой концепции.

Устранив большинство проблем и проведя рефакторинг, мы полностью решили вопросы со скоростью работы сайта.

Как проходит аудит и что получает заказчик

Что входит в техаудит:
— Анализ работы сервера, кода и программной архитектуры.
— Стандартные тесты 1С-Битрикс: качества, производительности, безопасности, работы модулей и компонентов.
— Frontend-тестирование: кроссбраузерное и кроссплатформенное тестирование верстки на реальных устройствах, а также с использованием сервисов.
— Нагрузочное тестирование: выявление предельных нагрузок, анализ достаточности настроек ПО сервера, анализ результатов и рекомендации.
— Функциональное тестирование: корзины, оформления заказа, личного кабинета, регистрации и других элементов функционала.

Что в результате

По итогам анализа заказчик:
— Получит подробный отчет, который содержит качественные и количественные данные, сводные таблицы и инфографику, выводы и рекомендации.
— Сформирует целостную картину проблем, которые наблюдаются в серверной архитектуре и коде: backend и frontend.
— Поймет, что нужно предпринять, чтобы увеличить скорость работы сайта.
— Получит конкретные рекомендации, как исправить выявленные проблемы.
— Сможет подготовить список важных задач для развития проекта и определите их приоритет.

Так что да проблемы у Битрикса есть, но в большинстве случае их можно решать, хотя и сложно

Так ли плох Битрикс на самом деле? Разбираем возможные причины технических проблем и низкой скорости интернет-магазина

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

Если сайт работает с ошибками и сбоями, то встает вопрос «Кто виноват?»

Нередко исполнители грешат на Битрикс. Типичные аргументы о недостатках платформы:
— Проблемы при интеграции с 1С.
— Недостаточная гибкость архитектуры.
— Проблемы при обработке данных из нескольких источников.
— Разрастание объема хранимых данных.
— Проблемы масштабирования.
— Сложная интеграция с современными средствами разработки верстки.

Но так ли плох Битрикс на самом деле? Кейс из практики

Клиент готовился к запуску нового сайта на готовом решении Aspro для Битрикс вместо старого — на Python. Но при перенаправлении на новый ресурс всего лишь 30% трафика (20 тысяч пользователей в сутки) он переставал выдерживать нагрузки и падал.

Клиент начал сомневаться, что новый сайт на Битрикс вообще выдержит их нагрузку. Встал вопрос: дорабатывать текущий сайт или создавать еще один, но на фреймворке.

Мы провели углубленный технический аудит сайта и нагрузочное тестирование, чтобы выявить слабые места. Проверили производительность текущего клиентского сайта, чистый шаблон Aspro.Next и Битрикс с настройками по умолчанию без изменений в коде.

Выяснили, что сайт на «чистом» Aspro.Next выдерживает нагрузку в разы большую той, чем нужно клиенту. Обнаружили, что проблемы на клиентском сайте связаны с некачественной кастомизацией компонентов Aspro и большим количеством некэшируемых запросов. После исправления ошибок сайт работает гораздо быстрее и с легкостью выдерживает даже большие нагрузки, чем на старой версии.
Почему экономить на разработке невыгодно. Некачественный сайт = низкая конверсия = убытки

Мнимая экономия на старте нередко приводит к тому, что в бэкенде накапливается большое количество проблем. В итоге через какое-то время подрядчик предложит либо произвести рефакторинг кода, либо полностью создать сайт с нуля.

К примеру, в рамках аудита интернет-магазина производственной компании мы нашли такое большое количество проблем и барьеров в UX, что клиент принял решение отказаться от старого сайта, так как бюджет по устранению ошибок был соразмерным. И несмотря на то, что мы всегда выступаем за постепенный редизайн, в данном случае выгоднее было разработать новый сайт.

Сбои в работе интернет-магазина — это прямое влияние на бизнес. Чем больше проблем, тем больше барьеров на пути пользователя, ниже конверсия и больше потерь.