¿Por qué usar Django en Google App Engine?


88

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í.


santa mierda terry bradshaw escribe código?
Woot4Moo

4
Django es beneficioso porque es asombroso. Eso es realmente. :)
jathanismo

También soy nuevo en el motor de aplicaciones de Google y esta es una pregunta terriblemente bien formada incluso para 2018 (aunque Django ORM parece que ahora es mucho mejor compatible con GAE). :)
Divij Sehgal

Respuestas:


19

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.


1
Gracias Koen. Parte de mi confusión en cuanto al atractivo de Django surgió de la idea de que el enrutamiento de URL y el manejo de solicitudes / respuestas / errores también eran características de la aplicación web proporcionada y que el motor de plantillas se puede usar sin Django y también con la aplicación web. ¿Estoy equivocado? ¿Django proporciona estos servicios mejor que el marco de la aplicación web?
Travis Bradshaw

Son más extensos y flexibles en django, diría yo. Así que es mejor si realmente lo necesitas :-)
Koen Bok

2
¡Creo que esta es la respuesta que estoy buscando! Ese Django es en gran parte redundante para la aplicación web, pero en la funcionalidad que comparten, Django lo hace de una manera más flexible y robusta. Parece que sin duda se trata de una decisión "marginal", pero creo que todas las demás sugerencias, más la suya, constituyen una respuesta convincente. Gracias.
Travis Bradshaw

1
Los módulos de Python escritos en C tampoco son compatibles.
Ryu_hayabusa

51

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.


Gracias por la atenta respuesta, Paul. Estamos evaluando GAE en gran parte porque el modelo de costos coincide bien con nuestro plan comercial propuesto. La capacidad de comenzar gratis y luego escalar gradualmente con un modelo de costos muy granular es muy atractiva. Además, no tenemos ninguna expectativa de tener que mudarnos o migrar lejos de GAE en el futuro y el bloqueo de la plataforma para este proyecto es aceptable. Incluí el comentario de "estrategia de salida" en mi pregunta principalmente en un esfuerzo por ser bastante completo en lo que he aprendido a través de la lectura y la investigación antes de publicar esta pregunta. ¡Gracias de nuevo!
Travis Bradshaw

¿Cómo califica el costo del tiempo de desarrollo? Una de las cosas buenas de Django es que pasa menos tiempo preocupándose por definir sus modelos de datos que con Bigtable. Bigtable te obliga a ser mucho más claro sobre tus usos antes de poder usarlo. Ciertas consultas son significativamente más fáciles con sql "normal".
Paul McMillan

3
Tenga cuidado de no pellizcar demasiado los centavos. Gratis es bueno, pero el servicio cuesta dinero real rápidamente. Si se encuentra en el nivel de servicio "gratuito", alójelo en algún otro servidor / alojamiento que ya esté pagando. Si ingresa al nivel de servicio no gratuito, los $ 20 / mes por un VPS que puede escalar fácilmente más adelante están en el ruido en cuanto al costo.
Paul McMillan

11
tbradshaw, no olvide considerar la frecuencia con la que necesitará ejecutar informes ad-hoc en su conjunto de datos. Estoy involucrado en una aplicación social en crecimiento y GAE se está convirtiendo ... no diré una pesadilla, pero es extremadamente intensivo en recursos derivar conocimiento de nuestros datos. Entre la depuración de registros antiguos de Google y las longitudes extremas necesarias para barrer todos los datos, hace que la forma de generar informes sea mucho más cara que una base de datos SQL. Ese es un costo que no consideré al comenzar. En segundo lugar, si realmente crece y comienza a ganar dinero, el control que pierde con respecto a las copias de seguridad es, bueno, un factor.
JasonSmith

2
Para problemas de bloqueo, consulte AppScale, que es un clon de Google App Engine. Hemos estado trabajando en la plataforma desde que apareció GAE y tenemos muchos usuarios en ella para sus aplicaciones de producción de Python y Java. Tiene acceso directo a las máquinas en las que se ejecuta, por lo que tiene más control sobre la infraestructura. github.com/AppScale/appscale.git
Navraj Chohan

16

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? )


+1, bigtable es simplemente malo para algunos tipos de proyectos y consultas. Es genial para lo que hace Google y puede ser terrible para lo que quieres hacer.
Paul McMillan

¡Gracias Paul! ¿Podría vincularme a algún recurso que describa el middleware y los complementos de Django que funcionan en GAE? Si hay complementos útiles para nuestro proyecto, sin duda sería una razón para ir con Django en lugar de la aplicación web. Los más obviamente útiles (como la sesión y la autenticación) parecen tener claras dependencias de Django ORM.
Travis Bradshaw

2
Básicamente, cualquier complemento que no tenga un models.py funcionará perfectamente. Y si tienen un models.py, probablemente puedas hacer la conversión 1 a 1 a bigtable y seguir utilizándolo si quieres. Algunos de los que uso son django_annoying, django_debug_toolbar, y de la sección contrib csrf, humanize y, por supuesto, admin.
Paul Tarjan

11

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


3

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.


1
¡Gracias por su rápida respuesta! Si bien estoy de acuerdo en que Django es un marco que se inicia rápidamente, eso no es realmente una preocupación para nosotros. Tenemos cuatro desarrolladores de Python bastante experimentados con experiencia en desarrollo web, por lo que comenzar con cualquier marco será rápido y sencillo. Pero la pregunta sigue siendo, al elegir entre Django y la aplicación web en GAE, ¿cuál es la mejor opción y por qué ?
Travis Bradshaw

@ Woot4Moo, si no tienes experiencia con GAE, ¿lo implementas? Soy nuevo en GAE pero el precio me confunde bastante, cargos aleatorios de hughe, estoy pensando en python en cualquier lugar, ¿podrías pasarme algunas recomendaciones?
Manza

0

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 ).


0

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


Gracias, aunque menciono exactamente eso en la pregunta original: "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 para apuntar al éxodo. "
Travis Bradshaw

0

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,

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.