Разработка административной панели на Filament (Laravel)

Filament админ-панель: что ломается при росте проекта

Самописная админка начинается как один контроллер с формой и списком, а через год в ней живёт весь операционный контур. Права проверяются прямо в шаблоне: условие на роль решает, показывать кнопку или нет. Появилась роль «старший оператор с правом на возврат» — правка уходит в пять файлов, один из которых забывают.

Хаос в правах доступа проявляется в момент инцидента, а не в момент правки. Уволенный сотрудник остаётся активным: учётку гасят в другом сервисе, а здесь только снимают роль. «Тихие» суперпользователи, заведённые на запуске, живут годами — до разбора спорного списания, где непонятно, кто и на каком основании его провёл.

Рост объёма данных добивает то, что работало на старте. Справочники наполняли руками, уникальных ключей и нормализации не закладывали, поэтому в контрагентах появляются три записи одного клиента. Выпадающий список грузит таблицу целиком — форма заказа на десятках тысяч строк открывается секундами, и это приносят как «сайт тормозит».

Ручной ввод и дубли лечат прямыми правками в базе: задача закрыта, следа нет — ни истории изменений, ни причины. Зависшие задачи операторов — обратная сторона того же: заявка уходит в работу, но никому не назначена, а очередь видит только тот, кто её открыл.

Первой ломается скорость выпуска новых разделов. Справочник с фильтрами и правами — это недели копирования уже готового, потому что общего слоя для списков, форм и проверок доступа в самописе нет. В актуальной ветке Filament такая типизация встроена — разбираем, как это закрывается при переходе.

Что меняется после внедрения: сроки, ошибки, доступы

Скорость выпуска новых разделов

Каркас панели уже собран: навигация, авторизация, таблицы, формы и фильтры работают по единым правилам. Инженер описывает модель данных и права, а типовые элементы подключает декларативно — без вёрстки каждого экрана с нуля. Раздел средней сложности выходит за дни вместо недель, и это не разовый рывок, а темп всей очереди задач.

Меньше ручных операций

Подтверждение заявки, смена статуса, массовая выгрузка перестают требовать правок в базе и разовых скриптов. Действие выполняется из интерфейса, протоколируется и повторяется одинаково любым сотрудником. Рутина уходит в одну кнопку, человек занимается только тем, где действительно нужно его решение.

Ошибки ввода данных

Проверки на уровне формы, обязательные связи и предустановленные значения закрывают класс отказов, который раньше находили по расхождениям в отчётах. Поле не пропустит пустое значение или дубль, а связь не даст удалить запись, от которой зависят другие. Ошибка видна в момент ввода, а не при сверке.

Время адаптации сотрудника

Логика интерфейса повторяется от экрана к экрану: одинаковые фильтры, поиск, сохранение, отмена. Новый сотрудник осваивает типовой раздел за одну-две смены и не разбирается в самодельных формах. Учить приходится один раз и один набор приёмов.

Прозрачность прав доступа

Роли и разрешения описаны декларативно, а не разбросаны по коду. Видно, кто открывал раздел, кто менял запись и что именно изменилось; при увольнении доступ отзывается в одном месте. Это снимает вопросы «а кто это поправил» и упрощает проверки.

Сравнение подходов: готовые компоненты или своя разработка

Выбор начинается не с инструмента, а с того, насколько структура данных совпадает с типовой. Если сущности описываются стандартными связями, готовый набор компонентов закрывает задачу быстрее: формы, таблицы, фильтры и права настраиваются декларативно, без ручной вёрстки экранов. Filament админ-панель в таком режиме разворачивается поверх моделей и не требует отдельного слоя представления.

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

Внедрение админ-панели на Filament: от аудита до передачи

Работы идут этапами с результатом на каждом — заказчик видит, что уже работает, а не ждёт финальной сборки. Панель на Filament собирается поверх существующей схемы данных, поэтому начинаем с аудита: пока непонятно, откуда берутся записи и кто их меняет, любой интерфейс получится декоративным.

