Tutorial: Criar um aplicativo de pontos de interesse com Vue.js, Node.js, Express e Couchbase Server

Percorrendo a seção do script, você verá que faço uso intenso dos recursos reativos do Vue. Para entender essa parte, será útil se você tiver pelo menos alguma familiaridade com o Vue, especialmente propriedades computadas e observadores, dados, método e ganchos de ciclo de vida.

Fazemos uso do montado para adicionar um ouvinte para eventos enviados pelo servidor e para preencher inicialmente a lista suspensa de cidades. O trabalho mais pesado da lógica comercial aqui acontece na consulta ao banco de dados, como veremos.

Vamos acompanhar como funciona a seleção de uma cidade. Observe que cada item no menu suspenso do botão tem um ouvinte de clique vinculado que define selecionado para os dados da cidade para essa entrada. Temos um método watch definido em selecionado. O Vue também sabe automaticamente que a propriedade computada exibição depende de selecionado.

Isso significa que sempre que uma cidade é selecionada por meio do menu suspenso, temos uma cascata de atividades. Mudança selecionado causas exibição a ser recalculado. Isso, por sua vez, define o texto do botão suspenso, já que ele está vinculado a exibição. O selecionadono método assistir aciona uma atualização da tabela de listagem de hotéis sempre que uma nova cidade é selecionada.

A tabela itens estão vinculados a destinationsProvider sob métodos. A atualização da tabela faz com que esse código seja executado. Como a lista de cidades original, ele extrai os hotéis por meio de uma chamada assíncrona ao nosso banco de dados por meio de um endpoint REST do servidor.

O Vue cuida de muitas coisas aqui para nós. Por exemplo, a chamada para atualizar a tabela não recebe dados imediatamente. O Vue renderizará novamente as partes relevantes do DOM automaticamente sempre que a chamada REST retornar. Não precisamos fornecer nenhum dos cabos, a não ser especificar a ligação entre itens e provedor de destino.

Carregamos a chave da API do Google Maps de um arquivo config.js. Crie esse arquivo e, por enquanto, adicione este código de espaço reservado.

Crie o projeto novamente (npm run build). Inicie o servidor, recarregue o site e você verá o início do nosso cliente real com esta aparência.

Os dois blocos de código para conexão ao nosso banco de dados são muito simples.

As três primeiras linhas importam o cliente Node do Couchbase, criam um novo objeto de cluster que representa um cluster de nós de banco de dados e autenticam esse cluster. Isso inicia a conexão com o banco de dados.

Por conveniência, adicionamos referências aos objetos do cliente e do cluster ao app.locals. Isso os torna disponíveis globalmente.

Por fim, o código estabelece e salva conexões com dois buckets. Baldes são uma estrutura organizacional de alto nível no Couchbase.

O primeiro bucket será preenchido com dados de amostra que vêm com as instalações do Couchbase Server. Para o segundo bucket, estou fazendo algumas alterações. Precisamos de um bucket de metadados para o Serviço de eventos. Como veremos, precisamos de apenas alguns documentos extras armazenados, que precisam ir para algum lugar além do bucket principal. Em vez de criar um terceiro bucket, eu os coloco junto com os dados de eventos. Normalmente, você não usaria esse atalho na produção.

Temos apenas algumas linhas de código que precisamos direcionar ao Express para servir nossas páginas estáticas criadas a partir do código do cliente e para organizar nossa API de dados do servidor.

O modelo index.html A página inicial do aplicativo adiciona dist para todos os caminhos de arquivos. Isso significa que nossos arquivos estáticos são realmente servidos a partir de um diretório raiz de /cliente/dist.

Separei a API de dados em dois grupos, organizados em uma categoria geral rotas subdiretório. Há os pontos de extremidade que começam com registros. Eles recuperam dados do banco de dados.

O eventos A rota é exclusiva. Os pontos de extremidade são usados pelo cliente da Web e pelo Couchbase Eventing Service.

Vamos dar uma olhada no registros código primeiro.

Temos três rotas definidas aqui, /destinos, /hotels/byCity/:ide /select/geo. Todos eles têm a mesma estrutura básica. Obtemos nossas referências de banco de dados, usamos o bluebird para criar versões de promessa do método de consulta, construímos um N1QL disparar a consulta e retornar os resultados.

