Почему использование Django на Google App Engine?

При исследовании 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 лучше, чем использование веб-приложения на GAE. Я также абсолютно неопытен с Django, таким образом, разработка на меньших функциях и/или удобствах, которые работают над GAE, также ценна мне.

88
задан Blaszard 18 December 2016 в 09:16
поделиться

7 ответов

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

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

19
ответ дан 24 November 2019 в 07:37
поделиться

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

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

51
ответ дан 24 November 2019 в 07:37
поделиться

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

0
ответ дан 24 November 2019 в 07:37
поделиться

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

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

3
ответ дан 24 November 2019 в 07:37
поделиться

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

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

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

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

16
ответ дан 24 November 2019 в 07:37
поделиться

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

0
ответ дан 24 November 2019 в 07:37
поделиться

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

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

0
ответ дан 24 November 2019 в 07:37
поделиться
Другие вопросы по тегам:

Похожие вопросы: