Недавно наткнулся на очередную админку для Laravel — Voyager. На данный момент она имеет 4 715 звёзд на гитхабе, что в 2-5 раз выше, чем у других аналогичных проектов. Мне понравилась видео-презентация и я решил посмотреть Voyager в деле. Далее я постараюсь убедить вас не использовать её в продакшене особенно при CI подходе.
Отрицательные стороны Laravel Voyager
Хоть этот проект и имеет на сегодня версию 1.0.6, у него есть нерешённые проблемы и даже неотловленные эксепшены. Для меня главной проблемой оказалось то, что вся конфигурация дашбордов, меню и других сущностей хранится в БД. С одной стороны, это позволяет относительно легко конфигурировать всю систему мышкой через web-интерфейс. Проблемы начинаются тогда, когда нужно настройки дашбордов перенести с одного стенда на другой, например с девелоперской машины на продакшен. Можно сделать SQL-дамп и залить его в новое окружение, но что, если на том окружении уже имеются свои настройки и терять их нельзя?
Эту проблему можно обойти написанием миграций, которые бы занимались всевозможными проверками и приводили бы состояние данных в БД о дашбордах в требуемый вид. Такой подход сильно усложняет разработку и добавляет много ручной работы. Хотя подобные админки наоборот должны упрощать разработку.
Следующим шагом приходит в голову ограничить пользователям продакшена менять настройки дашбордов и системы в целом. Но тогда какой вообще смысл от этого функционала? В итоге всё сводится к тому, что проще конфигурировать дашборды PHP кодом, чем городить кривые миграции для Voyager.
Отсутствие проверки входных данных
Другая проблема системы Voyager (в версии 1.0.5) в том, что через web-интерфейс можно ввести некорректные настройки (притом не подозревая об этом) так, что интерфейс редактирования сущности будет кидать эксепшен и редактировать его придётся напрямую в БД. Эти элементы так же будут кидать эксепшены и в пользовательской части приложения.
Не оптимальная работа с базой данных
Ещё одна проблема, то что Voyager делает невероятное количество SQL запросов и не имеет поддержки кеширования. В результате одни и те же запросы выполняются дважды и даже трижды. А если вы решили использовать связи (relations) то на каждую связь в каждой строке таблицы будет выполняться отдельный запрос, даже если данные по этой связи уже были запрошены строкой выше! Это катастрофически сказывается на производительности. Например, главная страничка этой админки на полноценном сервере открывается 240 мс, а дашборд с 10-ю строками — 600 мс! Из этого времени загрузка ядра Laravel занимает 20-35 мс, а всё остальное сжирает Voyager.
Отсутствие перелинковки связанных записей
Другая фича, которой не хватает в Voyager — это перелинковка связей. Допустим, я настроил relations между двумя дашбордами и всё, что сделает Voyager — вместо id сущностей будет показывать другое поле из той таблицы, например, name или title. И всё! Без возможности кликнуть по этому полю и переходу к просмотру этой сущности. Хотя в phpMyAdmin это было реализовано лет 5 назад. Назвать Voyager чем то большим, чем наколеночная поделка нельзя.
Невозможность нестандартной авторизации
Ну и заключительным моментом стало то, что админка Voyager из коробки не поддерживает использование кастомного guard для отдельной авторизации в эту систему. Это решается созданием форка и правкой пары файлов, со всеми вытекающими последствиями. Но лучше сразу вынести Voyager в отдельный проект, а не добавлять его в основной.
Собственно, ни одной уникальной или хотя бы полезной фичи эта админка не выполняет, так что использовать её я крайне не рекомендую.