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

88

Изучая 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.

python  django  google-app-engine 
— Трэвис Брэдшоу
источник
черт возьми, Терри Брэдшоу пишет код?
— Woot4Moo,
4
Django полезен, потому что он потрясающий. Это действительно так. :)
— jathanism
Я тоже новичок в движке приложений Google, и это ужасно хорошо сформулированный вопрос даже для 2018 года (хотя Django ORM, похоже, теперь намного лучше поддерживается в GAE). :)
— Divij Sehgal

Ответы:

19

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

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

— Коэн Бок
источник
1
Спасибо, Коэн. Отчасти мое замешательство относительно привлекательности Django проистекает из идеи, что маршрутизация URL-адресов и обработка запросов / ответов / ошибок также являются функциями предоставленного веб-приложения и что механизм шаблонов может использоваться без Django, а также с веб-приложением. Я ошибаюсь? Предоставляет ли Django эти услуги лучше, чем фреймворк webapp?
— Трэвис Брэдшоу,
Я бы сказал, что в django они более обширны и гибки. Так что лучше, если это действительно нужно :-)
— Коен Бок
2
Я думаю, что это тот ответ, который я ищу! Этот Django в значительной степени дублирует webapp, но с точки зрения общих функций Django делает его более гибким и надежным. Кажется, что это определенно решение «на пределе», но я думаю, что все остальные предложения, плюс ваше, дают убедительный ответ. Спасибо.
— Трэвис Брэдшоу,
1
Модули Python, написанные на C, также не поддерживаются.
— Ryu_hayabusa
51

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 в основном потому, что модель затрат хорошо соответствует нашему предложенному бизнес-плану. Возможность начать бесплатно, а затем постепенно масштабироваться с очень детальной моделью затрат очень привлекательна. Кроме того, мы не ожидаем, что в будущем потребуется переход с GAE или отказ от нее, и привязка к платформе для этого проекта приемлема. Я включил комментарий «стратегия выхода» в свой вопрос в первую очередь для того, чтобы быть достаточно исчерпывающим в том, что я узнал из чтения и исследования, прежде чем опубликовать этот вопрос. Еще раз спасибо!
— Трэвис Брэдшоу,
Как вы оцениваете стоимость времени разработки? Одна из приятных особенностей Django заключается в том, что вы тратите меньше времени на определение своих моделей данных, чем с Bigtable. Bigtable заставляет вас быть более ясными в отношении ваших действий, прежде чем вы вообще сможете его использовать. Некоторые запросы значительно упрощаются с "обычным" sql.
— Пол Макмиллан,
3
Будьте осторожны, не зажимайте пенни слишком сильно. Бесплатная - это хорошо, но услуга быстро стоит реальных денег. Если вы используете «бесплатный» уровень обслуживания, разместите его на каком-нибудь другом сервере / хостинге, за который вы уже платите. Если вы переходите на платный уровень обслуживания, то 20 долларов в месяц за VPS, который вы можете легко масштабировать позже, - это шум, поскольку его стоимость.
— Пол Макмиллан,
11
tbradshaw, не забывайте учитывать, как часто вам нужно будет запускать специальные отчеты по вашему набору данных. Я участвую в растущем социальном приложении, и GAE становится ... не скажу кошмаром, но извлечение знаний из наших данных чрезвычайно ресурсоемко. Из-за очистки старых журналов Google и чрезмерной длины, необходимой для просмотра всех данных, создание отчетов становится намного дороже, чем использование базы данных SQL. Это стоимость, которую я не учел, когда начинал. Во-вторых, если вы действительно вырастете и начнете зарабатывать деньги, то потеря контроля над резервным копированием является важным фактором.
— JasonSmith
2
Если вас интересует блокировка, попробуйте AppScale, который является клоном Google App Engine. Мы работаем над платформой с момента выхода GAE, и у нас есть много пользователей для своих производственных приложений на Python и Java. У вас есть прямой доступ к машинам, на которых он работает, поэтому у вас больше контроля над инфраструктурой. github.com/AppScale/appscale.git
— Наврадж Чохан
16

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

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

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

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

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

— Пол Тарджан
источник
+1, bigtable просто плохо подходит для некоторых проектов и запросов. Это здорово для того, что делает Google, и может быть ужасно для того, что вы хотите сделать.
— Пол Макмиллан,
Спасибо, Пол! Не могли бы вы связать меня с любыми ресурсами, описывающими промежуточное ПО Django и плагины, работающие с GAE? Если есть надстройки, полезные для нашего проекта, это, безусловно, будет поводом использовать Django, а не webapp. Очевидно, что наиболее полезные из них (например, сеанс и аутентификация) явно зависят от Django ORM.
— Трэвис Брэдшоу,
2
В принципе, любой аддон, у которого нет models.py, будет работать отлично. И если у них есть models.py, вы, вероятно, можете выполнить преобразование 1 в 1 в bigtable и по-прежнему использовать его, если хотите. Некоторые из них, которые я использую, - это django_annoying, django_debug_toolbar и из раздела contrib csrf, humanize и, конечно же, admin.
— Пол Тарджан,
11

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

Теперь вы можете использовать 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

— Andilabs
источник
3

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

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

— Woot4Moo
источник
1
Спасибо за ваш быстрый ответ! Хотя я согласен с тем, что Django - это фреймворк, который быстро запускается, нас это не беспокоит. У нас есть четыре довольно опытных разработчика Python с опытом веб-разработки, поэтому начало работы с любым фреймворком будет быстрым и безболезненным. Но при выборе между Django и webapp в GAE остается вопрос, что лучше и почему ?
— Трэвис Брэдшоу,
@ Woot4Moo, если у вас нет опыта работы с GAE, где вы его развертываете, я новичок в GAE, но цена меня сильно смущает, случайные огромные сборы, я думаю, pythonanywhere, не могли бы вы дать мне несколько рекомендаций?
— Manza
0

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

— mdipierro
источник
0

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

— Георгий Годик
источник
Спасибо, хотя я упоминаю именно это в исходном вопросе: «Наконец, ясно, что использование Django действительно имеет преимущество в виде« стратегии выхода », если мы позже захотим отойти от GAE и нам понадобится платформа для нацеливания на исход. "
— Трэвис Брэдшоу,
0

Я все еще новичок в разработке движка 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,

— Casebash
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.