Por que usar Django no Google App Engine?

Ao pesquisar o Google App Engine (GAE), fica claro que usar Django é extremamente popular para desenvolvimento em Python no GAE. Tenho vasculhado a web para encontrar informações sobre os custos e benefícios do uso do Django, para descobrir por que ele é tão popular. Embora eu tenha conseguido encontrar uma grande variedade de fontes sobre como executar Django no GAE e os vários métodos de fazer isso, não encontrei nenhuma análise comparativa sobre por que o Django é preferível a usar a estrutura de webapp fornecida pelo Google.

Para ficar claro, é imediatamente aparente porque o uso do Django no GAE é útil para desenvolvedores com um conjunto de habilidades existente no Django (a maioria dos desenvolvedores da Web em Python, sem dúvida) ou código existente no Django (onde usar o GAE é mais um exercício de portabilidade). Minha equipe, no entanto, está avaliando o GAE para uso em um projeto totalmente novo e nossa experiência existente é com TurboGears, não Django.

É muito difícil determinar por que o Django é benéfico para uma equipe de desenvolvimento quando as bibliotecas BigTable substituíram o ORM do Django, as sessões e autenticação são necessariamente alteradas e o modelo do Django (se desejável) está disponível sem usar a pilha Django inteira.

Finalmente, está claro que o uso do Django tem a vantagem de fornecer uma "estratégia de saída" se mais tarde quisermos nos afastar do GAE e precisarmos de uma plataforma para o êxodo.

Eu ficaria extremamente grato pela ajuda em apontar o porquê usar Django é melhor do que usar webapp no ​​GAE. Eu também sou completamente inexperiente com Django, então a elaboração de recursos menores e / ou conveniências que funcionam no GAE também são valiosos para mim.

Usamos django em nossas instâncias do appengine principalmente quando temos que servir sites reais para o usuário. Ele tem um ótimo mecanismo de template, roteamento de url e todo o manuseio de solicitação / resposta / erro embutido. Então, mesmo que não possamos usar a mágica orm / admin, tem muito a seu favor.

Para os serviços de API, construímos algo muito simples webob. É muito mais leve porque não precisa de tudo que o django oferece e, portanto, é um pouco mais rápido em algumas situações.

Django provavelmente não é a escolha certa para você, se você tem certeza de que o GAE é certo para você. Os pontos fortes das duas tecnologias não se alinham muito bem - você perde completamente muito do maravilhoso orm do Django no GAE, e se o usar, você escreve um código que não é diretamente adequado para o bigtable e a maneira como o GAE funciona.

A vantagem do GAE é que ele obtém grande escalabilidade, forçando você a escrever um código que pode ser facilmente escalado desde o início. Você simplesmente não pode fazer uma série de coisas que escalam mal (é claro, você ainda pode escrever código de escalonamento insuficiente, mas evita algumas armadilhas). A desvantagem é que você realmente acaba codificando em torno do framework, se usar algo como Django, que é projetado para um ambiente diferente.

Se você se vir deixando o GAE por qualquer motivo, investir na infraestrutura é um problema para você. Codificar para bigtable significa que será mais difícil mudar para uma arquitetura diferente (embora o projeto apache esteja trabalhando para resolver isso para você com o componente HBase do projeto Hadoop). Ainda seria muito trabalho sair do GAE.

Qual é o motivador por trás do uso do GAE, além de ser um produto do Google e uma palavra da moda legal? Há alguma razão para que o dimensionamento usando algo como a oferta do mediatemple provavelmente não funcione bem para você? Tem certeza de que as escalas do GAE são adequadas para sua aplicação? Como o custo se compara a servidores dedicados, se você espera chegar a esse reino de desempenho? Você pode resolver seu problema bem usando as ferramentas que o GAE oferece, em comparação com uma configuração de servidor com balanceamento de carga mais tradicional?

Dito isso, a menos que você precise de forma absolutamente positiva do escalonamento quase ridículo que o GAE oferece, eu pessoalmente sugiro não deixar essa estrutura de serviço em particular sua escolha de framework. Gosto do Django, então diria que você deveria usá-lo, mas não no GAE.

Editar (junho de 2010): Como uma atualização para este comentário algum tempo depois: o Google anunciou recursos semelhantes ao sql para GAE que não são gratuitos, mas permitem que você faça coisas facilmente como executar comandos no estilo SQL para gerar relatórios sobre seus dados.

