Розробка фронтенду на Next.js для 1С-Бітрікс

Розробка фронтенду на Next.js для 1С-Бітрікс

Bitrix-моноліт з PHP-шаблонами вирішує 80% завдань. Решта 20% — високонавантажені сторінки, SEO для динамічного контенту, PWA, персоналізація з edge computing — вимагають іншої архітектури. Next.js як фронтенд поверх Бітрікс-бекенду — це headless-підхід: Бітрікс керує контентом і бізнес-логікою, Next.js займається рендерингом.

Це не заміна Бітрікс, а розподіл відповідальності: Бітрікс — надійний бекенд для e-commerce (замовлення, каталог, CRM, оплати), Next.js — сучасний фронтенд з SSR, SSG, ISR та відмінними Core Web Vitals.

Архітектура headless Бітрікс + Next.js

Бітрікс виступає у ролі API-сервера. На його стороні розробляються REST-контролери через \Bitrix\Main\Engine\Controller або кастомні endpoint'и у /local/ajax/.

Next.js працює на окремому сервері (Node.js), споживає Бітрікс API і рендерить сторінки. Між ними — API-шар.

Browser → Next.js (SSR/SSG) → Bitrix REST API → DB
                            ↓
                       Redis Cache

Типова схема запитів:

// next.js: getStaticProps для сторінки категорії
export async function getStaticProps({ params }) {
  const [category, products] = await Promise.all([
    fetchBitrix(`/api/catalog/category/${params.slug}`),
    fetchBitrix(`/api/catalog/products?section=${params.slug}&limit=24`),
  ]);

  return {
    props:      { category, products },
    revalidate: 300, // ISR: перегенерація через 5 хвилин
  };
}

Incremental Static Regeneration (ISR) — ключова фіча Next.js для e-commerce: сторінки генеруються статично при першому запиті та перегенеровуються у фоні за розкладом. Це дає швидкість статики при актуальності динамічного контенту.

API на стороні Бітрікс

Створення чистого REST API поверх Бітрікс без зайвих залежностей:

// /local/php_interface/include/api/catalog/ProductsController.php
class ProductsController extends \Bitrix\Main\Engine\Controller
{
    public function getListAction(
        string $section = '',
        int    $page    = 1,
        int    $limit   = 24,
        string $sort    = 'NAME',
        string $order   = 'ASC'
    ): array {
        $filter = ['ACTIVE' => 'Y', 'IBLOCK_ID' => CATALOG_IBLOCK_ID];
        if ($section) {
            $sectionId = $this->getSectionIdBySlug($section);
            $filter['SECTION_ID'] = $sectionId;
            $filter['INCLUDE_SUBSECTIONS'] = 'Y';
        }

        $result = \CIBlockElement::GetList(
            [$sort => $order],
            $filter,
            false,
            ['nPageSize' => $limit, 'iNumPage' => $page],
            ['ID', 'NAME', 'DETAIL_PAGE_URL', 'PREVIEW_PICTURE',
             'PROPERTY_BRAND', 'CATALOG_PRICE_1']
        );

        $products = [];
        while ($el = $result->GetNextElement()) {
            $products[] = $this->formatProduct($el);
        }

        return [
            'items' => $products,
            'total' => (int)$result->SelectedRowsCount(),
            'pages' => ceil($result->SelectedRowsCount() / $limit),
        ];
    }
}

API має повертати нормалізовані дані, а не сирі Бітрікс-структури з смітниковими полями ~PREVIEW_TEXT і IBLOCK_ELEMENT_ID.

SSR для SEO-критичних сторінок

Картки товарів, сторінки категорій, статті блогу — кандидати на SSG/ISR. Кошик, чекаут, особистий кабінет — CSR (рендеринг на клієнті), SEO не потрібен.

// Динамічна генерація шляхів для товарів
export async function getStaticPaths() {
  const products = await fetchBitrix('/api/catalog/products/slugs');

  return {
    paths:    products.map(p => ({ params: { slug: p.slug } })),
    fallback: 'blocking', // нові товари рендеряться при першому запиті
  };
}

fallback: 'blocking' дозволяє обробляти нові товари без повної перегенерації сайту.

Кейс: Next.js фронтенд для fashion-рітейлера

Мережа магазинів одягу, онлайн-каталог ~35 000 SKU, сезонне поповнення. Проблема: Core Web Vitals LCP = 4,8 сек (ціль < 2,5 сек), Бітрікс-шаблон важкий, повільний на мобільних.

Бітрікс залишили як бекенд: управління товарами, замовлення, CRM, 1С-інтеграція. Розробили Next.js фронтенд.

Реалізація:

1. API Бітрікс: контролери для товарів, категорій, брендів, пошуку, кошика (SSR-сумісний через cookie-сесію).

2. Next.js App Router (Next.js 14): Server Components для SEO-сторінок, Client Components для інтерактивних елементів (фільтр, кошик, авторизація).

3. Зображення: next/image з автоматичною оптимізацією, WebP, responsive srcset. Хостинг зображень через CDN (окремо від Бітрікс).

4. Пошук: Meilisearch з індексом з Бітрікс, React-компонент instant search.

5. Кошик: state у Zustand + синхронізація з Бітрікс-кошиком через REST API при кожній зміні.

Перехід зайняв 4 місяці: 1 місяць на API Бітрікс, 3 місяці на Next.js фронтенд. Паралельно працював старий шаблон, перемикання — через DNS за хвилину.

Управління станом кошика у Next.js

Кошик — складний випадок при headless: він має працювати до авторизації, синхронізуватися з Бітрікс при авторизації, не губитися при переході між сторінками.

Рішення: guest_token у cookie, кошик зберігається у Бітрікс за цим токеном. При авторизації — злиття гостьового кошика з користувацьким. React-стан — лише UI-дзеркало серверного кошика.

Деплой та інфраструктура

Next.js — Node.js-застосунок, що вимагає окремого процесу. Варіанти: Vercel (найпростіше, але дані виходять за кордон), VPS/dedicated з PM2 + nginx, Docker-контейнер.

Nginx як reverse proxy перед Next.js і Бітрікс:

# Статика і SEO-сторінки → Next.js
location / {
    proxy_pass http://nextjs:3000;
}

# REST API → Бітрікс
location /api/bitrix/ {
    proxy_pass http://bitrix/local/ajax/;
}

# Адміністративна частина → Бітрікс
location /bitrix/ {
    proxy_pass http://bitrix;
}

Склад робіт

• Проєктування API: ендпоінти, схема даних, кешування
• Розробка REST-контролерів у Бітрікс
• Розробка Next.js застосунку: роутинг, SSG/ISR/SSR, компоненти
• Інтеграція кошика, авторизації, чекауту з Бітрікс
• Налаштування CDN для зображень, кешування на рівні nginx
• Деплой, моніторинг, CI/CD

Терміни: MVP (каталог + картка + пошук) — 2–3 місяці. Повний фронтенд із кошиком, чекаутом, кабінетом — 4–6 місяців.