- Вы не можете использовать весь ORM - используйте их собственный API BigTable.
- Вы не можете использовать библиотеку urllib - используйте их пользовательские urlfetch для извлечения чего-либо.
- Вы не можете использовать файловую систему - используйте API их blobstore.
- Существует ограничение по времени для завершения каждого запроса, каждого запроса в БД.
- Нельзя использовать какие-либо модули, использующие C. Memcached, PIL и многие другие полезные библиотеки.
- Вы изменяете свое приложение для их пользовательской аутентификации, пользовательского кэширования, пользовательских миниатюр изображений и т. Д.
По сути, вы должны написать все приложение для их пользовательского API и инфраструктуры. Все, что вы получаете от django, на самом деле - это механизм шаблонов и библиотека форм, и в Python нет недостатка в хороших для них.
Использование встроенных стандартов django обеспечивает переносимость между базами данных, между системами кэширования, между механизмами аутентификации и т. Д. - Обычно вы отказываетесь от участия в инфраструктуре Appengine, когда кодируете ее. В проекте django-nonrel делается попытка сделать специфику Appengine одним из базовых для каждого из них. Он также поддерживает запросы ORM, но поддерживает только определенные типы объединений и дает сбой не так легко предсказуемым образом. - Бэкэнды аутентификации и кэширования кажутся надежными.
Django и Appengine - определенно не состязание на небесах. Вы, разработчик, должны принять тепло их дискомфорта. Если вы хотите разместить на AppEngine, могу ли я предложить Flask (или bottle ) в качестве инструмента разработки, и если вы ищете Django в качестве инструмента разработки, могу ли я предложить ep.io (или djangy ) в качестве места назначения облачного хостинга.