Além disso, há mudanças futuras na linguagem de consulta do GAE que permitirão consultas complexas de uma maneira muito mais fácil. Veja os vídeos do Google I / O 2010.

Além disso, há trabalho sendo feito durante o projeto Summer of Code 2010 que deve trazer suporte no-sql para o core django e, por extensão, tornar o trabalho com GAE significativamente mais fácil.

O GAE está se tornando mais atraente como plataforma de hospedagem.

Editar (agosto de 2011):

E o Google acabou de aumentar significativamente o custo para a maioria dos usuários da plataforma, alterando a estrutura de preços. O problema de lockin ficou melhor (se seu aplicativo for grande o suficiente, você pode implantar as alternativas do apache), mas para a maioria dos aplicativos, rodar servidores ou implantações VPS é mais barato.

Muito poucas pessoas realmente têm problemas de bigdata. "Oh, minha startup pode crescer algum dia" não é um grande problema de dados. Construa coisas agora e coloque-as em ação usando as ferramentas padrão.

Já fiz muitos projetos no GAE. Alguns em django, alguns em sua estrutura normal.

Para pequenas coisas, geralmente uso sua estrutura normal para simplicidade e rapidez. Como http://stdicon.com , http://yaml-online-parser.appspot.com/ ou http://text-twist.appspot.com/ .

Para coisas grandes, eu escolho o django para aproveitar todas as vantagens de middleware e plug-ins. Como http://metaward.com .

Basicamente, meu teste decisivo é Será que levarei mais de 2 semanas para escrever e ser um projeto de software REAL ?Em caso afirmativo, vá com django para os addons.

Ele tem o benefício adicional de, se seu projeto for inadequadamente adequado para BigTable, então você rapidamente transfere (como eu fiz O BigTable é lento ou sou burro? )

Acho que todas essas respostas são um pouco obsoletas.

Agora você pode usar Google Cloud SQL

Django é uma estrutura da web Python de terceiros popular. Quando combinado com o Google Cloud SQL, todas as suas funcionalidades podem ser totalmente suportadas por aplicativos executados no App Engine . O suporte para usar o Google Cloud SQL com Django é fornecido por um back-end de banco de dados Django personalizado que envolve o back-end MySQL do Django.

https://cloud.google.com/python/django/appengine

mais uma novidade é que há suporte BETA para PostgreSQL

Tenho experiência com Django e não GAE. De minhas experiências com Django, foi uma configuração muito simplista e o processo de implantação foi incrivelmente fácil em termos de projetos web. Concedido, tive que aprender Python para realmente ter um bom controle das coisas, mas no final do dia eu iria usá-lo novamente em um projeto. Isso foi há quase 2 anos antes de chegar a 1.0, então meu conhecimento está um pouco desatualizado.

Se você está preocupado em mudar de plataforma, então esta seria uma escolha melhor, suponho.

Não posso responder à pergunta, mas você pode querer dar uma olhada no web2py. É semelhante ao Django em muitos aspectos, mas sua camada de abstração de banco de dados funciona em GAE e suporta a maioria das funcionalidades do GAE (não todas, mas tentamos atualizá-la). Desta forma, se o GAE funcionar bem para você, se não funcionar, você pode mover seu código para um banco de dados diferente (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres e - em breve - Sybase e MongoDB )

Se você decidir executar seu aplicativo fora do GAE, ainda poderá usar o Django. Você realmente não terá tanta sorte com o GAE webapp

Ainda sou muito novo no desenvolvimento do mecanismo do Google App, mas as interfaces que o Django fornece parecem muito mais agradáveis ​​do que o padrão. Os benefícios dependerão do que você está usando para executar o Django no mecanismo de aplicativo. O Google App Engine Helper para Django permite que você use todo o poder do Google App Engine com algumas funcionalidades do Django auxiliar.

O Django non-rel tenta fornecer o máximo de poder do Django possível, mas rodando no app-engine para possível escalabilidade extra. Em particular, inclui modelos Django (um dos principais recursos do Django), mas esta é uma abstração que vaza devido às diferenças entre bancos de dados relacionais e bigtable. Provavelmente haverá compensações em termos de funcionalidade e eficiência, bem como um número maior de bugs e peculiaridades. Claro, isso pode valer a pena em circunstâncias como as descritas na pergunta, mas caso contrário, seria altamente recomendável usar o auxiliar no início, pois então você terá a opção de passar para o app-engine puro ou Django non-rel posteriormente. Além disso, se você mudar para Django non-rel,