CouchApp sin Servidor o backend CouchDB con problemas de xdomain?

Question

He estado jugando con CouchDB y CouchApp por un tiempo. Estoy planeando usarlo para un nuevo proyecto de sitio web en el que estoy trabajando.

1. Desde un punto de vista de escalabilidad, me encanta la idea de CouchApp.

   El inconveniente es que sin un código del lado del servidor hay algunas cosas (como autenticación de OAuth) que son difíciles de hacer en el lado del cliente. En algún momento, estoy seguro de que necesitaré algún código del lado del servidor de alguna descripción, supongo que puedes mirar Node.js pero preferiría no hacerlo en este punto.

2. El uso de CouchDB puramente como una solución de backend mientras sus páginas se sirven desde otro servidor también encaja perfectamente, pero la desventaja aquí es que los problemas de dominio cruzado le impiden usar fácilmente la API CouchDB incorporada.

¿Alguien tiene una solución para uno de estos dos inconvenientes?

¿Puede de alguna manera servir el código del lado del servidor (incluso PHP sería un triunfo) de CouchApp o puede de alguna manera utilizar un sitio separado para servir a sus páginas, pero superar el problema de dominio cruzado?

Estoy tratando de mantener la solución lo más limpia posible (y lo más escalable posible) y una de las mejores cosas de CouchDB es la API superrápida y súper rápida, así que no quiero usar una envoltura alrededor de ella - a menos que no obstaculice el rendimiento/escalabilidad.

Sus opiniones son bienvenidas.

Answer 1

Dado que CouchDB utiliza una API basada en HTTP, existen varias maneras de "mezclar y combinar" el código del lado del servidor (node.js, PHP, etc.) con su CouchApp.

rompo las opciones en tres categorías:

1. En primer lugar, una arquitectura de nivel 2 es lo que tenemos ahora: Navegador + CouchApp sirven de CouchDB. Es una gran solución para aplicaciones que solo necesitan lo que el navegador y CouchDB pueden ofrecer, pero necesitarás otro nivel tan pronto como llegues a la necesidad de enviar correos electrónicos, cambiar el tamaño de las imágenes u obtener datos de otra base de datos que no lo haga tener una API HTTP (MySQL, MongoDB, etc.).
2. A continuación, está la Arquitectura de 3 niveles: Navegador + Apache/PHP (o pila similar) + CouchDB. Esta es la opción más "tradicional" (es decir, LAMP). Esto está bien para migrar gradualmente a CouchDB, pero a largo plazo, puede ser engorroso tener que enrutar todo a través de un segundo servidor HTTP (como un proxy, quizás) o un lenguaje de scripting del lado del servidor como PHP.
3. La última, y ​​mi favorita, es la Arquitectura de Nivel 2.5: Navegador + CouchDB + externalidades o _cambios basados ​​en "acciones". En este caso, PHP (o similar) actúa como un tipo de proveedor de servicios para CouchDB. Las acciones pueden activarse haciendo que PHP mire el feed _changes para ciertos tipos de documentos y sus cambios (es decir, carga de imágenes, documento de mensaje de correo electrónico), o CouchDB puede configurarse para "hacer ping" a un manejador externo para hacer más procesamiento en el documento o sus archivos adjuntos. Esto es esencialmente cómo funciona couchdb-lucene mirando las actualizaciones y actuando sobre ellas a medida que ocurren o en intervalos regulares.

Usted puede encontrar más información acerca de los _changes alimentación y manipuladores _external siguientes:

• _changes alimentan: http://guide.couchdb.org/draft/notifications.html
• manipuladores _external: http://wiki.apache.org/couchdb/ExternalProcesses

Por lo que su valor, I' Estaré discutiendo estas tres opciones el próximo miércoles en un PHP and CouchDB Webcast. Sus preguntas serían una valiosa adición a la discusión al final de la transmisión por Internet.

Me encantaría saber cómo resulta su CouchApp, y cómo resuelve los problemas que mencionó anteriormente.

Answer 2

excelente respuesta de BigBlueHat, pero tengo uno más más opción posible añadir:

superar el problema de dominios cruzados, lo que le permite servir páginas de cualquier tipo de servidor web, y también permite que el navegador interactuar directamente con CouchDB (que puede estar en otro servidor).

La restricción entre dominios, tal como la aplican los navegadores, no es tan difícil de sortear. Los dos métodos principales que conozco son: JSONP y CORS.

JSONP disimula cada solicitud como solicitud de "secuencia de comandos" (ya que las solicitudes de secuencia de comandos están exentas de la regla de dominio cruzado). Solo funciona para GET, no POST o PUT o cualquier otra cosa. Puedes hacerlo con jQuery.

CORS es "Cross Origin Resource Sharing", y es simplemente un encabezado HTTP especial que debe implementarse en el servidor (couchdb en este caso), que le dice al navegador que está bien, no le importa servir solicitudes que provienen de otro dominio. Lo he probado y funciona, pero puede haber problemas de seguridad, no estoy seguro.

Entonces ... No sé si es una buena idea, pero técnicamente es posible (al menos parcialmente) superar la restricción entre dominios con CouchDB. ¿Alguien ha construido un sistema usando este tipo de configuración?