yurtaev3 мар 2012 в 15:29

Поддержка Django приложений в Google App Engine

3 мин

3.9K

Django *

+30

Комментарии 20

qmax 3 мар 2012 в 16:36

Непонятно, почему не выстрелило.
Было много разговоров о том, что документ-ориентированные базы гораздо удобнее для веба вообще.
Да и с точки зрения банальной эрудиции, данные интернет-магазина, например, удобнее и эффективнее хранить документами, а не вытаскивать мега-джойнами.

yurtaev 3 мар 2012 в 16:40

Я согласен с тем что документ-ориентированные базы это супер удобно, тут вопрос в том какие инструменты предоставляет google для разработки приложения. Нам дали API, вот и крутимся как можем у кого руки чешутся.

qmax 3 мар 2012 в 16:47

Тут согласен, webapp, webapp2 до django никак не дотягивают, а tipfy, кажется, умер.
Однакож сердце фреймворка — ORM, который в GAE по сути вообще не нужен. А Guido vanRossum пилит более адекватный API к базе.

Но это всё не имеет отношения к SQL

printf 3 мар 2012 в 16:52

Основная проблема в другом. Это все может быть очень удобно, но писать код только под GAE — серьезный риск. Если завтра AppEngine по какой-то причине перестанет устраивать, придется переписывать всю логику работы с СУБД, файлами — для проектов крупнее бложика, а тем более серьезных коммерческих проектов это никуда не годится.

Frenzy 4 мар 2012 в 00:37

На самом деле не выстрелило, потому что банально ДОРОГО. Как только приложение переходит в разряд highload готовимся к сумасшедшим счетам. Но это относится ко многим клаудам, тот же Heroku взять например. Только с другого облачного сервиса можно было спрыгнуть на свои сервера, если проект выстрелит, а в случае с GAE полный vendor lock-in, в основе которого своя БД.

Так что гуглу некуда деваться, надо дать людям то, что они хотят, конкуренты (с упомянутым Heroku во главе) сильно поджимают.

gunya 4 мар 2012 в 10:32

Можно свалить, можно. appscale.cs.ucsb.edu/ же

qmax 3 мар 2012 в 16:36

По поводу проектов поверх GAE — gmail, googledocs, googlemaps и прочее — разве не на gae построены?

yurtaev 3 мар 2012 в 16:44

Нет, GAE это лишь попытка продать свои простаивающие мощности. Я конечно не могу точно сказать, но я очень сомневался бы если gmail на 100% совместим с GAE. По началу энтузиасты строили решения на GAE в надежде что их купит гугл, так как интеграцию будет проще делать. А еще гугл обещал выдержать милион посетителей и почти не брать за это деньги, но оказалось что это очень дорого, особенно если много писать в базу.

baka_cirno 3 мар 2012 в 16:46

Нет. Разве что может использоваться Bigtable, но совсем через другие интерфейсы.

igrishaev 4 мар 2012 в 02:53

Прекрасно.
Но если проект не на Джанге, а на другом фреймворке? Кто-нибудь знает, как связать SQLAlchemy с CloudSQL?

yurtaev 4 мар 2012 в 05:30

Судя по документаций трудностей не должно быть, нам дают обычный доступ DB-API 2.0, нужно отдать свой «connect» для SQLAlchemy

igrishaev 4 мар 2012 в 06:49

Только не стоит забывать про то что GAE поддерживает библиотеки написанные только на чистом python, про все сишные модули стоит забыть

GAE поддерживает некоторые популярные сишные библиотеки, например, PIL, NumPy.

yurtaev 4 мар 2012 в 07:04

PIL используется только на локальной машине для эмуляций Images API

nimnull 4 мар 2012 в 07:51

В составе GAE уже идет набор неплохих «батареек», плюс появление python27 runtime сильно упростило работусо времён, когда была доступна 2.5 версия.
Кстати — странно что пост появился только сейчас CloudSQL анонсировали ажно 7-го ноября, а недавно вышла уже версия 1.6.3 SDK с поддержкой django 1.3
Правда проблем от этого не убавилось — отсутствуют инструменты нормальной миграции базы, что при длительной командной разработке проекта доставляет массу неудобств.

От себя хотел добавить — не нужно было пытаться взгромоздить django поверх Datastore — последний всё же noSQL решение и отношение должно быть соответствующим, но зато там были асинхронные запросы на чтение/запись, и в общем, я его до сих пор считаю неодооцененным. Попробуйте поработать с Datastore не стандартным google.appengine.ext.db а через google.appengine.ext.ndb — который с релиза 1.6.1 появился в составе SDK, Гвидо плохого не напишет :)

yurtaev 4 мар 2012 в 08:03

Я бы даже сказал что в октябре анонсировали, об 1.6.2 я сказал. Изначально писал статью типа – «создаем проект django на GAE», с инструкцией по шагам, но бросил это дело, кому надо тот понял суть, новички сюда не полезут.
На счет запуска django поверх Datastore, в сети много обсуждения этого, значит это кому то надо. Да это дикий костыль, но пользовались этим потому что иных инструментов по возможностям не было. Любой более-менее сложный проект приходилось писать с нуля руками, начиная авторизаций, заканчивая админкой.
Datastore это хорошо, я согласен, но это дорого, и перенести потом приложение на свой сервер допустим с монгой будет наверное так же затратно как написать приложение по новой.

nimnull 4 мар 2012 в 08:09

Практически согласен во всём, кроме повального увлечения django — есть куча хороших python-фреймворков отвязанных от ORM совершенно :)

По переносимости — работая ранее с ndb нашел множество похожих подходов у ребят сделавших asyncmongoorm поверх asyncmongo для tornado — так что, если код раньше был на чем-то вроде webapp — перенос не составит труда :)