Flask vs webapp2 para Google App Engine

116

Estoy comenzando una nueva aplicación de Google App Engine y actualmente estoy considerando dos marcos: Flask y webapp2 . Estoy bastante satisfecho con el marco de trabajo de aplicaciones web incorporado que he usado para mi aplicación anterior de App Engine, así que creo que webapp2 será aún mejor y no tendré ningún problema con él.

Sin embargo, hay muchas buenas críticas de Flask, me gusta mucho su enfoque y todas las cosas que he leído hasta ahora en la documentación y quiero probarlo. Pero estoy un poco preocupado por las limitaciones que puedo enfrentar en el futuro con Flask.

Entonces, la pregunta es: ¿conoce algún problema, problemas de rendimiento, limitaciones (por ejemplo, sistema de enrutamiento, mecanismo de autorización incorporado, etc.) que Flask podría traer a la aplicación Google App Engine? Por "problema" me refiero a algo que no puedo solucionar en varias líneas de código (o cualquier cantidad razonable de código y esfuerzos) o algo que es completamente imposible.

Y como pregunta de seguimiento: ¿hay algunas características asesinas en Flask que creas que pueden hacerme volar la cabeza y hacer que lo use a pesar de los problemas que pueda enfrentar?

— Anton Moiseev
fuente

No sé mucho sobre webapp2, pero he estado usando Flask durante algunos meses y me encanta. Encontré complementos de matraces que realmente me ayudaron, como el flask-babelsoporte para múltiples idiomas y el flask-seasurfsoporte CSRF para proteger mis formularios.

— ThePloki

138

Descargo de responsabilidad: soy el autor de tipfy y webapp2.

Una gran ventaja de seguir con webapp (o su evolución natural, webapp2) es que no tiene que crear sus propias versiones para los controladores SDK existentes para el marco de su elección.

Por ejemplo, diferido usa un controlador de aplicación web. Para usarlo en una vista Flask pura, usando werkzeug.Request y werkzeug.Response, necesitará implementar diferido para él (como hice aquí para tipfy).

Lo mismo ocurre con otros controladores: blobstore (Werkzeug todavía no admite solicitudes de rango, por lo que deberá usar WebOb incluso si crea su propio controlador; consulte tipfy.appengine.blobstore ), correo, XMPP, etc. u otros que se incluyan en el SDK en el futuro.

Y lo mismo ocurre con las bibliotecas creadas con App Engine en mente, como ProtoRPC , que se basa en webapp y necesitaría un puerto o adaptador para funcionar con otros marcos, si no desea mezclar webapp y su marco de trabajo. controladores de elección en la misma aplicación.

Por lo tanto, incluso si elige un marco diferente, terminará a) usando la aplicación web en algunos casos especiales ob) teniendo que crear y mantener sus versiones para controladores o características específicas del SDK, si los usa.

Prefiero Werkzeug sobre WebOb, pero después de más de un año portando y manteniendo versiones de los controladores SDK que funcionan de forma nativa con tipfy, me di cuenta de que esta es una causa perdida: para respaldar GAE a largo plazo, lo mejor es estar cerca de webapp / WebOb. Hace que la compatibilidad con las bibliotecas del SDK sea muy sencilla, el mantenimiento se vuelve mucho más fácil, está más preparado para el futuro, ya que las nuevas bibliotecas y características del SDK funcionarán de forma inmediata y existe el beneficio de una gran comunidad que trabaja con las mismas herramientas de App Engine.

Una defensa específica webapp2 se resume aquí . Agregue a los que webapp2 se puede usar fuera de App Engine y es fácil de personalizar para que parezca micro-frameworks populares y tiene un buen conjunto de razones convincentes para hacerlo. Además, webapp2 tiene una gran posibilidad de incluirse en una futura versión del SDK (esto es extraoficial, no me cite :-) que lo impulsará y traerá nuevos desarrolladores y contribuciones.

Dicho esto, soy un gran admirador de Werkzeug y los chicos de Pocoo y tomé prestado mucho de Flask y otros (web.py, Tornado), pero, y, ya sabes, soy parcial, los beneficios de webapp2 anteriores deberían ser tomado en cuenta.

— moraes
fuente

10

¡Gracias @moraes! Lo suficientemente sólido. Creo que cosas como blobstore, mail (y probablemente ProtoRPC) son piezas bastante importantes para ese proyecto, y quiero trabajar con ellas de la manera más fluida posible. Además, creo que mezclar diferentes marcos no es la mejor idea si puedes evitarlo fácilmente. Además, a pesar de que simpatizo con Flask, estoy realmente impresionado con webapp2 y tengo las manos ansiosas por probarlo. ¡Gracias por la respuesta y por webapp2!

— Anton Moiseev

3

@Sundar Puede ejecutarse en cualquier servidor web compatible con WSGI. Para Apache hay code.google.com/p/modwsgi y otros.

— moraes

4

