Розробка 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. Отримайте консультацію щодо впровадження вже сьогодні.