най-добрият подход за SaaS приложение с множество наематели

Опитвам се да създам SaaS приложение с няколко клиента и знам, че има множество подходи за това, но избрах този с множество бази данни, който мисля, че ще пасне най-много.

така че създавам db за всеки наемател и съхранявам таблица с наематели в главната db и свързвам потребителите към съответната им db въз основа на поддомейна.

сега проблемът ми тук е къде да съхранявам потребителите в главната база данни? или tenant db, съхраняването на потребителите в главната db ще затрудни получаването на свързани с потребителите модели в други db, но съхраняването им в tenants db би затруднило удостоверяването на всички потребители ...

също какъв е най-добрият сценарий?

  1. удостоверяване, получаване на jwt токен.
  2. изпращайте токен с всяка заявка.
  3. при всяка заявка валидирайте токена, проверете поддомейн, свържете се със съответния клиент db, изпълнете заявка.

това добър подход ли е? какво трябва да направя с проблема с таблицата с потребители? ThnQ


person Sherif    schedule 30.08.2016    source източник
comment
съхраняването му в tenants db би затруднило удостоверяването на всички потребители. Защо бихте искали да направите това?   -  person Alex Howansky    schedule 30.08.2016
comment
може би не го изясних ... ако го съхраня в tenants db, когато потребителският журнал влиза за първи път, без да посочва кой клиент. как да разбера от коя база данни да се удостоверя?   -  person Sherif    schedule 30.08.2016
comment
Или ги накарайте да посочат клиента изрично, като използват потребителски идентификатори, които изглеждат като имейли (напр. [email protected]), или неявно да определят клиента, като погледнат името на домейна, което е обслужило заявката. И в двата случая искате вашите потребителски идентификатори да бъдат уникални в рамките на всеки клиент, а не уникални във всички тях. Т.е., ако някой настрои userid bob в рамките на клиент #1, това не трябва да попречи на някой друг да използва userid bob в рамките на клиент #2.   -  person Alex Howansky    schedule 30.08.2016
comment
Знам, че използвате множество бази данни, но ако решите да преминете към една база данни, бих ви предложил да разгледате Landlord което е чудесно за saas платформи. Само една мисъл, успех.   -  person camelCase    schedule 30.08.2016


Отговори (2)


Мога да предложа трети вариант. Има потребител както в наемател, така и в основна база данни. След това можете да създадете процедура за актуализиране на основната база данни, когато потребителят се промени в база данни на клиента (или обратното).

Освен това не знам модели в Laravel, но MySQL няма проблем с кръстосани JOIN бази данни.

person Tomáš Jacík    schedule 30.08.2016
comment
Ще разгледам MYSQL cross db joins, но се опитвам да избегна дублирани данни, мисля, че е лоша практика - person Sherif; 30.08.2016
comment
Зависи. В мултитенантното приложение понякога е по-добре да имате множество данни за по-добра производителност. Ами ако един сървър е недостатъчен? Можете просто да разделите бази данни на наематели между множество db сървъри, но все още имате нужда от всички в основната база данни. - person Tomáš Jacík; 30.08.2016

Добър вариант ще бъде да запазите потребителите в базата данни на наемателите. Тъй като разграничавате своя клиент въз основа на поддомейн, можете да кажете на вашата система за удостоверяване да прави запитвания към конкретна база данни за поддомейн.

Споделяне на потока на удостоверяване

  1. Потребителят натиска поддомейна, за да влезе за кандидатстване
  2. Потребителските идентификационни данни ще бъдат изпратени до приложението
  3. Преди да предадете идентификационни данни за удостоверяване, решете база данни за потребителско удостоверяване въз основа на поддомейн, от който идва потребителят.
  4. Предайте името на базата данни, потребителските идентификационни данни към системата за удостоверяване
  5. Системата за удостоверяване отправя запитвания към конкретна база данни и удостоверява потребителя
  6. Генериране на сесия
person Ketan Ghumatkar    schedule 02.06.2017