Зачем использовать Django в Google App Engine?

Изучая Google App Engine (GAE), становится ясно, что использование Django очень популярно для разработки на Python на GAE. Я рыскал по сети, чтобы найти информацию о затратах и ​​преимуществах использования Django, чтобы понять, почему он так популярен. Хотя мне удалось найти множество источников о том, как запускать Django в GAE и о различных методах этого, я не нашел сравнительного анализа того, почему Django предпочтительнее использования фреймворка webapp, предоставляемого Google.

Чтобы быть ясным, сразу становится очевидным, почему использование Django в GAE полезно для разработчиков с существующим набором навыков в Django (большинство веб-разработчиков Python, без сомнения) или существующего кода в Django (где использование GAE - это скорее упражнение по переносу). Моя команда, однако, оценивает GAE для использования в совершенно новом проекте, и у нас есть опыт работы с TurboGears, а не с Django.

Было довольно сложно определить, почему Django полезен для команды разработчиков, когда библиотеки BigTable заменили ORM Django, сеансы и аутентификация обязательно изменены, а шаблоны Django (при желании) доступны без использования всего стека Django.

Наконец, ясно, что использование Django действительно имеет то преимущество, что предоставляет «стратегию выхода», если позже мы захотим отойти от GAE и нам понадобится платформа для нацеливания на исход.

Я был бы чрезвычайно признателен за помощь, чтобы указать, почему использование Django лучше, чем использование веб-приложения в GAE. Я также совершенно не разбираюсь в Django, поэтому для меня также важна проработка более мелких функций и / или удобств, которые работают с GAE.

Мы используем django в наших экземплярах appengine в основном, когда нам нужно обслуживать реальные веб-сайты для пользователя. В нем есть отличный механизм шаблонов, маршрутизация URL и вся встроенная обработка запросов / ответов / ошибок. Так что, даже если мы не можем использовать волшебный механизм orm / admin, у него есть много чего.

Для сервисов api мы построили что-то очень простое поверх webob. Он намного легче, потому что ему не нужно все, что предлагает django, и поэтому в некоторых ситуациях он работает немного быстрее.

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

Особенность GAE в том, что он обеспечивает отличную масштабируемость, заставляя вас писать код, который легко масштабируется с нуля. Вы просто не можете делать ряд вещей, которые плохо масштабируются (конечно, вы все равно можете написать плохо масштабируемый код, но вы избежите некоторых подводных камней). Компромисс заключается в том, что вы действительно заканчиваете кодирование вокруг фреймворка, если вы используете что-то вроде Django, разработанного для другой среды.

Если вы видите, что когда-либо покидаете GAE по какой-либо причине, значит, инвестируя в инфраструктуру, вы столкнетесь с проблемой. Кодирование для bigtable означает, что будет труднее перейти на другую архитектуру (хотя проект apache пытается решить эту проблему за вас с помощью компонента HBase проекта Hadoop). По-прежнему потребуется много работы для перехода от GAE.

Что является движущей силой использования GAE, помимо того, что это продукт Google и классное модное слово? Есть ли причина, по которой масштабирование с использованием чего-то вроде предложения mediatemple вряд ли сработает для вас? Вы уверены, что способы масштабирования GAE подходят для вашего приложения? Какова стоимость по сравнению с выделенными серверами, если вы рассчитываете достичь этой области производительности? Можете ли вы решить свою проблему с помощью инструментов, которые предоставляет GAE, по сравнению с более традиционной настройкой сервера с балансировкой нагрузки?

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

Изменить (июнь 2010 г.): в качестве обновления этого комментария когда-нибудь позже: Google анонсировал sql-подобные возможности для GAE, которые не бесплатны, но позволят вам легко выполнять такие действия, как запуск команд в стиле SQL для создания отчетов по вашим данным.

Кроме того, в языке запросов GAE есть предстоящие изменения, которые сделают сложные запросы намного проще. Посмотрите видео с Google I / O 2010.

Кроме того, в рамках проекта Summer of Code 2010 ведется работа, которая должна обеспечить поддержку no-sql в ядре django и, как следствие, значительно упростить работу с GAE.

GAE становится все более привлекательной в качестве хостинговой платформы.

Изменить (август 2011 г.):

А Google просто значительно повысил стоимость платформы для большинства пользователей, изменив структуру ценообразования. Проблема блокировки стала лучше (если ваше приложение достаточно велико, вы можете развернуть альтернативы apache), но для большинства приложений запуск серверов или развертывание VPS обходится дешевле.

У очень немногих людей действительно есть проблемы с большими данными. «О, мой стартап может когда-нибудь масштабироваться» - это не проблема больших данных. Создавайте вещи прямо сейчас и выпускайте их, используя стандартные инструменты.

Я сделал много проектов на GAE. Некоторые в django, некоторые в обычном фреймворке.

Для мелочей я обычно использую их обычные рамки для простоты и скорости. Например, http://stdicon.com , http://yaml-online-parser.appspot.com/ или http://text-twist.appspot.com/ .

Для больших вещей я использую django, чтобы воспользоваться всеми хорошими промежуточными программами и плагинами. Как http://metaward.com .

В основном моя лакмусовая бумажка - это займет у меня больше 2 недель, чтобы написать и стать НАСТОЯЩИМ программным проектом? Если это так, используйте django для дополнений.

У него есть дополнительное преимущество: если ваш проект плохо подходит для BigTable, вы быстро переносите его (например, я сделал это медленно, или я тупой? )

Я думаю, что все эти ответы немного устарели.

Теперь вы можете использовать Google Cloud SQL

Django - популярный сторонний веб-фреймворк Python. В сочетании с Google Cloud SQL все его функции могут полностью поддерживаться приложениями, работающими в App Engine . Поддержка использования Google Cloud SQL с Django обеспечивается специальной серверной частью базы данных Django, которая является оболочкой для базы данных MySQL Django.

https://cloud.google.com/python/django/appengine

Еще одна свежая новость - есть поддержка BETA для PostgreSQL

У меня есть опыт использования Django, а не GAE. Судя по моему опыту работы с Django, это была очень упрощенная установка, а процесс развертывания был невероятно простым с точки зрения веб-проектов. Конечно, мне пришлось выучить Python, чтобы действительно хорошо разбираться в вещах, но в конце концов я снова использовал его в своем проекте. Это было почти 2 года назад, прежде чем он достиг 1.0, так что мои знания немного устарели.

Если вы беспокоитесь о смене платформы, я думаю, это будет лучшим выбором.

Я не могу ответить на этот вопрос, но вы можете изучить web2py. Он во многом похож на Django, но его уровень абстракции базы данных работает с GAE и поддерживает большую часть функций GAE (не все, но мы пытаемся наверстать упущенное). Таким образом, если GAE отлично работает для вас, а если нет, вы можете переместить свой код в другую базу данных (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres и - скоро - в Sybase и MongoDB. ).

Если вы решите запустить приложение вне GAE, вы все равно можете использовать Django. Вам не повезет с веб-приложением GAE

Я все еще новичок в разработке движка Google App, но интерфейсы, предоставляемые Django, кажутся намного лучше, чем стандартные. Преимущества будут зависеть от того, что вы используете для запуска Django на движке приложения. Помощник Google App Engine для Django позволяет использовать всю мощь Google App Engine с некоторыми дополнительными функциями Django.

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