Vamos analisar as consultas, começando pela mais simples.

Usamos o /select/geo para armazenar a escolha atual de hotel feita pelo usuário. Aqui está a consulta dividida.

UPSERT modificará um documento ou o criará se ele ainda não existir. Armazenamos a geolocalização do hotel escolhido em um documento com um id de gatilho. Isso provavelmente parece estranho. Isso fará mais sentido mais tarde, quando chegarmos ao código Eventing. O que realmente nos interessa não é apenas a localização do hotel, mas os pontos de interesse próximos. Esse documento acionará a sequência que recupera esses POIs. Daí a razão para chamar o documento gatilho.

Aqui está um exemplo do documento criado.

Para entender o /hotels/byCity/:id consulta, primeiro dê uma olhada em alguns documentos de exemplo.

Para nossa tabela de hotéis, precisamos do nome do hotel, endereço, geolocalização, nome do aeroporto e código do aeroporto. Obviamente, isso é uma combinação de dados de ambos os documentos. Fazemos isso usando um INNER JOIN. Aqui está a pergunta.

Ao analisá-lo, você pode ver que conseguimos realizar a união usando documentos do mesmo bucket. Eu uso aliases para deixar as coisas mais claras. Usamos a cidade de cada documento para formar a condição de união. Observe que também uso o documento tipotanto na condição de união quanto na condição de ONDE cláusula. As condições de união podem ser bastante sofisticadas. Leia isto blog para obter mais detalhes e exemplos.

Por fim, vamos examinar como chegamos à nossa lista de cidades em primeiro lugar. Esta é a consulta para o /destinosponto final.

O único resultado retornado é uma lista de nomes de cidades. Nesse caso, estamos usando uma junção interna efetivamente como um filtro. Ao fazer a correspondência entre cidades aeroportuárias e cidades hoteleiras, obtemos uma lista apenas das cidades que têm ambas.

As uniões internas podem usar duas abordagens diferentes em termos de algoritmo. A primeira união que examinamos usa a união de loop aninhado padrão.

Este último exemplo usa uma tabela de hash na memória. Isso pode acelerar significativamente uma união, especialmente quando um dos dois conjuntos de dados é pequeno. Usamos a tabela "USE HASH()" para informar ao N1QL como queremos que a consulta seja otimizada. Há um lado "probe" e um lado "build". A tabela de hash é criada a partir dos dados do lado da construção. A junção é realizada fazendo pesquisas a partir dos dados do lado da sonda.

A dica que demos acima diz ao N1QL para usar os dados do hotel para o lado da sonda nesse caso. Ou seja, ele criará a tabela a partir dos dados do aeroporto e, em seguida, fará as pesquisas de hash usando os dados do hotel.

Se ainda não o fez, recomendo que experimente essas consultas diretamente no Couchbase Server Query Workbench, parte do console de administração da Web.

Já mencionamos a configuração de um ouvinte de eventos para eventos enviados pelo servidor no lado do cliente. Esses dois pontos de extremidade mostram o que é necessário no servidor.

A versão "get" do poi é chamado pelo navegador quando o ponto de extremidade Origem do evento é construído. Você pode ver que simplesmente adicionamos o chamador como um cliente.

Usamos a versão "post" como intermediária para enviar dados ao cliente. A versão res.send(''); dá uma dica de como isso funciona. No código Eventing, usaremos os recursos cURL do N1QL para enviar dados para esse endpoint. A resposta vazia está lá para encerrar essa transação.

Em seguida, o servidor encaminha os dados para todos os clientes que estiverem ouvindo. Há muito mais detalhes. Se você quiser saber mais, este artigo tem boas informações.

Para concluir o lado do servidor do nosso projeto, crie um subdiretório rotas no diretório do servidor.

Copiar o registros acima em um arquivo em rotas chamado registros.js. Copiar o eventos código acima em um arquivo chamado eventos.js. E, finalmente, no próprio diretório do servidor, crie um novo arquivo chamado .env. Cole os seguintes parâmetros de configuração e salve. (É claro que você pode alterar as configurações conforme necessário).

O servidor deve estar pronto para funcionar agora. No diretório raiz do servidor, execute nó app.js. Não se esqueça de criar o código do cliente primeiro.