@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 — перенос не составит труда :)