Розробка decoupled-фронтенду для 1С-Бітрікс
Ми розробляємо decoupled-фронтенд для 1С-Бітрікс: фізично відокремлюємо інтерфейс від CMS, зберігаючи керованість та можливість поступової міграції. Вирішуємо проблему, коли стандартний шаблон Бітрікса впирається в стелю продуктивності, а повний редизайн надто ризикований та затратний. Decoupled-підхід дає вам сучасний UX (React/Vue, SPA, SSR) без зупинки бізнесу — ми замінюємо лише критичні сторінки, залишаючи адмінку та SEO-сторінки на CMS.
Чому decoupled, а не headless?
Headless — це коли весь сайт тримається на API, а CMS — лише бекенд. Це вимагає повної перебудови архітектури. Decoupled — золота середина: ви обираєте, які сторінки віддавати через SPA, а які залишити на шаблонах Бітрікса. Наприклад, каталог товарів може бути React-додатком, а контентні сторінки — як і раніше генеруватися CMS. Порівняння:
| Параметр | Traditional (шаблон Бітрікса) | Decoupled | Headless |
|---|---|---|---|
| Продуктивність UI | Середня (php-рендер) | Висока (SPA) | Висока (SPA) |
| Складність впровадження | Низька | Середня | Висока |
| Швидкість впровадження | Миттєво | 2-4 тижні на компонент | 2+ місяці |
| SEO-сумісність | Повна | Часткова (потрібен SSR) | SSR обов'язковий |
| Ризики | Низькі | Низькі (поетапно) | Високі |
Decoupled-фронтенд на 30% швидше впроваджується порівняно з headless, при цьому дає 90% приросту продуктивності інтерфейсу. При цьому ви зберігаєте існуючі бітріксові модулі та бізнес-логіку — не потрібно переписувати інфоблоки, агенти та події.
Як синхронізувати кошик між Бітрікс та React?
Найчастіший біль при decoupled — кошик. Іконка в шапці (шаблон Бітрікса) повинна відображати актуальну кількість товарів, доданих через React-каталог. Рішення — Event Bus, доступний в обох світах:
// shared/eventBus.js — доступний і в частині Бітрікса, і в React
window.BitrixEventBus = {
listeners: {},
emit(event, data) {
(this.listeners[event] || []).forEach(cb => cb(data));
},
on(event, callback) {
(this.listeners[event] ||= []).push(callback);
}
};
// У React-компоненті при додаванні в кошик:
window.BitrixEventBus.emit('cart:updated', { count: newCount });
// У шаблоні Бітрікса (шапка):
window.BitrixEventBus.on('cart:updated', ({ count }) => {
document.querySelector('.cart-counter').textContent = count;
});
Цей же патерн застосовується для синхронізації обраного, сповіщень та будь-яких інших глобальних станів. Докладніше про REST API Бітрікс24 читайте в офіційній документації.
Патерн «острів» — часткова інтеграція фронтенду
Замість повного відокремлення фронтенду ви вбудовуєте React-компоненти в існуючий шаблон Бітрікса через точки монтування:
// У шаблоні компонента каталогу Бітрікса
$catalogData = json_encode($arResult['ITEMS']);
?>
<div id="react-catalog"
data-items="<?= htmlspecialchars($catalogData) ?>"
data-currency="UAH">
</div>
<script src="/local/js/dist/catalog.bundle.js"></script>
<script>
window.BitrixCatalog && window.BitrixCatalog.mount(
document.getElementById('react-catalog'),
<?= $catalogData ?>
);
</script>
// catalog.bundle.js — збирається Webpack/Vite незалежно
import { createRoot } from 'react-dom/client';
import { CatalogApp } from './CatalogApp';
window.BitrixCatalog = {
mount(container, initialData) {
const root = createRoot(container);
root.render(<CatalogApp initialData={initialData} />);
}
};
Цей підхід дозволяє розробляти фронтенд на React з повноцінним toolchain (TypeScript, hot reload, тести) і при цьому не чіпати решту сайту на Бітріксі.
Приклад: каталог товарів на React
Припустимо, потрібно замінити стандартний компонент каталогу Бітрікса на SPA з миттєвою фільтрацією. Ми створюємо API-ендпоінт, який віддає товари в JSON. React-додаток отримує дані та рендерить на клієнті. Серверна частина залишається на Бітрікс — інфоблоки, ціни, залишки. Це знижує час завантаження сторінки на 40–60% і збільшує конверсію на 15–25%.
Конфігурація збірки (Vite)
// vite.config.js для decoupled-компонентів Бітрікса
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
export default defineConfig({
plugins: [react()],
build: {
outDir: '../public/local/js/dist',
lib: {
entry: './src/index.tsx',
name: 'BitrixComponents',
formats: ['iife'],
fileName: 'components',
},
rollupOptions: {
external: [],
},
},
server: {
cors: true,
port: 3000,
proxy: {
'/api': {
target: 'http://site.local',
changeOrigin: true,
}
}
},
});
У режимі розробки Vite dev-сервер запускається на localhost:3000, а сайт на Бітріксі — на site.local. Звернення до API з dev-сервера проксуються через Vite proxy. Після збірки білд автоматично синхронізується з сервером.
Порівняння термінів впровадження компонентів
| Компонент | Термін (тижні) | Складність |
|---|---|---|
| Каталог | 3–4 | Середня |
| Кошик | 2–3 | Низька |
| Особистий кабінет | 4–6 | Висока |
| Оформлення замовлення | 2–3 | Середня |
Що входить в роботу
- Аудит поточної архітектури сайту на Бітріксі та виявлення кандидатів на decoupled
- Розробка API-прошарку (REST/GraphQL) між Бітріксом та новим фронтендом
- Реалізація 2–3 компонентів за патерном «острів» (каталог, кошик, особистий кабінет)
- Налаштування CI/CD для автоматичної збірки та деплою фронтенду
- Інтеграція Event Bus для синхронізації стану
- Документація по точках монтування та API
- Тестування продуктивності (заміри до/після)
Процес роботи
- Аналітика — вивчаємо існуючий сайт, навантаження, вузькі місця. Визначаємо, які сторінки замінити в першу чергу.
- Проектування — обираємо стек (React/Vue), проектуємо API, опрацьовуємо архітектуру компонентів.
- Реалізація — пишемо код паралельно з вашою командою. Щотижневі демо.
- Тестування — навантажувальні тести, регресія за функціоналом Бітрікса.
- Деплой — викочуємо поетапно, моніторимо помилки. Передбачений відкат на 24 години.
Технічні вимоги до серверної частини
- PHP 8.1+ - MySQL 8.0+ - Модуль mod_rewrite для REST API - Налаштоване кешування теговане - CORS дозволений для домену фронтенду - Необхідні розширення PHP описані в офіційних рекомендаціях БітріксаТерміни орієнтовно
Від 2 тижнів на один компонент до 2 місяців на повний перехід під ключ. Вартість розраховується індивідуально після аудиту — напишіть, оцінимо ваш проект.
Типові помилки при decoupled
- Повне копіювання дизайну в React — програєте в продуктивності через зайві перемальовки.
- Відсутність версіонування бандлів — браузер кешує старі скрипти. Використовуйте хеші:
catalog.a1b2c3.js. - Синхронізація стану через HTTP замість Event Bus — зайві затримки.
- Забути про SEO: якщо SPA не віддає HTML, пошуковики не побачать сторінки. Використовуйте SSR або prerendering.
- Не налаштувати проксі для розробки — фронтенд не зможе звертатися до API Бітрікса.
Маємо 10+ років досвіду з Бітріксом, сертифікати «1С-Бітрікс» та більше 50 успішних проектів. Даємо гарантію на всі роботи за договором. Замовте аудит вашого проекту — ми підберемо оптимальну архітектуру decoupled. Отримайте консультацію щодо впровадження вже сьогодні.