¿Por qué usar Django en Google App Engine?

Al investigar Google App Engine (GAE), está claro que el uso de Django es muy popular para desarrollar en Python en GAE. He estado buscando en la web para encontrar información sobre los costos y beneficios de usar Django, para descubrir por qué es tan popular. Si bien he podido encontrar una amplia variedad de fuentes sobre cómo ejecutar Django en GAE y los diversos métodos para hacerlo, no he encontrado ningún análisis comparativo sobre por qué Django es preferible a usar el marco de aplicaciones web proporcionado por Google.

Para ser claros, es evidente de inmediato por qué usar Django en GAE es útil para desarrolladores con un conjunto de habilidades existentes en Django (la mayoría de los desarrolladores web de Python, sin duda) o código existente en Django (donde usar GAE es más un ejercicio de migración). Mi equipo, sin embargo, está evaluando GAE para su uso en un proyecto completamente nuevo y nuestra experiencia actual es con TurboGears, no con Django.

Ha sido bastante difícil determinar por qué Django es beneficioso para un equipo de desarrollo cuando las bibliotecas BigTable han reemplazado al ORM de Django, las sesiones y la autenticación se cambian necesariamente y la plantilla de Django (si se desea) está disponible sin usar toda la pila de Django.

Finalmente, está claro que usar Django tiene la ventaja de proporcionar una "estrategia de salida" si luego quisiéramos alejarnos de GAE y necesitamos una plataforma a la que apuntar para el éxodo.

Estaría muy agradecido por la ayuda para señalar por qué usar Django es mejor que usar una aplicación web en GAE. También soy completamente inexperto con Django, por lo que la elaboración de características y / o comodidades más pequeñas que funcionan en GAE también son valiosas para mí.

Usamos django en nuestras instancias de appengine principalmente cuando tenemos que ofrecer sitios web reales al usuario. Tiene un gran motor de plantillas, enrutamiento de URL y todo el manejo de solicitudes / respuestas / errores integrado. Así que aunque no podamos usar las cosas mágicas de orm / admin, tiene mucho que ofrecer.

Para los servicios de API, construimos algo muy simple además de webob. Es mucho más ligero porque no necesita todo lo que ofrece django y, por tanto, es un poco más rápido en algunas situaciones.

Django probablemente no sea la opción adecuada para usted, si está seguro de que GAE es adecuado para usted. Las fortalezas de las dos tecnologías no se alinean muy bien: pierdes por completo gran parte del maravilloso formato de Django en GAE, y si lo usas, escribes código que no es realmente adecuado para bigtable y la forma en que funciona GAE.

Lo que pasa con GAE es que obtiene una gran escalabilidad al obligarlo a escribir código que se escala fácilmente desde cero. Simplemente no puede hacer una serie de cosas que escalen mal (por supuesto, aún puede escribir código de escalado deficiente, pero evita algunos errores). La compensación es que realmente terminas codificando alrededor del marco, si usas algo como Django, que está diseñado para un entorno diferente.

Si alguna vez se ve saliendo de GAE por cualquier motivo, invertir en la infraestructura es un problema para usted. La codificación para bigtable significa que será más difícil pasar a una arquitectura diferente (aunque el proyecto apache está trabajando para resolver esto por usted con el componente HBase del proyecto Hadoop). Aún sería mucho trabajo hacer la transición fuera de GAE.

¿Cuál es el motivador que impulsa el uso de GAE, además de ser un producto de Google y una palabra de moda? ¿Hay alguna razón por la que escalar usando algo como la oferta de mediatemple probablemente no funcione bien para usted? ¿Está seguro de que las formas en que GAE escala son las adecuadas para su aplicación? ¿Cómo se compara el costo con los servidores dedicados, si espera llegar a ese ámbito de rendimiento? ¿Puede resolver bien su problema utilizando las herramientas que proporciona GAE, en comparación con una configuración de servidor con equilibrio de carga más tradicional?

Dicho todo esto, a menos que necesite absolutamente la escala ridícula que ofrece GAE, personalmente sugiero que no permita que ese servicio en particular estructura su elección de marco. Me gusta Django, así que diría que debería usarlo, pero no en GAE.

Editar (junio de 2010): como actualización de este comentario en algún momento posterior: Google ha anunciado capacidades similares a sql para GAE que no son gratuitas, pero que le permitirán hacer cosas fácilmente como ejecutar comandos de estilo SQL para generar informes sobre sus datos.