1. Аудит текущего учёта. Разбираем, какие сущности реально используются, где дубли, какие поля заполняют вручную и какие операции держатся на одном человеке.
2. Схема данных и ролей. Фиксируем связи между сущностями и права: что доступно менеджеру, что администратору, где нужна история изменений.
3. Настройка разделов. Навигация, таблицы с фильтрами и поиском, формы с валидацией, массовые операции — под ежедневные сценарии, без лишних кнопок.
4. Проверка сценариев. Прогоняем рабочие пути целиком: заведение записи, правка, отмена, выгрузка отчёта, восстановление удалённого. Граничные случаи ловим до релиза.
5. Развёртывание и доступы. Настраиваем роли, журнал действий и резервное копирование, чтобы любое изменение было восстановимо.
6. Передача и обучение. Показываем разделы на реальных данных, отдаём документацию по ролям и регламент типовых операций, включая порядок добавления новых разделов.

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

Состав поставки: конфигурации, политики, документация

Мы передаём панель так, чтобы её можно было развивать без нас: конфигурации, права и документация остаются в репозитории заказчика, а не в переписке с подрядчиком. Ниже — что именно входит в поставку по каждой административной панели на Filament.

• Конфигурации разделов — по каждому разделу отдельный набор полей, связей, фильтров и состава колонок. Добавить поле или скрыть столбец можно правкой конфигурации, не трогая логику выборки и не переписывая экран.
• Политики доступа — матрица «роль → раздел → действие» с проверками и на уровне запросов, и на уровне интерфейса: оператор не видит чужие разделы и не может обойти ограничение через прямую ссылку.
• Схема данных — диаграмма таблиц и связей с назначением полей и пометками, какие изменения ломают совместимость со старыми записями, а какие безопасны.
• Инструкции для операторов — пошаговые сценарии на каждодневные задачи: заведение и модерация записи, массовая правка, выгрузка, что делать при отказе сохранения.
• Регламент сопровождения — порядок правок и проверки, правила выпуска и отката версии, календарь обновления зависимостей, зона ответственности заказчика и наша.
• Журнал интеграций — перечень внешних сервисов, к которым обращается панель, с указанием формата обмена, частоты вызовов и поведения при недоступности внешней стороны.
• Тестовые данные и чек-лист приёмки — набор записей для проверки на стенде и список сценариев, по которым заказчик сам подтверждает, что панель готова к работе.

Всё это оформлено так, что новый разработчик входит в проект по документации, а не по устным пояснениям. Если по ходу работы появляются нестандартные разделы, они описываются тем же способом — иначе поставка считается неполной.

Кейс: учёт заявок и остатков — метрики до и после

Исходная точка

Учёт заявок и остатков жил в трёх таблицах и почтовой ветке: менеджер оформлял заявку по телефону, вручную сверял наличие и переносил строки между файлами. На проверку уходило 6–8 минут на заявку, а доля заявок, которые приходилось править вручную после оформления, держалась около 38%. Основной класс отказов — продажа позиции, которой на складе фактически нет: расхождение всплывало на следующий день при инвентаризации, уже после того как клиенту подтвердили заказ.

Что изменили и что получили

Собрали единый раздел на Filament: справочник позиций, приход и списание, очередь заявок и права по ролям — кладовщик видит движение, менеджер только остаток и резерв. Остаток стал вычисляемым: подтверждение заявки резервирует позицию, оформить больше, чем физически есть, система не даёт. Утренние сверки ушли из регламента — расхождение видно в момент оформления, а не на следующий день.

Оформление одной заявки сократилось с 6–8 минут до 40–60 секунд, доля ручных правок — с 38% до 6%, и это в основном уточнение адреса доставки. Новое поле или статус вводим за 1–2 часа: описание, правило доступа, миграция, проверка на копии данных; раньше это была переписка на 2–3 дня и правка в трёх местах сразу. Ответственный за направление в отзыве отдельно отметил, что ручные сверки по утрам перестали быть частью рабочего дня.

Можно ли доработать текущую систему, не переписывая интерфейс?

