Определенно лучше прыгнуть в Play (или django), а затем смешивать оба решения. Причина одна, основная. Хотя можно смешивать один фреймворк с другим или даже смешивать фреймворки из разных языков, во-первых... вам нужно как минимум очень хорошо знать все элементы. Затем вы можете искать наиболее оптимальные способы их соединения и использовать лучшие части каждого, чтобы получить наилучший возможный результат.
Поскольку де-факто подходы Play и djangos очень похожи, я не вижу веских причин пытаться их соединить, тем более, когда большая часть команды использует одно решение, лучший вариант — следовать им.
Хотя, как вы написали, вы также новичок в django, этот переключатель не должен быть проблемой. Вы можете просто в будущем написать аналогичный проект на django и сравнить производительность, производительность и т. д. Может быть, тогда вы убедите своих коллег попробовать что-то еще.
Кстати: обмен сообщениями между двумя приложениями должен осуществляться с помощью задокументированных API, просто рассматривайте друг друга как «чужой» сервис. Вы можете совместно использовать базу данных, но убедитесь, что фреймворки не дублируют функции.
Другими словами, если вы будете писать ContenteManager на django, убедитесь, что ребята из Play подключаются к БД как к клиенту, или наоборот, не пытайтесь смешивать ответственность между двумя решениями (даже если они написаны на одном языке). /framework), потому что вы потерпите неудачу.
person
biesior
schedule
20.11.2012