AppEngine Gotchas
Logo após o lançamento do Google App Engine, uma das notícias que saíram sobre ele chamava-se Google App Engine : Easy to build, easy to maintain, and easy to scale . Após usá-lo por um período, eu diria que é fácil de manter e escalar, mas não tão fácil de construir, devido tanto a restrições arquiteturais quando à alguns pequenos bugs no SDK.
Sandbox e limitações
À semelhança do zope, o appengine oferece uma sandbox. Você tem um runtime do Python 2.5.2, mas algumas coisas estão limitadas: escrita em filesystem é proibida, alguns módulos não podem ser importados, e toda a comunicação com o mundo externo só pode ser feita através da urlfetch, e fazendo apenas requisiçõs HTTP e HTTPS (portas 80 e 443). Curiosamente, na primeira versão, mesmo a execução das APIS do gdata eram impossíveis dentro do appengine, mas logo depois eles liberaram uma nova versão com suporte a requisições através do urlfetch. Não é possível executar um subprocesso, nem executar tarefas agendadas. É um impacto razoavelmente pequeno, mas ainda assim presente.
Você pode enviar apenas 1000 arquivos no máximo. Parece muito, mas é um limite fácil de ser batido. E como não tem zipimport lá ainda, fica difícil de enviar os eggs compactados. Não chega a afetar os usuários do Django, que já tem uma versão do Django lá e não precisam enviar o Django em si, mas usuários que queiram testar outros frameworks, acabam tendo o espaço seriamente comprometido. Aliás, não existe uma forma prática de rodar outro framework, principalmente um que seja centrado em eggs, como o Pylons, devido à restrição de módulos. Ian Bicking criou um projeto chamado App Engine Monkey, que basicamente, permite o uso de eggs (não compactados) no AppEngine. Através dele é possível rodar Pylons, e possivelmente, outros frameworks.
É possível enviar seus próprios pacotes e bibliotecas para o appengine, com a exceção de que eles não usem módulos implementados em C, ou seja: apenas puro python.
Bugs no SDK
É interessante, alguns bugs acontecem no SDK apenas, mas não no servidor de produção. Mas você tem de aplicar alguns patches no seu SDK para se livrar dos bugs!
A importação de objetos em massa (bulkloader) usa o módulo csv do Python. Mas o módulo csv não tem suporte a UTF-8. É possível corrigir esse problema aplicando no SDK o patch descrito no bug 157. Isso resolve a importação no SDK, mas não no servidor de desenvolvimento.
Os cabeçalhos das requisições vem sempre em minúsculas. No meu caso, o gdata estava esperando por Location, mas recebeu location. Um caso simples de resolver.
Ao fazer requisições com o urlfetch, os parâmetros de querystring não são enviados. É um bug que afeta só o SDK, e também simples de resolver.
Django
O suporte a Django é builtin, mas devido a própria estrutura do Django algumas coisas não funcionarão como um Django comum. Por exemplo, o admin do Django depende dos models do Django. Como no AppEngine, estamos amarrados ao próprio banco do Google, o admin fica de fora. Logo, fica de fora uma característica utilissima do Django: a serialização de um objeto do Model em JSON.
Assim como surgiu o projeto para rodar o Pylons no AppEngine, existe um outro projeto, que permite que o Django seja mais Django no Appengine, com a possibilidade de executar a maioria dos comandos do manage.py, traz de volta a serialização de modelos pra JSON e torna possível o envio de e-mails usando a própria API do Django.
A parte boa
O logging funciona, muito bem por sinal, e a tela para visualizar os logs da sua aplicação é bem intuitiva. Resta ainda toda a discussão de se deixar os dados no google é bacana ou não. As restrições as vezes enchem, mas com um pouco de paciência, é possível chegar à uma convivência amigável com o AppEngine.
Syndicated 2008-05-23 16:07:05 (Updated 2008-05-23 17:17:02) from devlog
