2009-11-04 16 views
7

Leí un artículo de un desarrollador de juegos indie que usa Google App Engine para almacenar en caché su sitio principal y blog, para proteger la alta disponibilidad durante el tráfico picos (efecto Digg, Slashdot).Uso de Google App Engine como "caché" para sitios web personales (blogs wordpress, wikis)

Wolfire Blog - Google App Engine for Indie Developers

No hay una gran cantidad de detalles sobre el exactamente lo que se desarrollaron en Python en Google App Engine que se utilizan para almacenar en caché el sitio. Los únicos detalles que pude encontrar fueron acerca de la aplicación de App Engine pitón de leer los artículos backend de WordPress a través de una fuente RSS:

Wordpress se ejecuta en un servidor dedicado, y importarlo a www.wolfire.com a través de RSS, que es la parte de App Engine. Dumping Wordpress está completamente en mi lista , aunque de cosas que hacer algún día. ;)

¿Alguien sabe de cualquier Python de código abierto o marcos web Java que se puede utilizar para personalizar el almacenamiento en caché de un sitio que se podría construir y desplegar en Google App Engine para actuar como un proveedor "escalable" para tu web ¿contenido?

Estoy usando un servicio de alojamiento compartido "Ok" llamado bluehost para alojar mi blog de WordPress, me gustaría poder poner mi blog en un dominio aparte (blog.ddaniels.net) y alojar la aplicación de Google -engine en www.ddaniels.net que apuntaría a blog.ddaniels.net.

Esto podría ampliarse para casi cualquier tipo de sitio web, aún necesitaría enlaces a contenido dinámico para apuntar al host original (para cosas como comentarios y edición de páginas wiki, etc., básicamente cualquier operación de tipo HTTP PUT).

Me asumir que, básicamente, se necesitaría un marco de Java o Python que se podía:

  1. Configure su servidor back-end, por ejemplo, blog.yourname.com

  2. marco
  3. Configurar Google App Engine como www.yourname.com (detalles para Google App Engine mapping to your domain, la clave es que hay que usar subdominios y "www" es un subdominio)

  4. en el primer acceso de la página (o después de la fecha de caducidad) HTTP GET la página de copias de seguridad de host y almacenar en caché en Google App Engine

Respuesta

9

se podría empezar por tomar el código para DryDrop, que refleja las páginas estáticas desde un repositorio alojado en GitHub y convirtiéndolo en un proxy inverso más general. Por ejemplo, debe asegurarse de que las solicitudes POST o los usuarios que hayan iniciado sesión pasen directamente al proxy.