Розробка компонента 1С-Бітрікс: архітектура та кешування

Розробка компонента 1С-Бітрікс

Стандартні компоненти Бітрікс покривають 80% типових задач. Але коли потрібні специфічні списки з фільтрацією за багатьма параметрами, складні форми з AJAX-валідацією або інтеграція з зовнішнім API — без власного компонента не обійтися. Типова помилка новачка — писати логіку прямо в шаблоні або копіювати код з component.php у кожен новий проект. Це призводить до дублювання, труднощів підтримки та проблем з кешуванням.

Уявіть каталог на 100 000 товарів з 20 властивостями фільтра — стандартний bitrix:catalog не справляється. Без кеша база падає, з кешем дані застарілі. Наш підхід — будувати компонент з правильною архітектурою, використовуючи теговане кешування та перевикористовувані класи. Ми за понад 10 років розробили більше 50 компонентів — від каталогів інтернет-магазинів до корпоративних порталів, кожен за правилами шаблону проєктування «Модель-Представлення».

Проблеми, які вирішуємо

• Відсутність кешування. Без кеша кожен виклик компонента робить запити до БД. При 1000 відвідувачів це дає навантаження 10 000 запитів на хвилину. Правильний кеш знижує його до 1–2 запитів на період кешування.
• Жорсткий зв'язок логіки та шаблону. Коли запити в template.php, дизайнер не може змінити верстку, не ризикуючи зламати код. Розділення шарів вирішує це на 100%.
• Проблеми з інвалідацією кеша. Скидання всього кеша при зміні одного елемента — марна трата ресурсів. Теговане кешування, реалізоване через \Bitrix\Main\Data\TaggedCache, оновлює лише потрібні записи та економить до 40% часу завантаження сторінки.
• Відсутність нормалізації параметрів. Параметри, передані в $arParams, можуть бути невалідними. Метод onPrepareComponentParams() у класі компонента гарантує коректні значення.

Як ми це робимо: стек та конфіги

Ми використовуємо PHP 8.1+, інфоблоки v2.0, ORM Бітрікс, модуль main. Для типового компонента (список елементів) пишемо клас, що успадковує CBitrixComponent. В onPrepareComponentParams приводимо IBLOCK_ID до int, COUNT — до додатного числа. Потім в executeComponent вмикаємо кеш, отримуємо дані через CIBlockElement::GetList з сортуванням та фільтром. Результат збираємо в $arResult['ITEMS']. Шаблон містить лише HTML та виклик AddCss/AddJs через Asset.

Кейс із практики. Для інтернет-магазину з каталогом 50 000 товарів потрібен був компонент фільтрації за 12 параметрами. Ми реалізували класовий компонент з тегованим кешем і подією OnAfterIBlockElementUpdate для інвалідації. Після впровадження навантаження на сервер знизилося на 35%, а час відгуку — з 2 секунд до 0.4 секунди.

Процес роботи

1. Аналітика — вивчаємо архітектуру, навантаження, вимоги.
2. Проєктування — визначаємо структуру, параметри, кеш, інтеграції.
3. Реалізація — пишемо клас, шаблон, тести.
4. Тестування — навантажувальне, функціональне, на сумісність з оновленнями.
5. Деплой — встановлення на бой, передача документації.

Строки розробки

Вартість розраховується індивідуально під завдання — зв'яжіться для точної оцінки.

Чому варто використовувати клас замість процедурного коду?

Класовий підхід у 2 рази скорочує час налагодження та на 30% спрощує підтримку при оновленнях. Це підтверджує наш досвід: у проектах з класами кількість багів в середньому на 40% менше. Порівняння:

Як правильно налаштувати кешування компонента?

Використовуйте $this->StartResultCache() та $this->EndResultCache(). Для інвалідації при зміні даних — BXClearCache(true, '/cache/path/') в події OnAfterIBlockElementUpdate. Точніше працює теговане кешування: TaggedCache::startTagCache('my_tag'); ... TaggedCache::endTagCache(). Воно дозволяє скинути лише записи, пов'язані з конкретними елементами, а не весь кеш компонента. Таке налаштування прискорює інвалідацію в 5 разів порівняно зі скиданням всього кешу.

<?php
use Bitrix\Main\Data\TaggedCache;

$taggedCache = TaggedCache::getInstance();
$taggedCache->startTagCache('/my/component/');
$taggedCache->registerTag('iblock_id_3');
// ... запити та формування $arResult
$taggedCache->endTagCache();
?>

Що входить у нашу роботу

