Flask vs webapp2 para Google App Engine

116

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?

— Anton Moiseev
fonte

Não sei muito sobre webapp2, mas uso o Flask há alguns meses e adoro. Encontrei plug-ins de flask que realmente me ajudaram, como flask-babelpara suporte a vários idiomas e flask-seasurfpara suporte CSRF para proteger meus formulários.

— ThePloki

138

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.

— moraes
fonte

10

Obrigado, @moraes! Sólido o suficiente. Acho que coisas como blobstore, mail (e provavelmente ProtoRPC) são peças muito importantes para esse projeto e quero trabalhar com elas da maneira mais tranquila possível. Além disso, acho que misturar diferentes frameworks não é a melhor ideia se você puder evitá-lo facilmente. Além disso, apesar do fato de eu simpatizar com o Flask, estou realmente impressionado com o webapp2 e estou com as mãos loucas para experimentá-lo. Obrigado pela resposta e pelo webapp2!

— Anton Moiseev

3

@Sundar Pode ser executado em qualquer servidor web compatível com WSGI. Para o Apache, há code.google.com/p/modwsgi e outros.

— moraes

4

@moraes: Esta resposta está desatualizada agora? Posso ver que o GAE SDK é compatível com Flask. O webapp2 ainda é a melhor escolha?

— termina em

1

@nish, referencia que o GAE SDK é oficialmente compatível com Flask?

— enkash

15

Apenas uma observação: embora esta seja a resposta aceita de legado, o desenvolvimento do webapp2 está morto. Eu diria que o Flask é o caminho a percorrer.

— Jesse

13

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.

— agf
fonte

7

Obrigado, @agf. Já vi muitos desses posts antes, mas acho que estou mais interessado na experiência pessoal. Não acho que a questão seja tão ampla, já que não estou interessado em uma discussão abrangente ou em informações detalhadas sobre um problema, apenas me aponte que isso e aquilo será difícil ou impossível de implementar.

— Anton Moiseev

2

@Anton, Solicitar experiência pessoal subjetiva está muito próximo das diretrizes do SO para perguntas que não devem ser feitas .

— James

9

@James - Não concordo. Não pergunto sobre suas suposições, suposições ou sentimentos subjetivos. Eu pergunto sobre a sua experiência, ou seja, sobre os fatos que você conhece com segurança. Não posts obsoletos, nem problemas que outras pessoas tenham enfrentado durante a customização pesada, apenas fatos. Não concordo - ok, apenas sinalize.

— Anton Moiseev

3

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.

— gato
fonte

é isso, o suporte OOP me conquistou. Eu originalmente uso o web.py, mas o webapp2 parece ter uma estrutura bonita sem a solução alternativa que fiz no web.py. flask pode ser fácil de começar, mas você precisa de mais do que isso se planeja fazer aplicativos maiores

— Ahmad Muzakki

2

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

— Anup
fonte

para mim, este não é um suporte oficial, este é apenas um exemplo do estilo "você também pode fazer isso com o Flask". Para webapp2, ainda há um manual detalhado com itens específicos do GAE adicionados aqui e ali.

— silpol 01 de

2

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.

— Niklas R.
fonte