В большинстве случаев переписывать интерфейс не требуется. Если данные лежат в реляционной базе с явными связями, панель управления надстраивается поверх существующих таблиц: описываем ресурсы, отношения и права доступа, и сотрудники работают с теми же записями, просто через другой интерфейс. Показатели, отчёты и поиск при этом считаются по тем же полям, что и раньше.

Перенос данных в такой схеме не нужен: источник остаётся один, а старый интерфейс можно держать рядом и постепенно выводить из работы. Именно поэтому доработка без переписывания окупается там, где учёт уже ведётся, но ввод и правка записей отнимают время у операторов.

Переработка схемы неизбежна там, где логика держится на свободных текстовых полях: статусы и типы записаны строкой, связи между сущностями нигде не зафиксированы, история изменений не сохраняется. Надстройка над таким хранилищем даст только косметику — фильтры и аккуратные формы, — а расхождения в данных останутся. Здесь поэтапная модернизация начинается с нормализации ключевых таблиц и переноса значений в справочники, и только после этого строится панель.

Совместимость с текущим учётом проверяем до изменений, а не после: выгрузки, отчёты и внешние интеграции должны получать данные в прежнем виде. Поэтому переключение делаем управляемым — панель читает боевые данные сразу, а запись переводим на неё по модулям, оставляя возможность вернуться к прежнему порядку ввода без потери уже созданных записей.

Так частичная модернизация закрывает основную боль — скорость и прозрачность работы операторов — без остановки учёта и без риска потерять накопленные данные.

Частые технические вопросы: ограничения и компромиссы

Ниже — технические сомнения, которые чаще всего всплывают на оценке Filament админ-панели: где у подхода есть предел, что происходит при росте объёмов и как панель встраивается в существующий контур доступов и учётных систем.

Как панель ведёт себя на больших объёмах?

Списки собираются на сервере с постраничной выборкой и сортировкой по индексам — первым начинает тормозить фильтр по неиндексированному полю, это и есть точка роста. Массовые импорты и выгрузки уводим в фоновые задачи, чтобы браузер не ждал ответа на многотысячную выборку.

Как разграничивается доступ между сотрудниками?

Доступ строится на ролях и политиках уровня записей: менеджер видит только свои объекты, руководитель направления — своё подразделение. Каждое изменение попадает в журнал действий с автором и прежним значением, поэтому спор «кто поменял» закрывается фактами, а не перепиской.

Что с интеграциями и сопровождением?

Обмен с учётными системами идёт через отдельный слой и очередь: импорт идемпотентен по внешнему идентификатору, расхождения сводятся сверкой. Если внешний сервис недоступен, операции встают в буфер и доигрываются — панель не теряет введённые данные. Обновления мажорной версии выполняем отдельной веткой с прогоном тестов, чтобы админка не «поехала» вместе с фреймворком.

Обсудим задачу: с чего начинается оценка и план

Чтобы оценка задачи опиралась на факты, а не на предположения, нужен минимальный набор входных данных: доступ к репозиторию или дамп структуры базы, перечень ролей и прав, список сущностей со связями и текущие способы администрирования этих данных. Если панель уже работает, добавляем экраны, отчёты и выгрузки, которые должны остаться рабочими.

• Схема данных: таблицы, связи, объёмы — определяют, где нужны индексы и постраничный вывод.
• Роли и права: кто что видит и меняет, нужен ли журнал действий и ограничения по подразделениям.
• Текущее администрирование: скрипты, ручные правки в базе, выгрузки — кандидаты на перенос в интерфейс.
• Внешние системы: оплата, склад, уведомления — по каждой нужен способ обмена и ответственный на вашей стороне.
• Ограничения: окружения, требования безопасности, порядок доступа к серверам, что критично к запуску.
• Что переносим в первую очередь, а что может подождать до второй очереди.

Часть экранов закрывается штатными средствами Filament, часть требует собственной логики — это первое, что влияет на объём. По собранным данным возвращаемся с планом работ: этапы, состав команды под каждый этап, точки согласования и порядок старта. Опишите задачу своими словами — уточняющие вопросы зададим сами.