Менеджеры регулярно просят добавить новый пункт в меню — каждый запрос превращается в задачу для разработчика, тормозит релизы и отвлекает команду от основного функционала. Мы спроектировали систему управления меню, которая решает эту проблему: правки вносятся за минуты без привлечения программистов. За 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 дней в зависимости от сложности. Стоимость рассчитывается индивидуально — пишите, оценим проект за один рабочий день.
Получите консультацию: свяжитесь с нами, и мы покажем, как ваша команда сможет управлять меню без программистов. Закажите разработку системы управления меню.