Este post se adentrará en el uso del Servicio de eventos Couchbase en el Couchbase Silicon Valley 2017 demostración técnica aplicación.
Si aún no está familiarizado con la demo o Servicio de eventos Couchbaseecha un vistazo a los recursos al final de este post. El código fuente de todo el conjunto de aplicaciones es disponible en GitHub.
Introducción
En la demostración, utilizamos un teléfono móvil con NFC para leer las temperaturas de un parche sin batería. Las lecturas se almacenan como un Recurso de observación FHIR en JSON utilizando Couchbase Lite. Estos documentos se sincronizan con un Servidor Couchbase clúster a través de Pasarela de sincronización.
El cliente web dispone de un panel de control diseñado para realizar un seguimiento de la información del paciente casi en tiempo real. Esto plantea un par de retos bastante comunes. ¿Cómo lo hacemos?
- Actualizar el cuadro de mandos basándose en los registros escritos por otra parte del sistema.
- Transferir eficazmente la información necesaria
Veamos cómo el Servicio de Eventos ayuda en ambos casos.
Envío de actualizaciones al cliente
Incluso sin un base de datos activa...puedes hacerlo de un par de maneras diferentes. Por ejemplo, podríamos encontrar la manera de enviar las lecturas a una cola de mensajes, o sondear la base de datos. Ambos enfoques tienen inconvenientes.
- Añadir una cola de mensajes introduce más complejidad en la infraestructura y más posibilidades de fallo.
- Las encuestas son, bueno, encuestas.
En su lugar, hemos utilizado Funciones Couchbaseuna función del Servicio de Eventos. Las funciones escuchan los cambios en la base de datos. (Técnicamente, las funciones procesan un Protocolo de cambio de base de datos Couchbase feed). A continuación, escriba dos callbacks en JavaScript, OnUpdate y OnDeleteque se invocan para cada evento de creación/actualización y eliminación de documentos, respectivamente. Esto le permite implementar código reactivo que se ejecuta directamente en su clúster.
(Como nota al margen, podríamos haber resuelto esto utilizando Ganchos web de Sync Gateway. Este enfoque tiene algunos aspectos en común con la técnica que utilizamos. Tiene varias desventajas, pero ese es un tema para otro post).
Eficacia de los datos
La aplicación móvil crea documentos basados en lecturas de temperatura que deben registrar una serie de datos relacionados.[1] Para el cuadro de mandos, sólo necesitamos un pequeño subconjunto de esos datos. Podríamos recuperar todo el documento con una búsqueda clave/valor. Eso sería rápido, pero significa transferir datos que no nos interesan. Es bastante fácil utilizar un N1QL para reducir los datos. Aunque N1QL es increíblemente eficiente, esto implica procesar los nodos de consulta.
Con Functions, se obtiene una copia del documento con cada actualización. Naturalmente, puedes extraer los datos que quieras de ahí con bastante facilidad. Dado que Eventing es un servicio independientepuede escalar los recursos que dedica a sus Funciones independientemente del resto de su clúster.
El Código
El código es bastante sencillo.
Funciones Couchbase
Aquí está la parte de Funciones. Puedes añadir esto a través del panel Eventing de la consola de Couchbase Server, o a través de una llamada REST.[2]
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
función OnUpdate(doc, meta) { si (doc.resourceType != Observación) devolver; deje referencia = doc.tema.referencia; deje url = "http://localhost:8080/events/" + referencia.substr(9); deje datos = JSON.stringify({ "referencia": doc.tema.referencia, "código": doc.código.codificación[0].código, "recordedAt": doc.publicado, "valor": doc.valorCantidad.valor }); deje rizo = SELECCIONE CURL($url, { "solicitud": "POST", "cabecera": [ "Content-Type: application/json", "accept: application/json" ], "datos": $datos }); rizo.execQuery(); } función OnDelete(meta) {} |
En la especificación FHIR, todos los documentos tienen un resourceType. Sólo miramos los recursos de "Observación", así que la primera comprobación filtra eso.
A continuación, extraemos el UUID del paciente del campo de referencia del sujeto. Esto se utiliza en el enrutamiento en el servidor de la aplicación web. (Para más información, véase la siguiente sección).
A continuación, creamos una cadena JSON con sólo la referencia del sujeto, un código que indica el tipo de observación realizada, la fecha en que se tomó esta en particular y el valor de la medición. Esos son los únicos datos que necesitamos pasar.
Por último, utilizamos el cURL en N1QL para enviar esos datos al punto final REST del servidor de aplicaciones. (En lugar de utilizar una consulta SELECT para ejecutar la función CURL, considere la posibilidad de utilizar la propia función CURL de eventing).
Servidor Web REST Endpoint
El servidor de aplicaciones está escrito en Nodo utilizando Express. Definimos un ruta en Express para crear el endpoint utilizado en la llamada cURL en el código de Funciones.
Aquí está el código.
|
1 2 3 4 5 6 7 8 9 |
enrutador.Correo electrónico:(/:id, función(consulte, res, siguiente) { res.enviar(''); si (sse[consulte.parámetros.id] === indefinido) devolver; // No escucho todavía sse[consulte.parámetros.id](`evento: actualización\ndata: { "valores": [${JSON.stringify(consulte.cuerpo)}]}\n\n`); }); módulo.exportaciones = enrutador; |
Express le permite definir una parte de una ruta, y luego colgarla de una ruta más larga cuando se conectan las cosas. Por lo tanto, todo lo que ves aquí es la parte final de la especificación de la ruta. La dirección :id indica a Express que tome el último segmento de la URL y lo introduzca como parámetro en nuestra llamada de retorno. Recordemos que aquí añadimos el UUID del paciente como la última parte de la ruta URL. Así que eso es lo que el elemento id se establece en.
Una vez activada esta ruta con nuestra llamada cURL, necesitamos enviar la información al cliente web. Podríamos haber utilizado sockets web. En su lugar, hemos optado por utilizar eventos enviados por el servidor. Los SSEs son más ligeros que los web sockets, y funcionan bien para este propósito. Profundizaremos en los SSEs en otro post. Por ahora, piensa en ellos como un canal de mensajes que utiliza un formato muy simple.
Eso nos da lo que necesitamos saber para entender el código de devolución de llamada. La primera línea especifica la ruta. La segunda línea envía una respuesta vacía, para cerrar la sesión cURL. A continuación comprobamos si el canal de eventos enviado por el servidor ya ha sido configurado. Esto ocurre a través de una llamada desde el cliente. Si el canal SSE está listo, etiquetamos nuestros datos como un evento de "actualización", y enviamos el mismo JSON que recibimos.
Conclusión
Las funciones son probablemente mi nueva característica favorita en Couchbase Server 5.5. Hemos visto un ejemplo aquí, y puedes ver que no se necesita mucho para empezar. También hay muchos otros casos de uso. Desplegar lógica de negocio junto con los datos, con escalado fácil, todo sin añadir infraestructura, es algo genial.
Recursos
Para más información sobre la aplicación, vea el vídeo de la keynote aquíjunto con estos otros puestos.
Puede leer una excelente introducción a Servicio de eventos Couchbase en esta entrada. También recomiendo encarecidamente echar un vistazo a este vídeo de Couchbase Connect NYC 2018: Haz más con el cambio - Presentamos Couchbase Eventing
Posdata
Couchbase es de código abierto y probar gratis.
Empezar con código de ejemplo, consultas de ejemplo, tutoriales y mucho más.
Más recursos en nuestra portal para desarrolladores.
Síguenos en Twitter @CouchbaseDev.
Puede enviar preguntas a nuestro foros.
Participamos activamente en Stack Overflow.
Envíame tus preguntas, comentarios, temas que te gustaría ver, etc. a Twitter. @HodGreeley
