Flask vs webapp2 para Google App Engine

Estou começando um novo aplicativo Google App Engine e atualmente considerando duas estruturas: Flask e webapp2 . Estou bastante satisfeito com a estrutura de webapp integrada que usei para meu aplicativo anterior do App Engine, então acho que webapp2 será ainda melhor e não terei problemas com ele.

No entanto, há muitas análises boas do Flask, eu realmente gosto de sua abordagem e de todas as coisas que li até agora na documentação e quero experimentá-lo. Mas estou um pouco preocupado com as limitações que posso enfrentar no futuro com o Flask.

Portanto, a pergunta é - você conhece algum problema, problema de desempenho, limitações (por exemplo, sistema de roteamento, mecanismo de autorização integrado, etc.) que o Flask poderia trazer para o aplicativo Google App Engine? Por "problema" quero dizer algo que não consigo contornar em várias linhas de código (ou qualquer quantidade razoável de código e esforços) ou algo que é completamente impossível.

E como pergunta de acompanhamento: há algum recurso matador no Flask que você acha que pode me surpreender e me fazer usá-lo, apesar de quaisquer problemas que eu possa enfrentar?

Isenção de responsabilidade: eu sou o autor de tipfy e webapp2.

Uma grande vantagem de manter o webapp (ou sua evolução natural, webapp2) é que você não precisa criar suas próprias versões para manipuladores SDK existentes para a estrutura de sua escolha.

Por exemplo, deferred usa um manipulador de webapp. Para usá-lo em uma visualização de Flask puro, usando werkzeug.Request e werkzeug.Response, você precisará implementar adiado para ele (como fiz aqui para tipfy).

O mesmo acontece com outros manipuladores: blobstore (Werkzeug ainda não oferece suporte a solicitações de intervalo, então você precisará usar WebOb mesmo se criar seu próprio manipulador - consulte tipfy.appengine.blobstore ), mail, XMPP e assim por diante, ou outros que serão incluídos no SDK no futuro.

E o mesmo acontece para bibliotecas criadas com o App Engine em mente, como ProtoRPC , que é baseado em webapp e precisaria de uma porta ou adaptador para funcionar com outras estruturas, se você não quiser misturar webapp e your-framework-of- manipuladores de escolha no mesmo aplicativo.

Portanto, mesmo que escolha uma estrutura diferente, você terminará a) usando webapp em alguns casos especiais ou b) tendo que criar e manter suas versões para manipuladores ou recursos específicos do SDK, se for usá-los.

Eu prefiro muito mais o Werkzeug em vez do WebOb, mas depois de mais de um ano portando e mantendo versões dos manipuladores SDK que funcionam nativamente com o tipfy, percebi que esta é uma causa perdida - para suportar o GAE a longo prazo, o melhor é ficar perto de webapp / WebOb. Facilita o suporte para bibliotecas SDK, a manutenção se torna muito mais fácil, é mais preparada para o futuro, pois as novas bibliotecas e recursos do SDK funcionarão imediatamente e há o benefício de uma grande comunidade trabalhando em torno das mesmas ferramentas do App Engine.

Uma defesa específica do webapp2 é resumida aqui . Acrescente a isso que o webapp2 pode ser usado fora do App Engine e é fácil de ser personalizado para se parecer com microestruturas populares e você tem um bom conjunto de motivos convincentes para fazer isso. Além disso, o webapp2 tem uma grande chance de ser incluído em uma versão futura do SDK (isso é extra-oficial, não me cite :-), o que o impulsionará e trará novos desenvolvedores e contribuições.

Dito isso, sou um grande fã de Werkzeug e dos caras do Pocoo e peguei muito emprestado do Flask e outros (web.py, Tornado), mas - e, você sabe, sou tendencioso - os benefícios do webapp2 acima deveriam ser tidos em consideração.

Sua pergunta é extremamente ampla, mas parece não haver grandes problemas para usar o Flask no Google App Engine.

Este tópico da lista de e-mails tem links para vários modelos:

http://flask.pocoo.org/mailinglist/archive/2011/3/27/google-app-engine/#4f95bab1627a24922c60ad1d0a0a8e44

E aqui está um tutorial específico para a combinação Flask / App Engine:

http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/

Além disso, consulte App Engine - Dificuldade em acessar dados do Twitter - Flask , falha de flash de mensagem do Flask em redirecionamentos e Como gerencio bibliotecas Python de terceiros com o Google App Engine? (virtualenv? pip?) para problemas que as pessoas tiveram com o Flask e o Google App Engine.

Para mim, a decisão pelo webapp2 foi fácil quando descobri que o flask não é um framework orientado a objetos (desde o início), enquanto o webapp2 é um framework puro orientado a objetos. webapp2 usa o Despacho Baseado em Método como padrão para todos os RequestHandlers (como a documentação do flask o chama e o implementa desde a V0.7 em MethodViews). Embora em flask MethodViews sejam um add-on, é um princípio de design central para webapp2. Portanto, o design do seu software terá uma aparência diferente usando as duas estruturas. Ambos os frameworks usam modelos jinja2 hoje em dia e têm recursos bastante idênticos.

Eu prefiro adicionar verificações de segurança a um RequestHandler de classe base e herdar dele. Isso também é bom para funções de utilitário, etc. Como você pode ver, por exemplo, no link [3], você pode substituir métodos para evitar o despacho de uma solicitação.

Se você é uma pessoa OO, ou se precisa projetar um servidor REST, eu recomendaria o webapp2 para você. Se você preferir funções simples com decoradores como manipuladores para vários tipos de solicitação, ou se não se sente confortável com a herança OO, escolha flask. Acho que ambos os frameworks evitam a complexidade e dependências de frameworks muito maiores, como a pirâmide.

1. http://flask.pocoo.org/docs/0.10/views/#method-based-dispatching
2. https://webapp-improved.appspot.com/guide/handlers.html
3. https://webapp-improved.appspot.com/guide/handlers.html#overriding-dispatch

Eu acho que o Google App Engine suporta oficialmente o Flask Framework. Há um exemplo de código e tutorial aqui -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

Eu não experimentei o webapp2 e descobri que o tipfy era um pouco difícil de usar, pois requer scripts de configuração e compilações que configuram a instalação do seu python para algo diferente do padrão. Por essas e outras razões, não fiz meu maior projeto depender de uma estrutura e, em vez disso, uso o webapp simples, adiciono a biblioteca chamada beaker para obter capacidade de sessão e django já tem traduções integradas para palavras comuns a muitos casos de uso, então ao construir um O aplicativo localizado django foi a escolha certa para meu maior projeto. Os 2 outros frameworks que eu realmente implantei com projetos em um ambiente de produção foram GAEframework.com e web2py e geralmente parece que adicionar um framework que muda seu mecanismo de template pode levar a incompatibilidades entre versões antigas e novas.

Então, minha experiência é que estou relutante em adicionar uma estrutura aos meus projetos, a menos que eles resolvam os casos de uso mais avançados (upload de arquivo, multiautoria, interface do usuário administrativa são 3 exemplos de casos de uso mais avançados que nenhuma estrutura para gae no momento lida bem.