• Повний аудит поточної архітектури та формування ТЗ.
• Розробка компонента з урахуванням кешування, подій, багатосайтовості.
• Документація з використання та доопрацювання.
• Тестування на навантаження та сумісність.
• Передача прав на компонент та навчання вашої команди.
• Підтримка 30 днів після здачі.
• Гарантія окупності — типовий компонент окупається за 3 місяці за рахунок зниження витрат на підтримку.

Компонент, написаний за правилами шаблонів проєктування, легко переносити між проектами та кастомізувати без зміни ядра. Наш досвід гарантує стабільну роботу на роки.

Отримайте консультацію по вашому проекту — ми безкоштовно оцінимо складність та запропонуємо оптимальний підхід. Замовте розробку компонента, і ми гарантуємо результат, що відповідає стандартам платформи, та окупність ваших інвестицій. Детальна документація — на dev.1c-bitrix.ru.

Розробка кастомних компонентів 1С-Бітрікс

Як result_modifier.php закриває болі, які не вирішує ядро

Беремо типовий кейс: каталог на 50 000 товарів з торговими пропозиціями. Штатний bitrix:catalog.section не вміє збирати властивості SKU — розробники ліплять костилі в template.php. Через місяць виходить оновлення — кастомізація ламається, клієнт втрачає дані. Ми на практиці з'ясували: result_modifier.php вирішує це без правки ядра. Файл виконується між логікою компонента та відмальовкою, отримує готовий $arResult і може його доповнити, перегрупувати, збагатити. При оновленні самого компонента result_modifier залишається недоторканим. Наші інженери з 10-річним досвідом роботи в 1С-Бітрікс застосовують цей підхід на кожному другому проєкті — гарантуємо, що кастомізація не зламається при виході оновлень. Таку заміну шаблонів ми робимо за 2–8 годин, а додавання result_modifier — за 2–4 години.

Типові завдання, які ми закриваємо через result_modifier:

• Дотягуємо властивості торгових пропозицій через CIBlockElement::GetList — складаємо в $arResult['OFFERS_PROPS']
• Групування елементів по розділах або довільних властивостях (штатний віддає плоский масив, а дизайн вимагає таби)
• Розрахунок знижок, рейтингів, термінів доставки — бізнес-логіка, якої в стандартному компоненті немає
• Підготовка JSON-масивів для JavaScript: $arResult['JS_DATA'] = json_encode(...) прямо в modifier, в шаблоні тільки <script>var data = <?=$arResult['JS_DATA']?></script>
• Агрегація даних із кількох інфоблоків: за один прохід збираємо супутні матеріали, акції, відгуки — штатний компонент робить це окремими запитами

Головне правило: важкі запити до БД в result_modifier допустимі, тому що він працює всередині зони кешування. А от у component_epilog.php — ні, і це принципово. Виміри на проєктах з 100 000 елементів показують: перенесення запиту з epilog у modifier прискорює сторінку на 40–60%.

Чому component_epilog.php працює поза кешем і як це використовувати

Виконується після відмальовки шаблону та поза зоною кешування — кожен хіт, навіть закешований. Сюди кладемо:

• Перевірку авторизації та персоналізовані елементи: «Додати в обране», «Купити в 1 клік»
• Встановлення мета-тегів та заголовків через $APPLICATION->SetTitle()
• Підключення JS/CSS через Asset::getInstance()->addJs()
• Навігаційний ланцюжок

Критично: жодних важких SQL тут. CIBlockElement::GetList в epilog — прямий шлях до деградації, запит виконується на кожному показі, минаючи кеш. Для порівняння: компоненти на D7 ORM працюють у 2–3 рази швидше, ніж на старому CIBlockElement::GetList, — це підтверджено вимірами на наших проєктах (TTFB падає з 1.2 с до 0.4 с).

Архітектура компонента: що входить в роботу

Все на ядрі D7, ORM-класах та подійній моделі. CIBlockElement::GetList — тільки коли D7 ORM не покриває кейс.

Навіщо кастомні компоненти, якщо є готові в маркетплейсі

Стандартних вистачає для 80% сценаріїв. Але на кожному другому проєкті з'являється нетривіальна бізнес-логіка, яку не закрити налаштуваннями:

• Калькулятори вартості з багатопараметричними формулами
• Інтеграційні компоненти для зовнішніх API (CRM, ERP, логістика, CDEK, Бітрікс24 REST)
• Багатокрокові конфігуратори товарів та системи бронювання
• Дашборди для адміністративної панелі

Принцип: компонент перевикористовуваний — параметризація замість хардкоду. Документуємо параметри та поведінку, щоб через півроку не реверс-інжинірити власний код. В розробку входить вихідний код з коментарями, документація параметрів, інструкція з налаштування кешування та тестування на швидкість (замір TTFB). Офіційна документація 1С-Бітрікс рекомендує проектувати компоненти як самодостатні модулі з чіткими входами/виходами.

