Esta postagem se aprofundará no uso do Serviço de eventos do Couchbase no Couchbase Silicon Valley 2017 demonstração de palestra técnica aplicação.
Se você ainda não estiver familiarizado com a demonstração ou com o Serviço de eventos do CouchbaseDê uma olhada nos recursos no final desta postagem. O código-fonte de todo o conjunto de aplicativos é disponível no GitHub.
Introdução
Na demonstração, usamos um telefone celular com NFC para ler as temperaturas de um adesivo sem bateria. As leituras são armazenadas como um Recurso de observação FHIR em JSON usando Couchbase Lite. Esses documentos são então sincronizados em um Servidor Couchbase cluster via Gateway de sincronização.
O cliente Web tem um painel projetado para rastrear as informações do paciente quase em tempo real. Isso apresenta alguns desafios bastante comuns. Como podemos:
- Atualizar o painel com base nos registros gravados por outra parte do sistema
- Transferir com eficiência as informações necessárias
Vamos dar uma olhada em como o Eventing Service ajuda em ambos os casos.
Enviando atualizações para o cliente
Mesmo sem um banco de dados ativoSe você quiser fazer isso, pode fazê-lo de pelo menos duas maneiras diferentes. Por exemplo, poderíamos encontrar uma maneira de publicar as leituras em uma fila de mensagens ou pesquisar o banco de dados. Ambas as abordagens têm desvantagens.
- A adição de uma fila de mensagens introduz mais complexidade de infraestrutura e oportunidades de falha.
- Pesquisa de opinião é, bem, pesquisa de opinião.
Em vez disso, lidamos com isso usando Funções do CouchbaseO Eventing Service é um recurso do Eventing Service. As funções ouvem as alterações no banco de dados. (Tecnicamente, as funções processam um Protocolo de alteração do banco de dados do Couchbase feed). Em seguida, você escreve dois retornos de chamada em JavaScript, Sobre a atualização e OnDeleteque são invocados para cada evento de criação/atualização e exclusão de documento, respectivamente. Isso permite que você implemente código reativo que é executado diretamente em seu cluster.
(Em uma observação lateral, poderíamos ter resolvido isso usando Ganchos da Web do Sync Gateway. Essa abordagem tem alguns aspectos em comum com a técnica que usamos. Ela tem várias desvantagens, mas esse é um tópico para outra publicação).
Eficiência de dados
O aplicativo móvel cria documentos com base em leituras de temperatura que precisam registrar uma série de informações relacionadas.[1] Para o painel, precisamos apenas de um pequeno subconjunto desses dados. Poderíamos recuperar o documento inteiro com uma pesquisa de chave/valor. Isso seria rápido, mas significaria a transferência de dados que não nos interessam. É muito fácil usar um N1QL para reduzir os dados. Embora o N1QL seja incrivelmente eficiente, isso ainda significa processar os nós da consulta.
Com o Functions, você obtém uma cópia do documento a cada atualização. Naturalmente, você pode extrair os dados desejados de lá com bastante facilidade. Como Eventing é um serviço independenteCom o Functions, você pode dimensionar os recursos dedicados às suas funções separadamente do restante do cluster.
O Código
O código real envolvido aqui é bastante simples.
Funções do Couchbase
Aqui está a parte das funções. Você pode adicionar isso por meio do painel Eventing do console do Couchbase Server ou por meio de uma chamada REST.[2]
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
função Sobre a atualização(doc, meta) { se (doc.tipo de recurso != "Observação) retorno; deixar referência = doc.assunto.referência; deixar url = "http://localhost:8080/events/" + referência.substrato(9); deixar dados = JSON.stringify({ "referência": doc.assunto.referência, "código": doc.código.codificação[0].código, "recordedAt": doc.emitido, "valor": doc.valueQuantity.valor }); deixar enrolar = SELECIONAR CURL($url, { "request" (solicitação): "POST", "cabeçalho": [ "Content-Type: application/json", "accept: application/json" ], "dados": $dados }); enrolar.execQuery(); } função OnDelete(meta) {} |
Na especificação FHIR, todos os documentos têm um tipo de recurso. Analisamos apenas os recursos de "Observação", portanto, a primeira verificação filtra isso.
Em seguida, extraímos o UUID do paciente do campo de referência do assunto. Isso é usado no roteamento no lado do servidor do aplicativo Web. (Consulte a próxima seção para saber mais sobre isso).
Em seguida, criamos uma cadeia de caracteres JSON com apenas a referência do sujeito, um código indicando o tipo de observação feita, a data em que essa observação específica foi feita e o valor da medição. Esses são os únicos dados que precisamos passar.
Por fim, usamos o cURL no N1QL para fazer o POST desses dados no endpoint REST do servidor do aplicativo. (Em vez de usar uma consulta SELECT para executar a função CURL, considere usar a própria função CURL do eventing).
Ponto de extremidade REST do servidor da Web
O servidor de aplicativos é escrito em Nó usando Expresso. Definimos a rota no Express para criar o endpoint usado na chamada cURL no código do Functions.
Aqui está o código.
|
1 2 3 4 5 6 7 8 9 |
roteador.postagem('/:id', função(req, res, próxima) { res.enviar(''); se (sse[req.parâmetros.id] === indefinido) retorno; // Ainda não estou ouvindo sse[req.parâmetros.id](`evento: atualização\ndata: { "valores": [${JSON.stringify(req.corpo)}]}\n\n`); }); módulo.exportações = roteador; |
O Express permite que você defina uma parte de uma rota e, em seguida, pendure-a em um caminho mais longo ao conectar as coisas. Portanto, tudo o que você vê aqui é a parte final da especificação da rota. A parte :id diz ao Express para pegar o último segmento do URL e enviá-lo ao nosso retorno de chamada como um parâmetro. Lembre-se de que adicionamos o UUID do paciente como a última parte do caminho do URL. Portanto, é isso que o id é definido como.
Depois de acionar essa rota com nossa chamada cURL, precisamos enviar as informações para o cliente Web. Poderíamos ter usado soquetes da Web. Em vez disso, optamos por usar eventos enviados pelo servidor. Os SSEs são mais leves do que os soquetes da Web e funcionam bem para essa finalidade. Falaremos mais sobre os SSEs em outro post. Por enquanto, basta pensar nele como um canal de mensagens que usa um formato muito simples.
Isso nos dá o que precisamos saber para entender o código de retorno de chamada. A primeira linha especifica a rota. A segunda linha envia uma resposta vazia, para encerrar a sessão cURL. Em seguida, verificamos se o canal de eventos enviado pelo servidor já foi configurado. Isso acontece por meio de uma chamada do cliente. Se o canal SSE estiver pronto, marcamos nossos dados como um evento de "atualização" e enviamos o mesmo JSON que recebemos.
Conclusão
As funções são provavelmente meu recurso novo favorito no Couchbase Server 5.5. Examinamos um exemplo aqui, e você pode ver que não é preciso muito para começar. Há muitos outros casos de uso a serem analisados também. Implantar a lógica de negócios junto com os dados, com escalonamento fácil, tudo sem adicionar infraestrutura, é algo muito legal.
Recursos
Para saber mais sobre o aplicativo, assista ao vídeo da palestra aqui, juntamente com esses outros postagens.
Você pode ler uma excelente introdução ao Serviço de eventos do Couchbase em esta postagem. Também recomendo muito que você assista a este vídeo do Couchbase Connect NYC 2018: Faça mais com as mudanças - Apresentando o Couchbase Eventing
Pós-escrito
O Couchbase é de código aberto e grátis para experimentar.
Comece a usar com código de amostra, consultas de exemplo, tutoriais e muito mais.
Encontre mais recursos em nosso portal do desenvolvedor.
Siga-nos no Twitter @CouchbaseDev.
Você pode postar perguntas em nosso fóruns.
Participamos ativamente de Estouro de pilha.
Entre em contato comigo pelo Twitter com perguntas, comentários, tópicos que você gostaria de ver etc. @HodGreeley