Además, hay próximos cambios en el lenguaje de consulta GAE que permitirán consultas complejas de una manera mucho más sencilla. Mire los videos de Google I / O 2010.

Además, se está trabajando durante el proyecto Summer of Code 2010 que debería brindar soporte sin sql al núcleo de django y, por extensión, hacer que trabajar con GAE sea significativamente más fácil.

GAE se está volviendo más atractivo como plataforma de alojamiento.

Editar (agosto de 2011):

Y Google acaba de aumentar significativamente el costo para la mayoría de los usuarios de la plataforma al cambiar la estructura de precios. El problema de bloqueo ha mejorado (si su aplicación es lo suficientemente grande, puede implementar las alternativas de apache), pero para la mayoría de las aplicaciones, ejecutar servidores o implementaciones de VPS es más barato.

Muy pocas personas realmente tienen problemas de bigdata. "Oh, mi startup podría escalar algún día" no es un gran problema de datos. Construye cosas ahora y sácalas de la puerta usando las herramientas estándar.

He hecho muchos proyectos en GAE. Algunos en django, otros en su marco normal.

Para cosas pequeñas, suelo usar su marco normal para simplificar y agilizar. Como http://stdicon.com , http://yaml-online-parser.appspot.com/ o http://text-twist.appspot.com/ .

Para cosas grandes, utilizo django para aprovechar todos los complementos y middleware agradables. Como http://metaward.com .

Básicamente, mi prueba de fuego es: ¿Me llevará más de 2 semanas escribir y ser un proyecto de software REAL ? Si es así, vaya con django para los complementos.

Tiene el beneficio adicional de que, si su proyecto no es adecuado para BigTable, entonces se transfiere rápidamente (como hice yo, ¿BigTable es lento o soy tonto? )

Creo que todas estas respuestas son un poco obsoletas.

Ahora puedes usar Google Cloud SQL

Django es un popular framework web de Python de terceros. Cuando se combina con Google Cloud SQL, todas sus funciones pueden ser totalmente compatibles con aplicaciones que se ejecutan en App Engine . La compatibilidad con el uso de Google Cloud SQL con Django la proporciona un backend de base de datos Django personalizado que envuelve el backend MySQL de Django.

https://cloud.google.com/python/django/appengine

una nueva noticia más es que hay soporte BETA para PostgreSQL

Tengo experiencia usando Django y no GAE. Según mis experiencias con Django, fue una configuración muy simplista y el proceso de implementación fue increíblemente fácil en términos de proyectos web. De acuerdo, tuve que aprender Python para realmente controlar bien las cosas, pero al final del día lo usaría nuevamente en un proyecto. Esto fue hace casi 2 años antes de que llegara a 1.0, así que mi conocimiento está un poco desactualizado.

Si está preocupado por cambiar de plataforma, supongo que esta sería una mejor opción.

No puedo responder a la pregunta, pero es posible que desee consultar web2py. Es similar a Django en muchos aspectos, pero su capa de abstracción de base de datos funciona en GAE y admite la mayor parte de la funcionalidad GAE (no todas, pero intentamos ponernos al día). De esta manera, si GAE funciona muy bien para usted, si no lo hace, puede mover su código a una base de datos diferente (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres y, pronto, Sybase y MongoDB ).

Si decide ejecutar su aplicación fuera de GAE, aún puede usar Django. Realmente no tendrás tanta suerte con la aplicación web de GAE

Todavía soy muy nuevo en el desarrollo de motores de aplicaciones de Google, pero las interfaces que proporciona Django parecen mucho mejores que las predeterminadas. Los beneficios dependerán de lo que esté utilizando para ejecutar Django en el motor de la aplicación. Google App Engine Helper para Django le permite utilizar toda la potencia de Google App Engine con algunas funciones de Django en el lateral.

Django non-rel intenta proporcionar la mayor cantidad posible de potencia de Django, pero ejecutándose en el motor de la aplicación para una posible escalabilidad adicional. En particular, incluye modelos de Django (una de las características principales de Django), pero esta es una abstracción con fugas debido a las diferencias entre las bases de datos relacionales y bigtable. Lo más probable es que haya compensaciones en funcionalidad y eficiencia, así como una mayor cantidad de errores y peculiaridades. Por supuesto, esto podría valer la pena en circunstancias como las descritas en la pregunta, pero de lo contrario, recomendaría encarecidamente usar el asistente al principio, ya que luego tiene la opción de avanzar hacia el motor de aplicación puro o Django non-rel más adelante. Además, si cambia a Django non-rel,