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

Question

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

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

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

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

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

Answer 1

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 обходится дешевле.

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

Answer 2

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

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

Answer 3

Я сделал много проектов на GAE. Некоторые в django, некоторые в их нормальных рамках.

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

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

По сути, мой лакмусовый тест Это займет у меня больше 2 недель, чтобы написать и стать программным проектом REAL ? Если это так, воспользуйтесь django для дополнений.

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

Answer 4

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

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

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

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

Еще одна свежая новость в том, что есть бета-версия PostgreSQL

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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