¿Por qué utilizar Django en Google App Engine?

Cuando se investiga en Google App Engine (GAE), es claro que el uso de Django es muy popular para el desarrollo en Python en GAE. He estado rastreando por la web para encontrar información sobre los costos y beneficios del uso de Django, para averiguar por qué es tan popular. Aunque he sido capaz de encontrar una amplia variedad de fuentes en cómo para ejecutar Django en GAE y de los diversos métodos de hacerlo, no he encontrado ningún análisis comparativo en por qué Django es preferible el uso de la webapp marco proporcionado por Google.

Para ser claro, es inmediatamente evidente por qué el uso de Django en GAE es útil para los desarrolladores con un conjunto de habilidades en Django (la mayoría de Python web de los desarrolladores, sin duda) o código existente en Django (donde el uso de GAE es más de una portabilidad de ejercicio). Mi equipo, sin embargo, es la evaluación de GAE para su uso en un nuevo proyecto y nuestra experiencia es con TurboGears, no Django.

Ha sido bastante difícil determinar por qué Django es beneficioso para un equipo de desarrollo cuando el BigTable bibliotecas han sustituido a Django del ORM, sesiones y la autenticación son necesariamente cambiado, y Django de plantillas (si se desea) está disponible sin necesidad de utilizar la totalidad de Django pila.

Finalmente, es claro que el uso de Django tiene la ventaja de proporcionar una «estrategia de salida» si más tarde se quería alejarse de GAE y la necesidad de una plataforma para el objetivo para el éxodo.

Yo estaría muy agradecido por la ayuda en señalar por qué utilizando Django es mejor que el uso de webapp en GAE. Yo también estoy totalmente de experiencia con Django, por lo que la elaboración en funciones más pequeñas y/o de las conveniencias que el trabajo en GAE, también son valiosas para mí.

  • mierda santa, terry bradshaw, escribe el código?
  • Django es beneficioso porque es impresionante. Que realmente es. 🙂
  • Soy nuevo en Google app engine también y este es un muy bien formado pregunta, incluso para el 2018(aunque ORM de Django parece que es mucho mejor apoyado en GAE ahora). 🙂

