Комментарии

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

Насчёт: Существует два варианта, как вы можете создать онлайн-маркетплейс: написать код с нуля, например, на современном фреймворке 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, что клиент принял решение отказаться от старого сайта, так как бюджет по устранению ошибок был соразмерным. И несмотря на то, что мы всегда выступаем за постепенный редизайн, в данном случае выгоднее было разработать новый сайт.

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

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

Такс, напомните пожалуйста, в Битриксе до сих пор пишут страницы на php? Шаблонизатор так и не завезли? Ну типа там Twig.

Кейс из нашей практики работе с 1с-Битрикс

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

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

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

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

1. Ошибки при работе непосредственно с платформой Битрикс. Самая распространенная проблема — ошибки в работе типового функционала из-за модификаций в ядре 1С-Битрикс.

Есть еще одна серьезная проблема — создание самописных компонентов без особой необходимости вместо использования сложных комплексных и стандартных от Битрикс. Это вызывает проблемы при попытках расширения функционала, обновлении CMS и при развитии проекта.

2. Ошибки backend-разработки на PHP и Bitrix API. Запросы к БД в цикле, лишние файлы, служебные скрипты в открытом доступе, отсутствие защиты при обращении к GET- и POST-параметрам.

3. SQL-запросы в файлах страниц, шаблонах, запросы в циклах. Ошибки логики, постоянные повторы ошибок и, как следствие, высокая нагрузка на сайт и замедление его работы.

4. Кеширование компонентов отсутствует или отключено. В режиме отладки выводится сообщение о нулевом размере кэша, в результате — высокие нагрузки и замедление работы.

5. Ошибки верстки. Сайт загружается, но интерфейс не работает несколько секунд. В итоге пользователь видит сайт искаженным, а поисковые системы понижают сайт в ранжировании.

6. Проблемы с изображениями. Тяжелые и неоптимизированные картинки, которые могут быть низкого качества, устаревшего формата и в неэффективной кодировке.

7. Некорректная работа скриптов. Например, сами скрипты подключаются с внешних серверов, которые географически удалены от сервера сайта.

8. Низкий уровень безопасности сайта. Уязвимости к SQL-injection и Cross-Site Scripting. Файлы сессий, которые позволяют мошенникам получать доступ ко всем проектам на хостинге. Отладочная информация выводится на страницах публичной части, служебные файлы доступны по URL.

9. Не настроен сервер и его окружение. При повышении посещаемости сайт замедляется или вовсе отказывается работать. В итоге ресурс теряет позиции в поисковых системах и возможных клиентов.

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

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

12. Не удалены неиспользуемые модули. Чем больше в системе модулей, тем дольше загружается любая страница и дольше запускается инициализация ядра платформы. Это приводит к медленной работе сайта.

Татьяна, все зависит от индивидуальных особенностей каждого проекта, сейчас я бы если это не стартап конечно отдал бы классической архитекуре т.к. она проверена и надежна, но будущее вполне вероятно за безголовыми CMS

Так если есть возможности что лучше тогда выбрать — Headless CMS, для высоконагруженного проекта?

Headless CMS — это серверная система управления контентом, которая работает в основном как хранилище. Она делает контент доступным через API для отображения на любом устройстве без встроенного интерфейса или презентационного слоя.

Некоторые преимущества Headless CMS:

— Разнообразие каналов контента. CMS можно подключить к любому количеству фронтендов и выводить контент на любые устройства, сайты и мобильные приложения.
— Согласованность работы. Не нужны несколько отдельных команд для каждого наполнения, можно максимально оптимизировать ресурсы и сэкономить на работе специалистов.
— Конфиденциальность. Риск утечки данных минимальный, так как c контентом работают без привязки к интерфейсу.
— Высокая скорость загрузки. За счёт того, что передача происходит через API, статичный контент будет отображаться моментально как на крупном сервисе, так и на одностраничном лендинге.
— Экономия ресурсов. Благодаря подключению к CDN не требуется проводить нагрузочное тестирование и привлекать специалистов для настройки балансировки серверов.

Выбор между Headless CMS и традиционной CMS зависит от требований проекта и его технических возможностей.

Объясните как понять что безголовая CMS работает как хранилище и в чем ее все таки осные преимущества, только простым языком, чтоб было понятно.