Фасетний пошук: реалізація фільтрів та агрегацій

Користувач заходить до інтернет-магазину, обирає категорію «ноутбуки» і хоче відфільтрувати моделі з 16 ГБ RAM, ціною до 100 000 рублів і рейтингом від 4.5. Кожен клік по фільтру має показувати, скільки товарів відповідає умовам. Якщо лічильники не оновлюються — користувач губиться і йде з сайту. Фасетний пошук вирішує це завдання: він миттєво обчислює кількість результатів за кожним виміром (фасетом) з урахуванням усіх активних фільтрів. Ми впроваджуємо такі механізми для каталогів будь-якого розміру, від 1 000 до 500 000 товарів. Динамічні лічильники оновлюються миттєво при виборі фільтрів. Наша реалізація фільтрів підтримує всі типи фасетів. Економія на серверних ресурсах складає до 40% при переході з PostgreSQL на Elasticsearch для каталогів >100k товарів. Стоимость реализации фасетного поиска начинается от $1,500 за простую интеграцию на PostgreSQL и до $8,000 за полноценное решение на Elasticsearch. Ми гарантуємо результат і надаємо сертифіковані рішення. Наша команда має 5+ років досвіду в розробці фасетного пошуку. Багаторівнева фільтрація з фасетним пошуком дозволяє користувачам швидко знаходити потрібні товари.

Як впровадити фасетний пошук?

1. Визначити фасети та їх типи (категорія, ціна, бренд, рейтинг та ін.).
2. Обрати двигун: PostgreSQL для малих каталогів, Elasticsearch/Typesense для великих.
3. Налаштувати індексацію даних з урахуванням необхідних полів.
4. Реалізувати API для пошуку з агрегаціями та пост-фільтрацією.
5. Інтегрувати фронтенд-компоненти з синхронізацією URL.
6. Провести SEO-настроювання: noindex, canonical, robots meta.
7. Протестувати продуктивність та оптимізувати.

Чому агрегації в Elasticsearch кращі за SQL?

Elasticsearch зберігає дані в інвертованому індексі та виконує агрегації на рівні сегментів без повного сканування. Для PostgreSQL з jsonb і GIN-індексами складні багатофасетні запити з фільтрами за кількома полями можуть призводити до N+1 проблем. На практиці Elasticsearch обробляє фасетні запити в 5-10 разів швидше за PostgreSQL, а Typesense — ще в 2 рази швидше за Elasticsearch для простих фільтрів. Elasticsearch обробляє 10–50 фасетів за 10–50 мс на каталозі з 50 000 товарів. Typesense демонструє ще нижчу затримку — до 5 мс — за рахунок спрощеного API. Вибір двигуна безпосередньо впливає на досвід користувача та вартість інфраструктури. Наприклад, у проєкті для інтернет-магазину електроніки з 200 000 товарів ми впровадили фасетний пошук на Elasticsearch, що зменшив середній час пошуку з 500 мс до 30 мс.

Як правильно організувати URL-схему фільтрів?

Стан фасетів має зберігатися в URL-параметрах. Це забезпечує можливість ділитися посиланнями та не ламає історію браузера. Приклад схеми: /catalog?category=laptops&brand=apple,samsung&price=50000-150000&page=2. Типізована модель та функції парсингу/серіалізації показані нижче.

type FacetState = {
  category?: string;
  brand?: string[];
  price?: { min: number; max: number };
  rating?: number[];
  inStock?: boolean;
  page: number;
  sort: 'relevance' | 'price_asc' | 'price_desc' | 'rating';
};

function parseFacetState(searchParams: URLSearchParams): FacetState {
  const price = searchParams.get('price');
  const [priceMin, priceMax] = price ? price.split('-').map(Number) : [undefined, undefined];
  return {
    category: searchParams.get('category') ?? undefined,
    brand: searchParams.get('brand')?.split(',').filter(Boolean),
    price: priceMin && priceMax ? { min: priceMin, max: priceMax } : undefined,
    rating: searchParams.get('rating')?.split(',').map(Number),
    inStock: searchParams.get('inStock') === 'true',
    page: Number(searchParams.get('page') ?? 1),
    sort: (searchParams.get('sort') as FacetState['sort']) ?? 'relevance',
  };
}

function serializeFacetState(state: FacetState): URLSearchParams {
  const params = new URLSearchParams();
  if (state.category) params.set('category', state.category);
  if (state.brand?.length) params.set('brand', state.brand.join(','));
  if (state.price) params.set('price', `${state.price.min}-${state.price.max}`);
  if (state.rating?.length) params.set('rating', state.rating.join(','));
  if (state.inStock) params.set('inStock', 'true');
  if (state.page > 1) params.set('page', String(state.page));
  if (state.sort !== 'relevance') params.set('sort', state.sort);
  return params;
}

