Разработка системы управления меню сайта под ключ

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

Для типов 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}"); } } 

Мультиязычность реализована через отдельные записи menus с полем locale. Кеш разделяется по языку, поэтому переключение языка не влияет на производительность. При изменении slug страницы URL в меню обновляется автоматически — это обеспечивает целостность навигации.

Процесс работы

1. Аналитика — изучаем типы меню, количество пунктов, частоту обновлений
2. Проектирование — описываем модель, согласуем интерфейс
3. Разработка — пишем код параллельно с тестами
4. Тестирование — проверяем на N+1, кеш, производительность
5. Деплой — разворачиваем в прод, настраиваем CI/CD

Срок разработки: от 2 до 5 дней в зависимости от сложности. Стоимость рассчитывается индивидуально — пишите, оценим проект за один рабочий день.

Получите консультацию: свяжитесь с нами, и мы покажем, как ваша команда сможет управлять меню без программистов. Закажите разработку системы управления меню.