Как разнести админ панель и основной сайт по разным проектам в laravel?

Question

[DocTypeMaster]

Друзья, затеял делать админ панель для сайта, и хочу сделать её на отдельном проекте ларавел, подскажите как это правильно делать и целесообразно вообще так делать ?

Пока это все будет на одном сервере лежать и админка и приложение, но в будущем для безопасности разнесу на разные сервера. А вообще как мне лучше это сделать, на поддомене admin.domain.com или как-то иначе сделать *?

Comments

[Алексей Скляров]

А чем вас стандартный site.com/admin не устраивает?

[Александр Аксентьев]

для безопасности

как это увеличивает безопасность?

[DocTypeMaster]

Алексей Скляров, разве я написал что не устраивает, я спросил как лучше, если в таком варианте то мне нужно сделать разделение ролей на ларавел, я использую на сайте jetstream и как разделить роли я не знаю

[jazzus]

Александр Аксентьев, если сайт взломают, админка будет в безопасности)

[NubasLol]

jazzus, ключи к бд тоже будут разные?Реплики для сайта, и бла бла?)))

[jazzus]

NubasLol, да какая бд.. хакеры увидят, что админки на сервере нет расстроятся и уйдут

Answer 1

[pLavrenov]

Если очень хочется разделить репозитории то можно использовать модульность.
При такой желании, вообще, мне кажется, нет смысла ставить сайт на laravel тк есть пути проще с меньшими трудозатратами.

nWidart/laravel-modules

Comments

[DocTypeMaster]

Мне это не совсем подходит

[jazzus]

DocTypeMaster, что тут может походить или не подходить. будто задача есть) берешь политики и на все запросы к админке кроме админа возвращаешь 404. типа хитрость от хакеров) в документации по моему даже пример с админом есть если не путаю

Answer 2

[Петр Слободянюк]

Я думаю что при решении таких задач проще всего расписать все минусы и плюсы и принять решение:
+ распределение нагрузки
+ в каком-то смысле выше уровень безопасности, но это спорный вопрос
+ независимая (в каком-то смысле) разработка

- в 2 раза больше кода (библиотеки, сервисы, политики, модели и многое другое дублируется)
- сложнее техническая поддержка
- увеличивается шанс повреждения БД
- независимая разработка

Лично моё мнение – разносить на 2 раздельных проекта нецелесообразно. На отдельный домен (поддомен) – возможно. Делается это для того чтобы распределить нагрузку на PHP. Делается это с помощью настройки префикса у маршрутов. Но делать это нужно, опять таки, если действительно требуется. Тут сложно судить не зная что у вас за ресурс и сколько часов разработки в него заложено.

Comments

[Петр Слободянюк]

И опять-таки. О какой безопасности идёт речь? Вы хотите и БД тоже разносить и делать репликацию? В общем, тут нужно копнуть глубже и понять откуда вообще возникла эта мысль.

Answer 3

[Evgeniy S]

Привет!
с поддоменом идея здравая! Тем более, ларавел роутинг позволяет все твои админские роуты посадить на поддомен.
разделять на репозитории вижу только в том случае, если собираетесь разделять доступ к коду другим программистам. иначе много проблем возникнет, от хранения до деплоя. Или если админка написана не на ларе (например на Vue или React). но опять же, лучше делать гит-модулями или package лары.

Так же для безопасности вы скорее всего будете делать нестандартный поддомен - типа adminka367sd.domain.com, + чтобы куки админов имели другие названия и не пересекались с рабочим сайтом.

и еще - БД будет общая, для рабочего сайта и для админки. и если на разных серверах, то будут лаги доступа к БД. Нужно продумать архитектуру

Comments

[DocTypeMaster]

спасибо , очень интересная мысль, про гит я вообще не писал ничего, я и не собирался разделять его, а вот насчет разноса на сервера и лагов

и еще - БД будет общая, для рабочего сайта и для админки. и если на разных серверах, то будут лаги доступа к БД. Нужно продумать архитектуру

если в админке будет только добавление постов и редактирование а на основном сайте только вывод то лаги будут ощутимые ?

[Evgeniy S]

DocTypeMaster, тогда основной сайт и бд держать на одном сервере. а уж админка на другом сервере только для листинга и редактирования постов - ничего страшного, лагов не будет.