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

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

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