@moraes: ¿Esta respuesta está desactualizada ahora? Puedo ver que GAE SDK es compatible con Flask. ¿Webapp2 sigue siendo la mejor opción?

— nal

1

@nish, ¿hace referencia a que GAE SDK es compatible con Flask oficialmente?

— enkash

15

Solo una nota, que si bien esta es la respuesta heredada aceptada, el desarrollo de webapp2 está muerto. Yo diría que Flask es el camino a seguir.

— Jesse

13

Su pregunta es extremadamente amplia, pero no parece haber grandes problemas al usar Flask en Google App Engine.

Este hilo de la lista de correo enlaza con varias plantillas:

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

Y aquí hay un tutorial específico para la combinación de Flask / App Engine:

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

Además, consulte App Engine - Dificultad para acceder a los datos de Twitter - Flask , el mensaje de Flask falla al parpadear en las redirecciones y ¿Cómo administro bibliotecas de Python de terceros con Google App Engine? (virtualenv? pip?) para los problemas que la gente ha tenido con Flask y Google App Engine.

— agf
fuente

7

Gracias, @agf. He visto la mayoría de estas publicaciones antes, pero creo que estoy más interesado en la experiencia personal. No creo que la pregunta sea tan amplia, ya que no me interesa una discusión exhaustiva o información detallada sobre un problema, solo indícame que esto y esto será difícil o imposible de implementar.

— Anton Moiseev

2

@Anton, Solicitar experiencia personal subjetiva está bastante cerca de las pautas de SO para preguntas que no se deben hacer .

— James

9

@James - No estoy de acuerdo. No les pregunto sobre sus conjeturas, suposiciones o sentimientos subjetivos. Le pregunto sobre su experiencia, es decir, sobre los hechos que conoce con confianza. No publicaciones obsoletas, ni problemas que otras personas hayan enfrentado durante una gran personalización, solo hechos. No está de acuerdo, está bien, solo márquelo.

— Anton Moiseev

3

Para mí, la decisión de webapp2 fue fácil cuando descubrí que flask no es un marco orientado a objetos (desde el principio), mientras que webapp2 es un marco orientado a objetos puro. webapp2 usa el envío basado en métodos como estándar para todos los RequestHandlers (como lo llama la documentación del matraz y lo implementa desde V0.7 en MethodViews). Si bien en el matraz MethodViews son un complemento, es un principio de diseño central para webapp2. Por lo tanto, el diseño de su software se verá diferente usando ambos marcos. Ambos frameworks usan hoy en día plantillas jinja2 y son bastante idénticas.

Prefiero agregar controles de seguridad a un RequestHandler de clase base y heredarlo. Esto también es bueno para funciones de utilidad, etc. Como puede ver, por ejemplo, en el enlace [3], puede anular métodos para evitar el envío de una solicitud.

Si eres una persona OO, o si necesitas diseñar un servidor REST, te recomendaría webapp2. Si prefiere funciones simples con decoradores como controladores para múltiples tipos de solicitudes, o si no se siente cómodo con la herencia OO, elija frasco. Creo que ambos marcos evitan la complejidad y las dependencias de marcos mucho más grandes como pirámide.

— gato
fuente

eso es todo, el apoyo de OOP me ganó. Originalmente uso web.py pero webapp2 parece tener una estructura ordenada sin la solución que hice en web.py. frasco puede ser fácil de comenzar, pero necesita más que eso si planea hacer aplicaciones más grandes

— Ahmad Muzakki

2

Creo que el motor de aplicaciones de Google es compatible oficialmente con el marco de matraces. Hay un código de muestra y un tutorial aquí -> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

— Anup
fuente

para mí, esto no es un soporte oficial, este es solo un ejemplo de estilo "también puedes hacerlo con Flask". Para webapp2, todavía hay un manual detallado con elementos específicos de GAE agregados aquí y allá.

— silpol

2

No probé webapp2 y descubrí que tipfy era un poco difícil de usar, ya que requería scripts de configuración y compilaciones que configuran su instalación de Python de forma distinta a la predeterminada. Por estas y otras razones, no he hecho que mi proyecto más grande dependa de un marco y utilizo la aplicación web simple en su lugar, agrego la biblioteca llamada beaker para obtener la capacidad de sesión y django ya tiene traducciones integradas para palabras comunes a muchos casos de uso, por lo que al construir un La aplicación localizada django fue la elección correcta para mi proyecto más grande. Los otros 2 marcos que implementé con proyectos en un entorno de producción fueron GAEframework.com y web2py y, en general, parece que agregar un marco que cambie su motor de plantillas podría generar incompatibilidades entre las versiones antiguas y nuevas.

Entonces, mi experiencia es que soy reacio a agregar un marco a mis proyectos a menos que resuelvan los casos de uso más avanzados (carga de archivos, autenticación múltiple, ui de administración son 3 ejemplos de casos de uso más avanzados que no hay un marco para gae en este momento maneja bien.

— Niklas R.
fuente