Автор: Максим Монахов — декан
Некоторое время назад мы уже писали статью о плюсах Битрикса: «Чем
Недостаточно гибкая архитектура
Инфоблоки в
За пример возьмем простой элемент «Документ», который обладает характеристиками:
- тип;
- дата формирования;
- автор;
- наличие подписи;
- кем подписан.
Он хранится в разделе «Заявления», подраздел «Запросы на справку».
Поле «Кем подписан» связано с инфоблоком — справочником сотрудников. Предположим, что данные поступают из внешней базы данных. Стандартный механизм импорта данных не предусматривает возможности обновления — только стирание и запись заново.
При этом, пока мы не добавим элементы в один инфоблок, не сможем получить уникальные идентификаторы, чтобы установить связь. Это приводит к тому, что при обмене необходимо передавать избыточное количество данных об этих связях.
Для
- Значительно увеличивается риск ошибки формирования связей. Их приходится задавать программисту вручную — чем больше связей, тем чаще путаница.
- Возрастает объем передаваемых данных, что приводит к существенному снижению скорости обмена, иногда на порядок.
- Связи, которые мы настраивали вручную, будут стерты при выгрузке.
Пример: bakalavriat.fa.ru
Публичная часть использует
Чтобы обеспечить корректность отображения информации, приходится выстраивать сложную вложенную иерархию разделов, дублировать ее в характеристики программы. При этом используются связанные с ней дополнительные справочники преподавателей, предметов, цен. В результате обработка данных занимает порядка 30–40 минут для 300 элементов. При использовании фреймворка это занимает меньше минуты, так как есть возможность сделать структуру базы данных сайта в точном соответствии с БД источника.
Кроме того, нельзя
Проблема обработки данных с нескольких источников
Часто в интеграциях данные собирают с нескольких источников, причем получение из одного зависит от параметров другого. Естественно бывают ситуации, когда один из источников недоступен. В таком случае
Когда мы используем системы, написанные на современных фреймворках, сбор данных может осуществляться с помощью программного брокера, который умеет обрабатывать конкретные нештатные ситуации: дожидается полных данных, выстраивает порядок и очереди для их получения. Получается, что сбой любой системы не приводит к проблемам на целевой системе!
В Битриксе такой механизм не предусмотрен, что ведет за собой следующее:
- Если мы собираем данные сразу со всех источников, то сбой одного из них приводит к возникновению серверной ошибки — все данные не получены.
- Если мы собираем данные по очереди, то нам приходится их хранить сразу в Битриксе. Допустим, с
какого-то источника мы не взяли информацию, и получается так, что часть данных — новая, часть — старая. Как итог — дезинформация посетителей и проблемы с «поломанными» разделами на сайте.
Пример:
Данные о стоимости, расписании и ценах собираются более чем с 30 источников. Сбой одного из них приводит к тому, что на сайте отображается неактуальная информация для бронирования.
Для решения проблемы был написан отдельный механизм сбора данных на фреймворке, который формирует пакет обновления данных в Битрикс.
Только вылилось это в дополнительные финансовые и временные затраты для владельцев сайта.
Проблемы интеграции с 1С
Если конфигурация 1С, которая является поставщиком данных для сайта, не поддерживает работу со стандартным модулем обмена, то интеграция с Битрикс становится совсем не таким простым делом, как это заявлено. А ситуация, когда модуль обмена не работает, очень частая:
- или большинство конфигураций 1С не умеет работать с модулем обмена изначально;
- или была произведена масштабная доработка исходной конфигурации, и модуль обмена перестал работать.
В таком случае на стороне 1С нужно дорабатывать модуль обмена, либо поднимать SOAP/API шлюз. При одинаковых трудозатратах шлюз выглядит предпочтительнее,
Битрикс также потребует доработок для работы с новым модулем обмена или шлюзом. Если выбран последний (а это логично в 99,9%), то наступают те же проблемы, что описаны в предыдущем разделе: обращения к шлюзу требуют построения очереди, а ее лучше обрабатывать брокером.
Да и само написание модуля для работы со шлюзом на стороне
Кратко о других минусах
Разрастание объема хранимых данных
Если сайту на
В случае фреймворков для файлов может быть использована
Проблемы масштабирования
Современные фреймворки сразу поддерживают возможности масштабирования системы в случае ее роста. Например, в рамках концепции связанных микросервисов. Для
Тяжелая интеграция с современными средствами разработки публичной части сайта (верстки)
Современные решения: VueJS, Angular, React
На этом я, пожалуй, закончу! Вдруг вы подумаете, что я вас отговариваю от Битрикс! А на самом деле, если вы надумаете делать сайт — просто обратитесь к нам. Мы работаем в этой сфере ежедневно уже более 11 лет и с полной уверенностью подберем систему управления сайта под любые ваши задумки.