Как вы можете настроить мультитенантное приложение Rails без использования поддоменов? - PullRequest
0 голосов
/ 13 февраля 2019

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

Из того, что я 'До сих пор мы читали, что большинство решений для рельсов используют мультитенантные шаблоны с поддоменами, такие как Apartment gem , для блокирования учетных записей.Но кажется, что проще использовать ваш сайт на одном большом приложении и базе данных.Например, Basecamp недавно переключился на этот подход с Basecamp3 .Новые приложения, кажется, создаются таким образом.

И, если функции администратора и учетные записи клиентов / интерфейсный магазин будут полностью отдельными приложениями, или вы можете сделать это с помощью " величественного монолита «?Мне кажется, что одно большое приложение и база данных более просты.

Я нашел этот пост , который объясняет, как сделать что-то подобное с Pundit ,но я все еще не могу понять, как это может работать с владельцами учетных записей, персоналом и клиентами в одном приложении.

Вот основные потребности моего приложения:

Роли пользователя

  • Владелец учетной записи (создает учетную запись компании и имеет полный доступ к данным своей компании)
  • Персонал (приглашен присоединиться к компании и не имеет доступа к некоторым изданные компании, такие как платежная информация)
  • Клиент (может зарегистрироваться на сайте и просмотреть товары, добавить их в корзину, но не может получить доступ к каким-либо функциям персонала или владельца учетной записи.)
  • Все пользователи (независимо от роли) принадлежат компании и не могут получить доступ к данным другой компании.(Таким образом, предоставляя возможность запускать отдельные хранилища в одном и том же приложении, что необходимо для его запуска в качестве приложения SAAS.)
  • Владельцы учетных записей и персонал могут использовать продукты CRUD, но не клиенты.

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

Потенциальные модели и ассоциации

Company
has_many :users, dependent: :destroy
has_many :products, dependent: :destroy

User
belongs_to :company

Product
belongs_to :company

Авторизация

  • Будет ли работать Pundit для ограничения действий контроллера в зависимости от ролей пользователя, а затем для обеспечения того, чтобы данные отбирались через ассоциации моделей?

Порядок регистрации

Я немного размышляю о том, как справляться с определенными областями ролей пользователей, и где регистрация "персонал приглашает" и "клиент" может вписаться в поток регистрации.

Будет ли этот подход работать?

  1. Создать отдельные контроллеры для «Регистрация владельца учетной записи», «Регистрация персонала», «Регистрация клиента», а затем встроить мою регистрационную форму в твзгляды шланга.(Использует Clearance для аутентификации и хотел бы сохранить его, если это возможно, но при необходимости увеличьте его).
  2. Регистрация владельца учетной записи: так что, если кто-то зарегистрируется через контроллер регистрации новой учетной записи(со встроенной формой аутентификации) они также создадут Компанию.
  3. Приглашение персонала: Владелец аккаунта может создавать новых Пользователей персонала, введя Имя и Адрес электронной почты.Это создает нового пользователя с ролью «Персонал» (и, следовательно, не может стать владельцем учетной записи в другой учетной записи).Новому пользователю «Персонал» отправляется электронное письмо с приглашением, которое в основном является электронным письмом сброса пароля, и приглашает его принять приглашение путем создания пароля.
  4. Регистрация клиента: если кто-то регистрируется через контроллер «Регистрация клиента», онбудет автоматически предоставлена ​​роль пользователя «клиент».Не уверен, как установить идентификатор компании в этом случае.(Передать company_id как скрытый ввод в форму регистрации клиента?)

Есть ли лучший способ создать приложение такого типа, которое мне не хватает?Я на правильном пути?У меня нет опыта создания чего-то подобного, поэтому любые подсказки были бы чрезвычайно полезны.

Кажется, что новые приложения следуют этому типу шаблона для мультитенантности, а не для поддоменов.

1 Ответ

0 голосов
/ 13 февраля 2019

Вы открываете с помощью simple e-commerce site, но вопросы, которые вы задаете, указывают на то, что вы ищете что-то более сложное :) Вы на правильном пути.

Камень Act_as_tenant стоитвзгляд.Мы используем это сейчас, и это помогает удостовериться, что все ваши запросы правильно распределены.

Я бы также посмотрел и оценил rolify, если вам нужно выполнять роли (но не исключаю логический флаг для вашего пользователя, так какхорошо).

Я не исключаю разработки, но расчистка довольно популярна.

Использование субдомена может оказаться нереализованной работой в зависимости от количества усилий, если только вам не нужно фактически использовать субдомены.в целях тщеславия (my.example.com vs example.com/my) вы можете обойтись без него.

Я бы рассмотрел отдельные контроллеры и пространства имен для разных ролей, если их доступ сильно различается;Вы также можете объединить их в единичные контроллеры, используя Pundit (но это может быть громоздким).Вы по-прежнему хотите использовать Pundit, однако Pundit может выполнять такие действия, как определение объема записей, которые должен видеть пользователь.

Вы на правильном пути и задаете правильные вопросы, но ответы на все эти вопросы будутзависеть от других вопросов (которые вы, вероятно, даже не можете ответить прямо сейчас).

У меня есть проект, в котором я делаю то, что вы заметили (pundit, чтобы ограничить данные, actions_as_tenant, чтобы выдавать вещи), но по мере развития появляются определенные шаблоны, которые ведут меня по другому пути.Администратор пространства имен, вместо того, чтобы делать проверки администратора внутри одного контроллера, например;потому что если вы переписываете в API, вы в конечном итоге пытаетесь заставить одну и ту же конечную точку делать разные вещи, и гораздо чётче выделить 2 конечные точки за пространством имен и задокументировать фактическое поведение, на мой взгляд.

...