За последние 24 часа нас посетил 9981 программист и 1137 роботов. Сейчас ищут 383 программиста ...

Поддомен для каждой кампании?!

Тема в разделе "Версионность, тестирование и развёртывание", создана пользователем виталий032, 4 июн 2020.

  1. виталий032

    виталий032 Активный пользователь

    С нами с:
    31 янв 2014
    Сообщения:
    227
    Симпатии:
    30
    Адрес:
    Владивосток
    Всем привет.
    Необходим ваш совет.

    [Предисловие]
    Разрабатываю приложение для записи клиентов, направленное на мелкий бизнес.
    Есть владельцы бизнеса, сотрудники и клиенты. Каждый должен иметь возможность зайти в свой личный кабинет. Владельцы покупают услугу, регистрируют компанию. Сотрудники могут просматривать свои записи. Клиенты могут записаться.

    Мои партнеры хотят видеть панель клиентов-сотрудников (company scope) на отдельном поддомене. Ну, это логично, и решает некоторые проблемы с ролями и уникальной идентификацией пользователя.

    В конечном итоге я пришел к решению использовать опыт конкурентов. Отдельная компания на отдельном поддомене. На этом сайте с поддоменом могут заходить в личный кабинет сотрудники и клиенты. Владельцы заходят и осуществляют управление с главного сайта.

    Проект на laravel и react, полностью SPA. Все это в одной куче уже написано корявенько недоразработчиком мной. Однако теперь это нужно разнести (главный сайт - на прежнем месте, панель сотрудников вместе с панелью для записи - на отдельный поддомен.

    [Главная часть]
    Думаю когда владелец регистрируется или добавляет новую компанию с главного сайта, то создавать базу с именем "n72825", где 72825 - это ID компании. Nginx настроить так, чтобы все поддомены n*.example.com указывали на /var/www/company-project/current.

    То есть один проект (дочерний), для всех поддоменов нашего главного сайта. Хотя есть идея сделать отдельную папку для каждого такого поддомена, но боюсь в таком случае при обновлении gitlab репозитория прийдется обновлять 100500 проектов (папок) каждой компании, которые находятся на поддомене. Не очень так + надо будет зависимости composer и npm хранить для каждого проекта отдельно, хотя можно прокинуть симлинки. Короче идея не очень.

    Так как изменчивые только папка storage, то думаю сделать один проект (папку, company-project), которая будет принимать все запросы со всех поддоменов. Соответственно, возникает лишь проблема вытащить поддомен из url, динамически изменять имя базы данных (имя которой совпадает с поддоменом) и динамически изменять папку storage, на /var/www/company-project/storage/имя_базы(поддомена). А .env файл будет един для всех, так как остальные настройки едины, к примеру, пароль к mysql будет одинаковый.

    Сказали мне - 2 недели, ну или как получится. Походу спать я не буду вообще.

    Может быть вы поступили как-то иначе, может у вас есть подобный опыт? Хотелось бы услышать ваш фидбэк. Спасибо.
     
    #1 виталий032, 4 июн 2020
    Последнее редактирование: 4 июн 2020
  2. виталий032

    виталий032 Активный пользователь

    С нами с:
    31 янв 2014
    Сообщения:
    227
    Симпатии:
    30
    Адрес:
    Владивосток
    Я тут осознал, что в любом случае, при каждом обновлении master придется запускать миграции для каждой базы отдельно (а их может быть сотни тысяч). Блин, что-то тут не так.
     
  3. ElisDN

    ElisDN Активный пользователь

    С нами с:
    13 фев 2018
    Сообщения:
    605
    Симпатии:
    130
    Либо использовать одну БД и в таблицы добавить поле company_id.
     
    виталий032 нравится это.
  4. miketomlin

    miketomlin Старожил

    С нами с:
    9 авг 2016
    Сообщения:
    3.471
    Симпатии:
    578
    У нас обычно используют одну БД плюс табличные префиксы, если различать записи в общих таблицах по «company_id» по каким-то причинам напряжно.
     
    виталий032 нравится это.
  5. виталий032

    виталий032 Активный пользователь

    С нами с:
    31 янв 2014
    Сообщения:
    227
    Симпатии:
    30
    Адрес:
    Владивосток
    Спасибо всем, кто написал свой отзыв. Все таки решил, что с дополнительным полем company_id будет лучше и проще. Вообще убрал таблицы users, users_roles и roles с проекта на поддомене (панель сотрудники-клиенты) и сделал раздельные guards для отдельной авторизации Client и Employee.