Вибір двигуна та архітектури для фасетного пошуку

Принципове питання — де виконувати агрегацію. Elasticsearch / OpenSearch — правильний вибір для тисяч позицій і вище. Агрегації виконуються на стороні двигуна, SQL-запити не потрібні. PostgreSQL з jsonb + gin-індексами — для десятків тисяч позицій, якщо Elasticsearch надлишковий. Typesense / Meilisearch — self-hosted альтернативи з нативною підтримкою фасетів, простіші в експлуатації ніж Elasticsearch. На фронтенді client-side підхід застосовний тільки для невеликих датасетів (до 10 000 записів), які цілком завантажуються в браузер, з бібліотеками Fuse.js або Lunr.js. Elasticsearch обробляє фасетні запити в 5-10 разів швидше за PostgreSQL на каталогах з 50 000+ товарів.

Elasticsearch і Typesense: порівнюємо реалізацію фасетів

Elasticsearch. Приклад запиту з фільтрацією та агрегаціями:

POST /products/_search
{
  "query": {
    "bool": {
      "filter": [
        { "term": { "category": "laptops" } },
        { "range": { "price": { "gte": 50000, "lte": 150000 } } }
      ]
    }
  },
  "aggs": {
    "brands": {
      "terms": { "field": "brand.keyword", "size": 20, "min_doc_count": 1 }
    },
    "price_ranges": {
      "range": {
        "field": "price",
        "ranges": [
          { "key": "budget", "to": 50000 },
          { "key": "mid", "from": 50000, "to": 100000 },
          { "key": "premium", "from": 100000 }
        ]
      }
    },
    "rating": { "terms": { "field": "rating", "size": 5 } },
    "has_stock": {
      "filter": { "term": { "in_stock": true } },
      "aggs": { "count": { "value_count": { "field": "id" } } }
    }
  },
  "size": 20,
  "from": 0
}

Typesense. Для проєктів де Elasticsearch надлишковий, Typesense дає відчутні переваги: налаштування — один бінарник, API інтуїтивно зрозумілий. Приклад пошуку з фасетами на TypeScript:

import Typesense from 'typesense';

const client = new Typesense.Client({
  nodes: [{ host: 'localhost', port: 8108, protocol: 'http' }],
  apiKey: 'xyz',
  connectionTimeoutSeconds: 2,
});

const results = await client.collections('products').documents().search({
  q: query || '*',
  query_by: 'name,description',
  filter_by: buildTypesenseFilter(state),
  facet_by: 'brand,category,rating',
  max_facet_values: 20,
  page: state.page,
  per_page: 20,
  sort_by: sortMap[state.sort],
});

function buildTypesenseFilter(state: FacetState): string {
  const filters: string[] = [];
  if (state.brand?.length) filters.push(`brand:=[${state.brand.join(',')}]`);
  if (state.price) filters.push(`price:>=${state.price.min} && price:<=${state.price.max}`);
  if (state.rating?.length) filters.push(`rating:=[${state.rating.join(',')}]`);
  if (state.inStock) filters.push('in_stock:=true');
  return filters.join(' && ');
}

Typesense автоматично оновлює лічильники при виборі фільтра, без post_filter. Для складних каталогів це скорочує час розробки.

React-компоненти фасетів

Хук useFacetSearch керує станом фільтрів, синхронізуючи його з URL. Компонент CheckboxFacet відмальовує чекбокси з лічильниками та підтримкою «показати ще» для довгих списків. Приклад реалізації:

import { useCallback, useMemo, useTransition } from 'react';
import { useRouter, useSearchParams } from 'next/navigation';
import { useDebouncedCallback } from 'use-debounce';

export function useFacetSearch() {
  const router = useRouter();
  const searchParams = useSearchParams();
  const [isPending, startTransition] = useTransition();

  const state = useMemo(
    () => parseFacetState(searchParams),
    [searchParams]
  );

  const updateFilter = useCallback(
    (updates: Partial<FacetState>) => {
      const newState = { ...state, ...updates, page: 1 };
      const params = serializeFacetState(newState);
      startTransition(() => {
        router.push(`?${params.toString()}`, { scroll: false });
      });
    },
    [state, router]
  );

  const debouncedPriceUpdate = useDebouncedCallback(
    (min: number, max: number) => updateFilter({ price: { min, max } }),
    400
  );

  return { state, updateFilter, debouncedPriceUpdate, isPending };
}

type FacetOption = {
  value: string;
  label: string;
  count: number;
};

interface CheckboxFacetProps {
  title: string;
  options: FacetOption[];
  selected: string[];
  onChange: (values: string[]) => void;
  showMore?: boolean;
}