8 Kommentare

  1. 19

    Utilizamos django en nuestro appengine instancias sobre todo cuando tenemos que servir a sitios web reales para el usuario. Cuenta con una gran plantilla de motor de enrutamiento de dirección url y todas las de solicitud/respuesta/error de manejo integrado. Así que incluso aunque no podemos usar la magia orm/admin cosas tiene mucho a su favor.

    Para la api de servicios hemos construido algo muy simple en la parte superior de webob. Es mucho más ligero porque no necesitan todo lo que django ofrece, y por lo tanto un poco más rápido en algunas situaciones.

    • Gracias Koen. Parte de mi confusión en cuanto a la apelación de Django surgió de la idea de que la url de enrutamiento y de solicitud/respuesta/error de manejo fueron también características de la webapp y que el motor de plantillas que pueden ser utilizados sin Django así como con la webapp. ¿Estoy equivocada? Hace Django proporcionar estos servicios mejor que la webapp marco?
    • Es más amplia y flexible en django diría yo. Así que es mejor si usted realmente necesidad de que 🙂
    • Creo que esta es la respuesta que estoy buscando! Que Django es en gran medida redundante webapp, pero en la funcionalidad que comparten Django hace de una manera más flexible y robusta. Parece que es sin duda una decisión «en el margen», pero creo que todos los de las otras sugerencias, además de la suya, hace que para una respuesta clara. Gracias.
    • Los módulos de Python escrito en C no son compatibles también.
  2. 51

    Django, probablemente, no es la opción correcta para usted, si usted está seguro de que GAE es el adecuado para usted. Los puntos fuertes de las dos tecnologías no se alinean muy bien que perder un montón de Django maravilloso orm en GAE, y si usted lo utiliza, escribe el código que no es realmente conveniente directamente a bigtable y la forma en que GAE obras.

    La cosa sobre GAE es que se obtiene el gran escalabilidad, obligando a escribir el código que se adapta fácilmente desde el suelo. Usted simplemente no puede hacer un número de cosas que la escala de mal (por supuesto, usted puede escribir mal escalado de código, pero que evitar algunas de las dificultades). La desventaja es que usted realmente terminar la codificación de todo el marco, si usas algo como Django, que está diseñado para un entorno diferente.

    Si te ves a ti mismo salir de GAE por cualquier motivo, convirtiéndose invertido en la infraestructura no es un problema para usted. Codificación de bigtable significa que será más difícil para pasar a una arquitectura diferente (a pesar de que el proyecto apache está trabajando para resolver esto para usted con la HBase componente de la Hadoop proyecto). No por ello deja de ser un montón de trabajo para la transición de GAE.

    Lo que es la conducción motivador detrás de usar GAE, además de ser un producto de Google, y un fresco de la palabra de moda? Hay una razón por la que, para ampliar el uso de algo como mediatemple la oferta es poco probable que funcione bien para usted? Estás seguro de que la manera en que GAE escalas adecuadas para su aplicación? ¿Cómo se compara el costo de los servidores dedicados, si usted está esperando para llegar a ese rendimiento reino? Se puede resolver el problema utilizando las herramientas GAE ofrece, frente a la más tradicional de equilibrio de carga del servidor de instalación?

    Dicho todo esto, a menos que sea absolutamente positivamente la necesidad de la frontera-ridículo escala que GAE ofrece, yo personalmente sugiero no dejar que ese servicio en particular de la estructura de su elección de marco. Me gusta Django, así que yo diría que se debe utilizar, pero no en GAE.

    Edición (Junio De 2010):
    Como una actualización a este comentario en algún momento más adelante:
    Google ha anunciado sql-como capabilitys para GAE que no son libres, sino que le permiten fácilmente hacer cosas como correr estilo de SQL comandos para generar informes sobre los datos.

    Además, hay cambios que se avecinan para la GAE lenguaje de consulta que permitirá consultas complejas en una forma mucho más fácil de moda. Mira los videos de Google I/O 2010.

    Además, no hay trabajo que se realiza durante el Verano de 2010 Código proyecto que debe llevar no-sql apoyo a django núcleo, y por extensión, asegúrese de trabajar con GAE mucho más fácil.

    GAE es cada vez más atractiva como una plataforma de hosting.

    Edición (Agosto De 2011):

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

    Muy pocas personas que realmente han bigdata problemas. «Oh mi startup podría escala algún día» no es un bigdata problema. Construir cosas ahora y conseguir que fuera de la puerta utilizando las herramientas estándar.

    • Gracias por la respuesta reflexiva, Pablo. Estamos evaluando GAE en gran parte porque el modelo de costo coincide con nuestra propuesta de plan de negocios bien. La capacidad para iniciar el libre y, a continuación, la escala de forma incremental con un muy detallado modelo de costo es muy atractivo. Además, nosotros no tenemos la expectativa de que la necesidad de mover o emigrar lejos de GAE en el futuro y de la plataforma de lock-in para este proyecto es aceptable. He incluido la «estrategia de salida» comentario en mi pregunta, principalmente, en un esfuerzo por ser bastante completa en lo que he aprendido a través de la lectura y la investigación antes de publicar esta pregunta. Gracias de nuevo!
    • ¿Cómo valora usted el costo de tiempo de desarrollo? Una de las cosas buenas acerca de Django es que usted pasa menos tiempo preocupándose acerca de la definición de sus modelos de datos que lo haría con la Bigtable. Bigtable te obliga a ser mucho más clara acerca de sus usos antes de ser capaz de utilizarlo en absoluto. Ciertas consultas son mucho más fáciles con «normal» de sql.
    • Tenga cuidado de no pellizcar peniques excesivamente. Libre es agradable, pero el servicio rápidamente cuesta dinero real. Si eres de cabotaje en el «libre» nivel de servicio, alojarlo en otro servidor/hosting ya estás pagando. Si usted está recibiendo en los non-free de nivel de servicio, los $20/mo para un VPS que puede escalar fácilmente más tarde es en el ruido y en cuanto a coste.
    • Gracias de nuevo por el seguimiento. Estamos considerando el tiempo de desarrollo adicional asociado con la realización de un BigTable estilo de la modelo, en lugar de una más tradicional ORM basado en modelo relacional. Todos estamos enorme defensores y usuarios de SQLAlchemy y la transición a una columna de base de datos es una parte importante de nuestra evaluación. También hemos considerado el costo/beneficio de la GAE frente a otras opciones de alojamiento, pero está satisfecho con el rendimiento y el modelo de costo para el VPS en otros de nuestros proyectos y quiere alejarse de eso. Todavía grandes comentarios y nuestro equipo va a leer y a hablar de ellos!
    • tbradshaw, no se olvide de considerar con qué frecuencia necesitará reportes ad-hoc de ejecutar el conjunto de datos. Estoy involucrado en una creciente aplicación social y GAE es cada vez… no voy a decir una pesadilla, pero es extremadamente intensivo de los recursos para obtener conocimiento a partir de nuestros datos. Entre Google purgar los registros antiguos y los extremos necesarios para barrer a través de todos los datos, se hace de informes de forma, de manera más caro que una bd de SQL. Que es un costo que no consideraba al empezar a trabajar. En segundo lugar, si usted realmente hacer crecer y empezar a ganar dinero, el control que perder relativas a las copias de seguridad es, así, un factor.
    • Bloqueo en las preocupaciones retirar AppScale, que es un Google App Engine clon. Hemos estado trabajando en la plataforma, ya que GAE salió por primera vez y tienen muchos usuarios por su producción de python y java. Usted tiene acceso directo a las máquinas que se ejecuta en este modo tendrás más control sobre la infraestructura. github.com/AppScale/appscale.git

  3. 16

    He hecho un montón de proyectos en GAE. Algunos en django, algunos en su normal framework.

    De las pequeñas cosas, yo normalmente uso normal de marco para la simplicidad y rapidez. Como http://stdicon.com, http://yaml-online-parser.appspot.com/, o http://text-twist.appspot.com/.

    Para grandes cosas, voy con django para tomar ventaja de todos los bonitos middleware y plugins. Como http://metaward.com.

    Básicamente mi prueba de fuego es me Va a tomar más de 2 semanas para escribir y ser un REAL proyecto de software? Si es así, vaya con django para los complementos.

    Tiene el beneficio añadido de que, si el proyecto no está preparada para BigTable, a continuación, rápidamente puerto (como yo lo hice Es BigTable lento o soy tonto?)

    • +1, bigtable es malo para algunos tipos de proyectos y consultas. Es genial para lo que hace Google, y puede ser terrible para lo que quieres hacer.
    • Gracias Pablo! Podría usted un enlace a cualquiera de los recursos que describen el Django de middleware y plugins que trabajan en GAE? Si hay complementos útiles para nuestro proyecto, que sin duda sería un motivo para ir con Django en lugar de webapp. El más obviamente útil (como los de sesión y autenticación) parecen tener claro el ORM de Django dependencias.
    • Básicamente, cualquier complemento que no tiene un models.py funciona a la perfección. Y si tienen un models.py usted probablemente puede hacer el 1-a-1 la conversión a bigtable y todavía lo use si usted desea. Algunos de los que uso son django_annoying, django_debug_toolbar, y de la sección contrib csrf, humanizar, y por supuesto admin.
  4. 11

    Creo que todo esto de las respuestas son un poco obsoletos.

    Ahora usted puede utilizar Google Cloud SQL

    Django es un popular tercero web de Python marco. Cuando junto
    con Google Cloud SQL, todos los de su funcionalidad puede ser totalmente compatibles
    por las aplicaciones que se ejecutan en App Engine
    . Soporte para el uso de la Nube de Google
    SQL con Django es proporcionada por una costumbre Django backend de base de datos que
    envuelve Django del motor MySQL.

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

    uno más noticias frescas es, que no es BETA soporte para PostgreSQL

  5. 3

    Tengo experiencia con Django y no GAE. A partir de mis experiencias con Django fue una muy simplista de la instalación y el proceso de implementación fue increíblemente fácil en términos de proyectos web. Por supuesto que tenía que aprender Python para conseguir realmente una buena posición en las cosas, pero al final del día lo iba a usar de nuevo en un proyecto. Esto fue hace casi 2 años antes de llegar a 1.0 así que mi conocimiento es un poco anticuado.

    Si usted está preocupado acerca de un cambio de plataformas, entonces esto sería una mejor opción, supongo.

    • Gracias por tu rápida respuesta! Mientras que estoy de acuerdo en que Django es un framework que speedy para empezar, eso no es realmente una preocupación para nosotros. Tenemos cuatro muy experimentados desarrolladores de Python con el desarrollo web orígenes, de modo de introducción con cualquier marco va a ser rápido e indoloro. Pero la pregunta sigue siendo, al elegir entre Django y webapp en GAE, que es la mejor opción, y porque?
    • si no hay experiencia con GAE fueron ¿instalarla, soy nuevo en GAE, pero el precio me confunde bastante, al azar hughe cargos, estoy pensando en pythonanywhere, me podrias pasar algunas recomendaciones?
  6. 0

    No puedo responder a la pregunta, pero es posible que desee ver en web2py. Es similar a la de Django, en muchos aspectos, pero su base de datos la capa de abstracción de las obras en GAE y soporta la mayoría de los GAE funcionalidad (no todos, pero nos lo intenten). De esta manera, si GAE trabaja para usted genial, si no, se puede mover el código a una base de datos diferentes (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres, y – pronto – Sybase y MongoDB).

  7. 0

    Si decide ejecutar la aplicación fuera de GAE, usted todavía puede usar Django. Usted realmente no tiene mucha suerte con el GAE webapp

    • Gracias, aunque he de mencionar exactamente que en la pregunta original: «Finalmente, es claro que el uso de Django tiene la ventaja de proporcionar una «estrategia de salida» si más tarde se quería alejarse de GAE y la necesidad de una plataforma para el objetivo para el éxodo.»
  8. 0

    Todavía soy muy nuevo en Google App engine de desarrollo, pero las interfaces de Django proporciona aparecen mucho más agradable que el valor predeterminado. Los beneficios dependerán de lo que usted está usando Django en el app engine. El Google App Engine Ayudante de Django permite utilizar toda la potencia de Google App Engine con algunos Django funcionalidad en el lado.

    Django no rel intenta proporcionar la mayor cantidad de Django como sea posible, pero que se ejecuta en la aplicación de motor para posibles extra escalabilidad. En particular, incluye los modelos de Django (uno de Django núcleo de características), pero esto es una fuga de abstracción, debido a las diferencias entre las bases de datos relacionales y bigtable. Lo más probable es que sean las ventajas y desventajas en la funcionalidad y eficiencia, así como un aumento en el número de errores y desviaciones. Por supuesto, esto podría ser la pena que en circunstancias como las descritas en la pregunta, pero de lo contrario le recomendamos el uso de la ayuda en el inicio, entonces usted tiene la opción de avanzar hacia un puro app-motor o Django no rel más tarde. También, si usted cambie a Django no-rel, su mayor conocimiento de cómo la aplicación funciona el motor será útil si el Django de abstracción cada vez rompe – sin duda mucho más útil que el conocimiento de las peculiaridades/soluciones para Django no rel si intercambio de la otra manera.

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Pruebas en línea