Как создать приложение SaaS с Python и Django

программное обеспечение как услуга - это просто маркетинговое слово, оно технически ничем не отличается от сервера, доступного через интернет. Поэтому вопрос 3 не имеет смысла. Что оставляет нас с вопросом 1 и 2:

1. Что вы имеете в виду под "приложением" в этом контексте? Ваше веб-приложение (построенное с помощью Python и Django) может иметь несколько приложений Django (компонентов, составляющих веб-приложение), но я думаю, что это не то, что вы имеете в виду. Вы можете создать свой сайт на Python/Django и имеют различные параметры настройки в зависимости от того, какой пользователь (клиент) вошел в систему. Например, премиум-клиент может иметь несколько дополнительных опций, но он по-прежнему является частью той же кодовой базы. Просто некоторые параметры (кнопки/элементы управления и т. д.) Не отображаются для определенных клиентов

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

очень простой, элементарный пример того, как вы это сделаете.

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

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

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

до сих пор ваше приложение может настроить себя на передней панели. Он по-прежнему использует ту же базу данных, которая была разработана на первом этапе.

теперь возникает вопрос о показе только тех полей, которые имеют отношение к конкретному пользователю. Это будет параметризация базы данных. Таким образом, вы можете добавить столбец определяет каждую строку как принадлежащую определенному пользователю; затем создает представления или хранимые процедуры, фильтрующие записи на основе вошедшего пользователя.

теперь приложение может быть "арендовано"; так как вы можете настроить экземпляр на основе пользователя.

затем он просто становится больше отсюда-в зависимости от масштаба, типа и предполагаемой настройки вашего приложения. Вы можете решить, что ваше приложение работает лучше, когда у каждого пользователя есть свои собственные выделенная база данных вместо хранимой процедуры + вид комбо.

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

Если ваше приложение требует много хранения - вы можете решить взимать плату отдельно для хранения.

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

у меня есть блоге описание моего предложения о том, как сделать многопользовательское веб-приложение SAAS с помощью Django. Multi-tenancy здесь означает, что при регистрации пользователей у них есть свой поддомен. Напомним:

• все арендаторы имеют одну базу данных, но каждый имеет свои собственные схемы. Представьте у вас есть сайт abc.com и кто-то зарегистрирован xyz арендатор, так что они доступ к своей странице через xyz.abc.com, затем для арендатора xyz у вас есть отдельная схема, содержащая все таблицы, инкапсулирующие данные, связанные только с xyz арендатор. Есть и другие способы, например, иметь одну базу данных и одну схему для всех или даже отдельные базы данных. Но схематический подход-лучший компромисс. The Джанго-арендаторов документация библиотеки содержит более подробную информацию, если вы заинтересованы
• использовать Джанго-арендаторов библиотека для абстрактной работы с арендаторами. Когда кто-то обращается xyz.abc.com, вы должны знать, что xyz является арендатором и, что вы должны использовать xyz схемы. Джанго-арендаторов библиотека делает это для вас, поэтому по каждому запросу вы можете получить объект арендатора, просто выполнив current_tenant = request.tenant
• необходимо различать общие таблицы и таблицы для конкретного клиента. Например, наличие таблицы со списком заказов зависит от клиента. Каждый жилец может иметь свои собственная база данных, содержащая все их заказы. Эта таблица должна быть внутри xyz схемы. В то же время у вас будут некоторые основные таблицы Django, такие как пользователей. Данные могут быть общими, например, чтобы запретить двум пользователям регистрироваться с одним и тем же письмом.
• необходимо настроить DNS, чтобы поймать выражение *.abc.com, для которого можно добавить A запись внутри CPanel с *.abc.com ссылка на IP-адрес вашего сервера