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?
fuente
flask-babelsoporte para múltiples idiomas y elflask-seasurfsoporte CSRF para proteger mis formularios.Respuestas:
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.
fuente
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.
fuente
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.
fuente
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
fuente
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.
fuente