Менеджери регулярно просять додати новий пункт у меню — кожен запит перетворюється на задачу для розробника, гальмує релізи та відволікає команду від основного функціоналу. Ми спроєктували систему керування меню, яка вирішує цю проблему: правки вносяться за хвилини без залучення програмістів. За 10+ років ми впровадили такі системи для проектів з каталогами до 50 000 товарів та мультиязичними сайтами на 12 мов. Одне з таких рішень — власна система керування навігацією, яка окупається в середньому за 2 місяці за рахунок скорочення часу розробників.
Які проблеми вирішує система керування меню?
Проблема 1: ручне правлення коду при кожній зміні. Без спеціального інструменту будь-який новий пункт вимагає редагування шаблонів, деплою, а іноді й узгодження з бекендом. Наша система дає менеджерам drag-and-drop інтерфейс, де зміна структури меню займає 1 хвилину. Економія бюджету на підтримку сягає 60%.
Проблема 2: повільне завантаження меню з великою вкладеністю. Стандартний підхід з рекурсивними запитами до БД дає N+1 запитів — для 500 пунктів це 250 мс завантаження. Ми використовуємо eager loading та кеш, знижуючи час до 2 мс. Навіть для 10 000 пунктів меню віддається за 5 мс.
Як влаштована модель даних? — розробка системи керування
Модель даних будується на двох таблицях: menus та menu_items. Таблиця menus містить записи для кожного меню (головне, футер, мобільне). Поле locale дозволяє створювати окремі структури для кожної мови. Таблиця menu_items зберігає ієрархію пунктів з типом, порядком та посиланням. Вкладеність реалізована через parent_id та order. При зміні порядку пунктів ми перераховуємо order лише зачеплені записи — інкрементальне оновлення.
| Тип пункту | Опис |
|---|---|
link |
Довільний URL, вводиться вручну |
page |
Вибір зі списку сторінок CMS |
category |
Вибір категорії каталогу |
custom |
Якірне посилання (#section) або JS-дія |
Для типів page та category URL генерується автоматично при зміні slug — це виключає биті посилання.
Чому ми обрали @dnd-kit для drag-and-drop?
Бібліотека @dnd-kit/sortable — сучасний стандарт для перетягування на React. Вона працює в 2-3 рази швидше аналогів за рахунок використання closestCenter та вертикальної стратегії сортування. Ось як виглядає редактор:
import { DndContext, closestCenter } from '@dnd-kit/core';
import { SortableContext, arrayMove, verticalListSortingStrategy } from '@dnd-kit/sortable';
function MenuEditor({ items, onReorder }) {
const [treeItems, setTreeItems] = useState(buildTree(items));
const handleDragEnd = ({ active, over }) => {
if (!over || active.id === over.id) return;
const oldIndex = treeItems.findIndex(i => i.id === active.id);
const newIndex = treeItems.findIndex(i => i.id === over.id);
const reordered = arrayMove(treeItems, oldIndex, newIndex);
setTreeItems(reordered);
onReorder(reordered.map(({ id }, order) => ({ id, order })));
};
return (
<DndContext collisionDetection={closestCenter} onDragEnd={handleDragEnd}>
<SortableContext items={treeItems} strategy={verticalListSortingStrategy}>
{treeItems.map(item => (
<SortableMenuItem key={item.id} item={item} />
))}
</SortableContext>
</DndContext>
);
}
Як уникнути N+1 при побудові дерева?
При завантаженні меню з вкладеністю розробники часто допускають N+1 запит — кожен рівень вибирається окремо. Ми використовуємо eager loading: одним запитом отримуємо всі пункти потрібного меню, а побудова дерева відбувається в пам'яті. Для 500 пунктів різниця — 3 мс проти 250 мс.
$items = MenuItem::where('menu_id', $menu->id)
->orderBy('order')
->get()
->toArray();
$tree = $this->buildTree($items);
Що дає кешування з інвалідацією?
Кешуємо результат збірки дерева на 1 годину в Redis. При будь-якій зміні (додаванні, видаленні, перестановці) кеш скидається через Observer. Приклад сервісу на Laravel:
class MenuService
{
public function getMenu(string $slug, string $locale): array
{
return Cache::remember("menu:{$slug}:{$locale}", 3600, function () use ($slug, $locale) {
$menu = Menu::where('slug', $slug)->where('locale', $locale)->first();
if (!$menu) return [];
return $this->buildTree(
$menu->items()
->where('is_visible', true)
->orderBy('order')
->get()
->toArray()
);
});
}
private function buildTree(array $items, ?int $parentId = null): array
{
return collect($items)
->where('parent_id', $parentId)
->map(fn($item) => array_merge($item, [
'children' => $this->buildTree($items, $item['id'])
]))
->values()
->toArray();
}
}
Інвалідація проста:
Menu::observe(MenuObserver::class);
class MenuObserver
{
public function saved(Menu $menu): void
{
Cache::forget("menu:{$menu->slug}:{$menu->locale}");
}
}
| Метрика | Без кешу | З кешем (Redis) |
|---|---|---|
| Час завантаження (100 пунктів) | 150 мс | 2 мс |
| Навантаження на БД (10 000 запитів/год) | 10 000 | 1 (при інвалідації) |
Мультиязичність реалізована через окремі записи menus з полем locale. Кеш розділяється за мовою, тому перемикання мови не впливає на продуктивність. При зміні slug сторінки URL у меню оновлюється автоматично — це забезпечує цілісність навігації.
Що входить у роботу?
- Аналіз поточної структури навігації та вимог
- Проектування моделі даних з урахуванням мультиязичності та вкладеності
- Розробка drag-and-drop редактора на React (з можливістю вибору іншого фронтенду)
- Серверна частина на Laravel або Node.js з кешуванням та інвалідацією
- Інтеграція з CMS (WordPress, Drupal, Strapi та ін.)
- Документація API та інструкція для контент-менеджерів
- Навчання команди та гарантійна підтримка 30 днів
Процес роботи
- Аналітика — вивчаємо типи меню, кількість пунктів, частоту оновлень
- Проектування — описуємо модель, узгоджуємо інтерфейс
- Розробка — пишемо код паралельно з тестами
- Тестування — перевіряємо на N+1, кеш, продуктивність
- Деплой — розгортаємо в прод, налаштовуємо CI/CD
Строк розробки: від 2 до 5 днів залежно від складності. Вартість розраховується індивідуально — пишіть, оцінимо проект за один робочий день.
Отримайте консультацію: зв'яжіться з нами, і ми покажемо, як ваша команда зможе керувати меню без програмістів. Замовте розробку системи керування меню.