tldr;
La parte de almacenamiento de CouchTalk es sencilla, sólo recursos jpeg y wav codificados por id. Lo que es interesante es el modelo de aplicación que asume claves secuenciales, permitiendo al front-end indexar los datos sin emitir ninguna consulta. Para detectar la última clave simplemente observamos los eventos del navegador en la etiqueta img y nos detenemos en 404.
¿Hablar de qué?
Todo el mundo sabe que la mensajería push-to-talk está de moda, y las funciones de audio/vídeo de HTML5 la ponen a nuestro alcance desde JavaScript. Como desarrollador web, siempre me interesa ir más allá de lo que es práctico con los navegadores actuales. Si aún no has jugado con CouchTalk, hazlo ahora (requiere Google Chrome).
Consideraciones sobre el diseño
El principal aspecto de Couchbase Server que quería destacar con la aplicación CouchTalk es la velocidad. Push-to-talk es especialmente sensible al rendimiento - añade unas décimas de segundo de latencia y una aplicación puede pasar de divertida a lenta. La arquitectura de memoria gestionada de Couchbase Server significa que el rendimiento que ves hoy está limitado principalmente por la latencia de Internet de extremo a extremo, con tiempos de respuesta en el servidor de aplicaciones basados principalmente en el tamaño de los datos. Las miniaturas pequeñas se sirven en unos pocos milisegundos, mientras que las imágenes grandes pueden tardar más, ya que están limitadas por las velocidades de conexión.
Aplicación (arquitectura y modelo de datos)
El servidor de aplicaciones es extremadamente simple, sólo un servidor HTTP para leer y escribir imágenes y clips de audio, y un punto final web para entregar nuevos identificadores de mensajes a los clientes.
Las peticiones del servidor HTTP se pueden equilibrar entre los servidores node.js de cualquier manera, por lo que escalar ese aspecto de la aplicación es cuestión de seguir las prácticas de dimensionamiento de Couchbase Server, y añadir más servidores node.js cuando sea necesario.
PubNub se utiliza para notificar nuevos cambios a los miembros de la sala. Los mensajes PubNub no contienen imágenes reales ni clips de audio. En su lugar, los mensajes envían identificadores de documentos, que el cliente puede utilizar para solicitar los medios.
El modelo de datos se rige por un patrón de claves INCR, de modo que para cada mensaje en la sala, el cliente declara su intención de guardar un mensaje, y el servidor le da una clave para guardarlo. Las claves tienen el siguiente formato sala-secuencia donde la secuencia es un número entero creciente. Los clientes ya saben en qué sala están, así que una vez que conocen una secuencia actual, pueden rellenar los mensajes recientes generando sus claves.
Cuando un cliente pregunta por el ID del siguiente mensaje, simplemente incrementa la clave y envía el resultado de vuelta al cliente. Las operaciones de incremento son atómicas, por lo que puedes utilizarlas para construir un espacio de claves sin colisiones.
cb(err, ["snap",room,result.value].join('-'))
})
Este patrón clave es una gran manera de gestionar datos relacionados en Couchbase Server. Otro ejemplo sería: si conoces el número de comentarios en una entrada de blog puedes cargar todos los comentarios. O en el caso de CouchTalk: no hay necesidad de hacer un seguimiento de cuántas instantáneas forman parte de un clip, siempre y cuando sepas cuánto dura el clip y con qué frecuencia se toman nuevas instantáneas.
Cuando las imágenes o el audio se guardan en el servidor, utilizamos el comando "add" en lugar de "set" para asegurarnos de que las imágenes y el audio son inmutables, una vez que se han establecido no se modificarán.
Ten en cuenta que estamos guardando directamente un buffer binario en la base de datos. ¡Gracias Couchbase!
