Розробка headless-архітектури на 1С-Бітрікс

Розробка headless-архітектури на 1С-Бітрікс

Уявіть: інтернет-магазин на Бітріксі з каталогом 50 000 товарів. Сайт працює, але клієнти просять мобільний додаток, а маркетологи — інтеграцію з маркетплейсами. Стандартні компоненти генерують HTML, який непотрібний для JSON-API. Кожен новий канал вимагає переписування шаблонів, а продуктивність падає. Ми вирішуємо це кардинально — впроваджуємо headless-архітектуру, де Бітрікс стає чистою headless CMS, що віддає дані через REST API.

Headless розділяє бекенд (інфоблоки, торговий каталог, CRM) та незалежний фронтенд. Ви отримуєте мультиканальність: одне джерело даних для вебу, мобільних додатків, PWA та голосових асистентів. І жодної прив'язки до шаблонів Бітрікса. Такий підхід знижує витрати на підтримку — за нашими оцінками, економія на розробці фронтенду становить до 30%.

Чому headless вигідніший за моноліт?

Headless-архітектура на Бітріксі обробляє запити в 3 рази швидше, ніж моноліт, при однаковому навантаженні. Незалежний фронтенд дозволяє оновлювати інтерфейс без перескладання Бітрікса.

Як ми будуємо headless-архітектуру на Бітріксі

REST API шар

Бітрікс не має вбудованого REST API рівня Next.js, тому ми будуємо його двома способами. Рекомендований — роутер через bitrix/routing (версія 20.0 і вище), згідно з офіційною документацією 1С-Бітрікс:

// local/routes/api.php
use Bitrix\Main\Routing\RoutingConfigurator;

return function (RoutingConfigurator $routes) {
    $routes->prefix('api/v1')->group(function (RoutingConfigurator $routes) {
        $routes->get('/catalog', [CatalogController::class, 'index']);
        $routes->get('/catalog/{id}', [CatalogController::class, 'show']);
        $routes->post('/cart/add', [CartController::class, 'add']);
        $routes->post('/order', [OrderController::class, 'create']);
    });
};

Контролери успадковуються від \Bitrix\Main\Engine\Controller і повертають масиви, які Бітрікс автоматично серіалізує в JSON:

// local/controllers/CatalogController.php
class CatalogController extends \Bitrix\Main\Engine\Controller
{
    public function indexAction(int $page = 1, int $limit = 20): array
    {
        $items = \Bitrix\Iblock\Elements\ElementCatalogTable::getList([
            'filter' => ['ACTIVE' => 'Y', 'IBLOCK_ID' => CATALOG_IBLOCK_ID],
            'limit' => $limit,
            'offset' => ($page - 1) * $limit,
        ]);
        return ['items' => $items->fetchAll(), 'page' => $page];
    }
}

Для каталогу одного з інтернет-магазинів ми реалізували 15 endpoint'ів: фільтрація, сортування, ціни зі знижками, залишки по складах. Час відповіді скоротився з 1.2 с до 130 мс після ввімкнення кешування.

Аутентифікація та сесії

Headless ламає стандартну сесійну авторизацію. Використовуємо JWT-токени: користувач авторизується через API, отримує токен і передає його в заголовку Authorization. Бітрікс валідує токен у middleware. Альтернатива — Cookie + CORS, але це складніше в безпеці (потребує CSRF-захисту). Ми рекомендуємо JWT: він простіше масштабується і не потребує прив'язки до домену.

Як налаштувати кешування API?

Без кешування headless-Бітрікс повільний — кожен запит до каталогу будує вибірку з БД. Багаторівневе кешування (Redis + nginx) дає приріст у 10 разів:

public function indexAction(): array
{
    $cacheKey = 'catalog_page_' . $this->getCurrentPage();
    $cache = Cache::createInstance();
    if ($cache->initCache(3600, $cacheKey, '/catalog/')) {
        return $cache->getVars()['data'];
    }
    $data = $this->buildCatalogData();
    $cache->startDataCache();
    $cache->endDataCache(['data' => $data]);
    return $data;
}

Кеш інвалідується при зміні даних інфоблоку через BXClearCache(true, '/catalog/') в обробнику OnAfterIBlockElementUpdate.

CORS та деплой

Розділяємо домени: api.yoursite.ru (Бітрікс) і yoursite.ru (фронтенд на Next.js). Налаштування CORS у nginx:

location /api/ {
    add_header 'Access-Control-Allow-Origin' 'https://yoursite.ru';
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
    add_header 'Access-Control-Allow-Credentials' 'true';
    if ($request_method = 'OPTIONS') {
        return 204;
    }
    fastcgi_pass php-fpm;
}

Типові підводні камені headless-архітектури

Інвалідація кешу

При зміні товару потрібно скинути кеш усіх сторінок каталогу. Ми автоматизуємо це через події Бітрікса: при OnAfterIBlockElementUpdate очищаємо тегований кеш папки '/catalog/'.

Обробка кошика та замовлень

Кошик у headless потребує передачі ідентифікатора сесії в кожному запиті. Використовуємо UUID кошика, прив'язаний до гостя через JWT або cookie.

Складність налагодження

Без HTML-шаблонів складніше локалізувати помилки. Наш чек-лист включає: логування всіх API-запитів, моніторинг часу відповіді, дашборд помилок (Sentry).

Процес роботи та терміни

1. Аудит поточного сайту: інфоблоки, інтеграції, навантаження — 1-2 дні.
2. Проєктування API: специфікація endpoint'ів, схеми даних — 2-3 дні.
3. Розробка API та кешування: реалізація контролерів, middleware, тести — від 1 до 3 тижнів.
4. Налаштування інфраструктури: CORS, nginx, Redis, деплой — 2-3 дні.
5. Інтеграція з фронтендом: спільне тестування з вашою командою — 1 тиждень.

Орієнтовні терміни: від 2 до 6 тижнів. Вартість розраховується індивідуально після аудиту.

Що входить в роботу

• Повна документація API (OpenAPI/Swagger).
• Вихідний код контролерів, middleware, конфігурацій.
• Налаштування кешування та CORS на вашому сервері.
• Інструкція з розгортання та оновлення.
• Навчання ваших розробників (2 години онлайн).
• 2 тижні підтримки після запуску.

Чому це вигідно?

Наша команда має 10+ років досвіду з Бітріксом і 5 років на ринку. Ми реалізували headless-архітектуру для 50+ проєктів, включаючи каталоги з 200 000 товарів і навантаженням 10 000 запитів на хвилину. Економія на підтримці та розробці нових каналів досягає 40%. Гарантуємо стабільну роботу API та повну документацію.

Замовте аудит вашого проєкту — ми оцінимо терміни та вартість за один день. Зв'яжіться з нами для консультації.