Блог

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

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

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

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

Подход А

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

• Хорошая часть этого заключается в том, что каждое приложение будет иметь свое представление API, когда они будут извлечены.
• Плохо то, что это отвратительно!! Мне кажется, что это плохая практика, но я новичок в Джанго и не уверен. Кроме того, API приложения, возможно, потребуется получить http-адрес обратного вызова, чтобы он также прерывался при вызове представлений (я думаю).

Подход В

Другая идея состоит в том, чтобы немного задействовать сетевой уровень и выполнять фактические HTTP-запросы к моему собственному приложению. Конечно, это немного медленнее, но если даже однажды какое-либо из этих приложений будет извлечено, у нас все равно будет чистый дизайн, и нам просто нужно изменить http-адрес приложения в нашей реализации «четко определенного интерфейса».

В Интернете существует множество различных стратегий разработки приложений django, которые ясно показывают мне, что у разных людей разное представление о том, что такое приложение, и я не смог найти ничего, что определяло бы, как отдельные приложения django должны вызывать друг друга с помощью API, а не напрямую.

Я хотел бы знать, какой из моих подходов является более обычной практикой, и делаю ли я все это неправильно. Также обратите внимание, что эти приложения-службы не имеют никаких зависимостей друг от друга и должны иметь возможность работать по отдельности. Я понимаю, что в большинстве случаев приложения зависят друг от друга и могут импортировать классы друг из друга. Но для этого случая и для того, чтобы приложения могли «извлекаться», нам нужны API-интерфейсы вызовов или чтобы уровень связи оставался абстрактным. Кроме того, это приложения для работы с кадрами, поэтому мы не беспокоимся о визуализации просмотра.