Архитектура Django для различных клиентов/технологий, использующих одни и те же модели
Мы с командой испытываем трудности с определением архитектуры для бэкенд-среды с использованием Django. Для контекста мы создали приложение, похожее на App Store, для отображения всех наших разработок, с той разницей, что оно также запускает приложения.
Для хранения всей информации об этих приложениях мы создали бэкенд на Django, который представляет собой базу данных, доступную через API из App Store, и сайт Django Admin для регистрации информации, которая должна быть предоставлена в API (которую Django генерирует автоматически).
Дело в том, что сегодня у нас задействована только одна технология и, следовательно, только одна база данных и один администратор Django. Но другие области в нашей компании хотят использовать эту архитектуру, которую мы построили, с другими приложениями и, следовательно, другой информацией, не связанной с нашей средой
Вопрос в том, должны ли мы развернуть несколько Djangos в разных портах нашего сервера? Или мы должны попытаться создать зависимость в наших моделях от "Технологии", связанной с ней? (Для этого варианта важно отметить, что наша архитектура сложная и сильно вложенная). Или, может быть, нам следует использовать несколько баз данных, предоставляемых Django?
Была ли у кого-нибудь ситуация, подобная этой?
Заранее спасибо!
Для меня проблема с созданием зависимости в наших моделях от "Технологии" связана с тем, что ОП имеет в виду другие сведения, не относящиеся к среде ОП. Может ли ОП создать модель базы данных, которая работает, чья система не слишком сложна и которая может вместить все случаи, которые хочет ОП? Если это так, то я не вижу причин для отказа.
Здесь интересный Q&A, говорящий о наличии нескольких экземпляров Django на одном сервере. Лично я уже развертывал виртуальные общие хосты, логика которых была по сути такой, с тем ограничением, что ОП делится и с другими людьми. OP может увидеть в этой теме, что есть различные случаи, когда это было жизнеспособным вариантом. Лично я считаю такие общие хосты жизнеспособными только на начальных этапах, поскольку они не так производительны... но это отличный способ сэкономить ресурсы, если вы работаете с ограниченным бюджетом. IMO это может быть одним из лучших вариантов для случая ОП... который считается однопользовательским
Что касается множества баз данных, это автоматически приводит меня к подходу к многопользовательским приложениям (внутри многопользовательских приложений есть подходы, где также нужна только одна база данных). ОП хочет пойти на этот вариант, если приложение ОП может обслуживать всех пользователей с одного хоста, что, похоже, не подходит для ОП, если только ОП не сможет создать зависимость в моделях ОП от "Технологии" (как рассматривается в первом абзаце).