python - gae - google app engine que es
¿Por qué usar Django en Google App Engine? (8)
Al investigar Google App Engine (GAE), está claro que usar Django es tremendamente 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 webapp provisto por Google.
Para ser claro, es inmediatamente evidente por qué usar Django en GAE es útil para desarrolladores con un conjunto de habilidades existente en Django (la mayoría de desarrolladores web de Python, sin duda) o código existente en Django (donde usar GAE es más un ejercicio de portabilidad). 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 librerías BigTable han reemplazado el ORM de Django, las sesiones y la autenticación se cambian necesariamente, y la plantilla de Django (si es deseable) está disponible sin usar toda la pila Django.
Finalmente, está claro que usar Django tiene la ventaja de proporcionar una "estrategia de salida" si más adelante queremos alejarnos de GAE y necesitamos una plataforma para apuntar al éxodo.
Estaría muy agradecido por la ayuda para señalar por qué usar Django es mejor que usar Webapp en GAE. También soy completamente inexperto con Django, por lo que la elaboración de características más pequeñas y / o comodidades que funcionan en GAE también son valiosas para mí.
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 las funcionalidades pueden ser totalmente compatibles con las aplicaciones que se ejecutan en App Engine . El soporte para usar Google Cloud SQL con Django es proporcionado por un backend de base de datos Django personalizado que envuelve el back-end MySQL de Django.
https://cloud.google.com/python/django/appengine
una nueva noticia es que hay soporte BETA para PostgreSQL
Django probablemente no sea la opción correcta para ti, si estás seguro de que GAE es adecuado para ti. Las fortalezas de las dos tecnologías no se alinean muy bien: pierdes completamente una gran parte del maravilloso orbe de Django en GAE, y si lo usas, escribes código que no es directamente adecuado para bigtable y la forma en que funciona GAE.
Lo que pasa con GAE es que obtiene la gran escalabilidad al forzarte a escribir código que se escala fácilmente desde cero. Simplemente no puedes hacer una serie de cosas que escalan mal (por supuesto, aún puedes escribir código de escalado pobre, pero evitas algunas trampas). La compensación es que realmente terminas codificando alrededor del framework, si usas algo como Django que está diseñado para un entorno diferente.
Si se ve a sí mismo saliendo de GAE por algún motivo, invirtiéndose en la infraestructura, hay un problema para usted. Codificar para bigtable significa que será más difícil moverse a una arquitectura diferente (aunque el proyecto de apache está trabajando para resolver esto para usted con el componente HBase del proyecto Hadoop). Todavía 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 genial? ¿Hay algún motivo por el que escalar usando algo como la oferta del mediatemple no funcione bien para usted? ¿Estás seguro de que las formas en que las escalas de GAE son adecuadas para tu aplicación? ¿Cómo se compara el costo con los servidores dedicados, si está esperando 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 balanceada de carga más tradicional?
Dicho todo esto, a menos que realmente necesites la escala límite ridícula que GAE ofrece, te sugiero que no permitas que ese servicio en particular estructure tu elección de marco. Me gusta Django, así que diría que deberías usarlo, pero no en GAE.
Editar (junio de 2010): como una actualización de este comentario un poco más tarde: Google ha anunciado capacidades similares a sql para GAE que no son gratuitas, pero 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 de GAE que permitirán consultas complejas de una manera mucho más sencilla. Mira los videos de Google I / O 2010.
Además, se está trabajando en el proyecto Summer of Code 2010, que debería brindar soporte sin sql a django core y, por extensión, facilitar significativamente el trabajo con GAE.
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 lockin ha mejorado (si su aplicación es lo suficientemente grande puede implementar las alternativas de Apache), pero para la mayoría de las aplicaciones, los servidores en ejecución o las implementaciones de VPS son más baratos.
Muy pocas personas realmente tienen problemas bigdata. "Oh, mi startup podría escalar algún día" no es un gran problema de datos. Construya cosas ahora y sáquelas usando las herramientas estándar.
He hecho muchos proyectos en GAE. Algunos en django, algunos en su marco normal.
Para cosas pequeñas, generalmente uso su marco normal para simplificar y acelerar. Como http://stdicon.com , http://yaml-online-parser.appspot.com/ , o http://text-twist.appspot.com/ .
Para cosas grandes, voy con django para aprovechar todo el buen middleware y plugins. Me gusta http://metaward.com .
Básicamente mi prueba de fuego es: ¿Me tomará más de 2 semanas escribir y ser un proyecto REAL de software? Si es así, ve con django para los complementos.
Tiene la ventaja añadida de que, si su proyecto no es adecuado para BigTable, se desconectará rápidamente (como lo hice con BigTable lento o ¿soy tonto? )
No puedo responder la pregunta, pero es posible que desee buscar en web2py. Es similar a Django en muchos aspectos, pero su capa de abstracción de base de datos funciona en GAE y es compatible con la mayoría de las funcionalidades de GAE (no todas, pero tratamos de ponernos al día). De esta forma, si GAE funciona para usted de maravilla, 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 mucha suerte con la aplicación web GAE
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 tener un buen control de las cosas, pero al final del día lo usaría de nuevo en un proyecto. Esto fue hace casi 2 años antes de alcanzar 1.0, así que mi conocimiento está un poco desactualizado.
Si te preocupa cambiar de plataforma, supongo que sería una mejor opción.
Todavía soy muy nuevo en el desarrollo de motores de la aplicación de Google, pero las interfaces que proporciona Django parecen mucho mejores que las predeterminadas. Los beneficios dependerán de lo que esté usando 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 energía de Django, pero se ejecuta en el motor de la aplicación para una posible escalabilidad adicional. En particular, incluye los 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 la tabla grande. Lo más probable es que haya compensaciones en cuanto a funcionalidad y eficiencia, así como un mayor número de errores y caprichos. Por supuesto, esto podría valer la pena en circunstancias como las que se describen en la pregunta, pero por lo demás recomendaría encarecidamente usar el helper al inicio, ya que entonces tienes la opción de avanzar hacia el motor de aplicaciones puro o Django non-rel más adelante. Además, si cambia a Django non-rel, su mayor conocimiento de cómo funciona el motor de la aplicación será útil si la abstracción de Django se rompe alguna vez, sin duda mucho más útil que el conocimiento de las peculiaridades / soluciones para Django non-rel si cambia el Otra manera.
Usamos django en nuestras instancias de appengine principalmente cuando tenemos que servir sitios web reales al usuario. Tiene un gran motor de plantillas, enrutamiento url y todo el manejo de solicitud / respuesta / error incorporado. Por lo tanto, aunque no podemos usar las cosas mágicas de orm / admin, tiene mucho que ofrecer.
Para los servicios de API, construimos algo muy simple encima de webob . Es mucho más liviano porque no necesita todo lo que django ofrece y, por lo tanto, es un poco más rápido en algunas situaciones.