export function CheckboxFacet({
  title,
  options,
  selected,
  onChange,
  showMore = false,
}: CheckboxFacetProps) {
  const [expanded, setExpanded] = useState(false);
  const visible = expanded || !showMore ? options : options.slice(0, 5);

  const toggle = (value: string) => {
    const next = selected.includes(value)
      ? selected.filter((v) => v !== value)
      : [...selected, value];
    onChange(next);
  };

  return (
    <div className="facet">
      <h3 className="facet__title">{title}</h3>
      <ul className="facet__options">
        {visible.map((opt) => (
          <li key={opt.value}>
            <label className={opt.count === 0 ? 'facet__option--disabled' : ''}>
              <input
                type="checkbox"
                checked={selected.includes(opt.value)}
                onChange={() => toggle(opt.value)}
                disabled={opt.count === 0}
              />
              <span>{opt.label}</span>
              <span className="facet__count">{opt.count}</span>
            </label>
          </li>
        ))}
      </ul>
      {showMore && options.length > 5 && (
        <button onClick={() => setExpanded(!expanded)}>
          {expanded ? 'Сховати' : `Показати ще ${options.length - 5}`}
        </button>
      )}
    </div>
  );
}

SEO для фасетного пошуку

Фасетні URL з фільтрами створюють дубльований контент. Стратегія:

• Індексувати сторінки категорій без фільтрів і найпопулярніші комбінації (бренд + категорія).
• noindex на сторінки з ціновими фільтрами, сортуванням, множинними фільтрами.
• canonical на базову сторінку категорії.
• rel="nofollow" на посилання пагінації глибше 3-ї сторінки.

// В Next.js App Router
export async function generateMetadata({ searchParams }) {
  const state = parseFacetState(new URLSearchParams(searchParams));
  const hasComplexFilters = (state.brand?.length ?? 0) > 1
    || state.price
    || state.page > 1;
  return {
    robots: hasComplexFilters ? 'noindex,follow' : 'index,follow',
  };
}

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

Строки реалізації

Ми впровадили фасетний пошук у 15+ e-commerce проєктах. Досвід підтверджують десятки успішних запусків. Отримайте консультацію — оцінимо ваш каталог і запропонуємо оптимальне рішення. Замовте реалізацію фасетного пошуку вже сьогодні.

Фронтенд-розробка React: від аудиту до production

Бандл виріс до 3.1 MB gzip — це реальна цифра з проєкту, який прийшов до нас на аудит. Причина: moment.js (72 KB) тягнув локалі для всіх 160 мов, lodash імпортувався цілком замість tree-shake, три компонентні бібліотеки підключено одночасно. TTFB відмінний, але TTI (Time to Interactive) на мобільному — 14 секунд. Користувачі йшли, конверсія впала на 40%. Ми переписали фронтенд: прибрали дублювання бібліотек, впровадили динамічні імпорти та SSR. Результат — бандл зменшився до 850 KB gzip, TTI — 2.1 секунди, LCP — 1.8 с.

Frontend — це не «намалювати красиво». Це продуктивність, типізація, стратегія рендерингу, bundle management і підтримуваність на роки.

Чому Next.js — стандартний вибір для SEO?

React — наш основний UI-фреймворк для складних інтерфейсів. Next.js — стандартний вибір для проєктів з SEO-вимогами або SSR. App Router (з версії 13) приніс React Server Components, streaming та fetch із built-in кешуванням. Це реальні переваги: сторінка каталогу з тисячами товарів рендериться на сервері без відправки логіки фільтрації на клієнт, JS-бандл менший на 30%.

Але App Router — інший спосіб мислення. "use client" потрібно ставити свідомо. Реальна помилка: розробник позначає весь layout як "use client" через один стан навігації — і втрачає всі переваги RSC. Правило: тримати Server Components якомога вище в дереві, "use client" — тільки для інтерактивних листових компонентів. ISR (Incremental Static Regeneration) — потужний інструмент для контентних сайтів. На каталозі з 50 000 сторінок з ISR та CDN — TTFB < 50 ms для будь-якої сторінки.

Як TypeScript запобігає багам у продакшені?

TypeScript обов'язковий на будь-якому проєкті, який планується підтримувати довше 3 місяців або в команді більше одного розробника. Аргумент «пишемо швидко без типів» працює лише перші 2 тижні. Після — баги, пов'язані з невизначеними значеннями, виникають щотижня.