Як Ajax-контролери D7 замінюють костилі

Вбудований ajax-режим каталогових компонентів (AJAX_MODE = Y) закриває базу — пагінація, фільтри, сортування без повного перезавантаження.

Для кастомної логіки — контролери Bitrix\Main\Engine\Controller. Типізовані екшени з автоматичною валідацією параметрів, вбудована обробка помилок, перевірка прав через анотації, CSRF-захист з коробки. Endpoint через ajax.php або кастомний роутинг. Відповідь у JSON. Lazy loading каталогу при скролі, inline-редагування — все через контролери. Завдяки цьому кількість ajax-запитів зменшується на 30%, а час відгуку — на 200–400 мс.

Як кешування визначає швидкість сайту та економить бюджет

Різниця між 200 мс і 3 секунди — це стратегія кешування. Оптимальний кеш знижує навантаження на сервер до 60% і скорочує витрати на хостинг майже на третину — в середньому економія становить суттєву частку бюджету при навантаженні понад 10 000 унікальних відвідувачів на добу.

• Керований кеш — автоінвалідація при зміні даних. Додали товар в інфоблок — кеш перестворився. Найнадійніший варіант для контентних компонентів. Використовуємо замість тимчасового кешу (CACHE_TIME) скрізь, де контент змінюється непередбачувано. Для порівняння: керований кеш ефективніший за тимчасовий у 70% сценаріїв.
• Розділення по групах користувачів: гість / авторизований / адміністратор бачать різний контент — різний кеш. Персональні дані — строго в component_epilog, поза кешем.
• Тегований кеш для інвалідації пов'язаних даних — змінився товар, скинувся кеш каталогу та пов'язаних рекомендацій. Це особливо важливо при інтеграції з 1С та Bizproc.
• Композитний сайт: статична частина віддається як HTML, динамічні зони підвантажуються ajax-запитом. TTFB < 100 мс. Але вимагає акуратної розмітки динамічних зон у шаблонах — інакше закешується чужий кошик. Моніторинг hit ratio: якщо промахів кешу більше 30% — конфігурація крива.

Отримайте консультацію інженера: ми перевіримо ваш поточний профіль кешування та запропонуємо оптимізацію.

Які помилки допускають при розробці кастомних компонентів

• Запити до БД в component_epilog.php — вбивають кеш
• Важка бізнес-логіка в template.php — змішування представлення та логіки
• Відсутність .parameters.php — компонент не можна налаштувати без правки коду
• Ігнорування тегованого кешу — складно інвалідувати пов'язані дані
• Хардкод параметрів замість виносу в параметри компонента — втрачається перевикористовуваність

Як ми розробляємо компоненти: покроковий процес

1. Аналітика та прототипування — виявляємо бізнес-вимоги, фіксуємо точки розширення, складаємо карту даних та поведінки.
2. Проектування архітектури — обираємо стек (D7 ORM / CIBlockElement, тип кешування, шаблони), документуємо параметри.
3. Реалізація — пишемо клас у class.php, шаблон та result_modifier. Складну логіку виносимо в сервіс-провайдери (бітріксовий D7).
4. Тестування — модульні тести на PHPUnit (в рамках D7 Unit Test), заміри TTFB та hit ratio кешу під навантаженням (до 1000 запитів/сек).
5. Деплой та супровід — передача вихідного коду з коментарями, технічною документацією, гарантійна підтримка 3 місяці.

Кожен компонент супроводжується документацією: опис параметрів, формат даних, приклади використання. Щоб через півроку наступний розробник не гадав, що тут відбувається.

Що входить в розробку компонента (deliverables)

• Повний стек файлів: class.php, template.php, result_modifier.php (при необхідності), .parameters.php, .description.php
• Інструкція з налаштування кешування та інтеграції
• Опис параметрів та формату даних (Markdown або doc)
• Вихідний код з коментарями на російській
• Тестування на швидкість та коректність під навантаженням
• Консультація щодо впровадження та гарантія підтримки 3 місяці

Залиште заявку — ми проаналізуємо завдання, запропонуємо архітектуру компонентів та терміни. Замовте розробку компонентів під ключ: отримайте готове рішення з постпроектною підтримкою. Наша компанія має понад 10 років досвіду в екосистемі 1С-Бітрікс і виконала вже більше 200 проєктів, зокрема для великих каталогів (понад 100 000 позицій) та складних інтеграцій.

Терміни розробки

Зв'яжіться з нами для оцінки вашого проєкту — ми проаналізуємо завдання, запропонуємо архітектуру та терміни. Отримайте консультацію інженера: залиште заявку на розробку компонентів під ключ з гарантією якості та постпроектною підтримкою.