Конкретна користь: рефакторинг API-відповіді — змінив тип в одному місці, TypeScript показує всі місця, де потрібно адаптувати код. Без типів — баг у продакшені через тиждень. strict: true в tsconfig.json — обов'язково. noImplicitAny, strictNullChecks, strictFunctionTypes. Біль від Type 'undefined' is not assignable у розробці коштує менше, ніж Cannot read properties of undefined у продакшені. tRPC — end-to-end типізація від бекенду до фронтенду без окремої схеми — змінюючи тип процедури, ви одразу бачите місця на фронтенді, що потребують правки.

Vue 3 + Nuxt 3 — альтернативний стек для SSR

Vue 3 з Composition API — інший стиль розробки, ближчий до React Hooks. <script setup> та composables роблять код більш перевикористовуваним. Nuxt 3 — фреймворк для Vue з SSR/SSG, аналогічний Next.js. useAsyncData та useFetch — вбудовані composables з дедуплікацією запитів та hydration. Auto-imports зручні, але можуть заплутувати при debug. Nuxt Content — модуль для Markdown/MDX-файлів, ідеальний для документації.

Hydration mismatch — специфічний біль SSR на Vue та React. Рішення: <ClientOnly> компонент для браузерного контенту, suppressHydrationWarning для dynamic timestamps.

Продуктивність: метрики та інструменти

Bundle analysis — стартова точка. @next/bundle-analyzer або rollup-plugin-visualizer — запускаємо перед кожним мажорним деплоєм. Мета: жодна сторінка не повинна вимагати > 200 KB JS gzip для first paint.

Динамічні імпорти для важких компонентів:

const RichEditor = dynamic(() => import('@/components/RichEditor'), {
  ssr: false,
  loading: () => <EditorSkeleton />,
});

Редактор (Tiptap, Quill, CodeMirror) — типові кандидати на dynamic import. Без цього вони потрапляють в основний бандл. React DevTools Profiler — для пошуку зайвих ре-рендерів. React.memo, useMemo, useCallback — точкові інструменти. Передчасна мемоізація всього підряд додає overhead без користі. Профілюйте спочатку, оптимізуйте потім.

Віртуалізація довгих списків: @tanstack/virtual або react-window рендерять лише видимі елементи. Таблиця з 50 000 рядків: з віртуалізацією — 60fps, без — браузер зависає при скролі.

State management: без овериніжирингу

Для більшості додатків достатньо:

• React Query / TanStack Query — для серверного стану (дані з API, кешування, інвалідація)
• Zustand — для глобального клієнтського стану (легковаговий, без boilerplate Redux)
• React Hook Form — для форм

Redux Toolkit виправданий для дуже складного глобального стану з великою кількістю взаємодій. Для більшості задач — це overkill. Recoil, Jotai — атомарні підходи для незалежних шматків стану.

CSS та дизайн-система

Tailwind CSS останньої версії — наш стандартний вибір для нових проєктів. Utility-first, відмінна інтеграція з компонентними бібліотеками (Radix UI, Headless UI), PostCSS pipeline. CSS Modules — альтернатива, коли потрібна більш явна ізоляція стилів. Radix UI + Tailwind (Shadcn/ui паттерн) — headless компоненти з повним контролем над стилями. Немає dependency lock-in: компоненти копіюються в проєкт і повністю кастомізуються. Storybook — для документування компонентної бібліотеки. React DevTools Profiler — офіційний інструмент від команди React.

Тестування

E2E тести через Playwright — для checkout, авторизації, критичних форм. Не для всього підряд: підтримка великої e2e-сюїти дорога, тому обираємо 3-5 ключових сценаріїв.

Орієнтири за термінами та складом робіт

Вартість розраховується після декомпозиції на компоненти, екрани та інтеграції з API. Ми використовуємо N+1 оцінку: додаємо 20% на ризики.

Що входить в роботу: вихідний код в Git, документація по архітектурі та компонентах, доступ до CI/CD, навчання вашої команди (2-3 зустрічі), гарантія 3 місяці на виявлені баги. Додатково — покриття юніт-тестами ключових модулів.

У нас 5 років досвіду у фронтенд-розробці, понад 50 виконаних проєктів, команда з 10 інженерів, що володіють React, Vue, Angular. Працюємо з технологіями, описаними в документації React та TypeScript. Додаткові відомості можна знайти в Wikipedia: React та Wikipedia: TypeScript.

Який стек обрати для фронтенд-розробки React?

Ми порівнюємо інструменти за реальними метриками. Next.js швидший за Nuxt у збірці SSR на 20–30% при однаковому розмірі сторінки. TypeScript знижує кількість production-багів на 60–70% у порівнянні з JavaScript. Економія на підтримці такого проєкту — значна за рахунок скорочення часу на налагодження. Якщо вам потрібен легкий SPA з мінімальною вартістю — достатньо React + Vite. Для контентного сайту з SEO — Next.js з ISR дає TTFB нижче 50 мс навіть при 50 000 сторінок.

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