Projeto Meetup do Couchbase na pilha OCEAN disponível

Recentemente, estive em dois grupos Meetup diferentes no sul da Califórnia apresentando o que estou chamando de pilha OCEAN, que é composta pelo Ottoman.js, Servidor Couchbase, Express Framework, Angular e Node.js.

Tivemos uma grande participação de desenvolvedores interessados em aprender sobre uma pilha JavaScript com NoSQL.

De acordo com minha promessa aos grupos, fiz um tutorial do conteúdo que compartilhei para que todos possam se beneficiar. Veremos como desenvolver um aplicativo da Web funcional usando várias tecnologias JavaScript e NoSQL.

Antes de entrar no código, pressupõe-se que você tenha o Couchbase Server instalado e configurado, bem como o Node.js. O foco aqui será o desenvolvimento, não as configurações do ambiente.

Vamos criar uma API usando Ottoman.js e depois com N1QL em vez de Ottoman.js. Ambas as APIs serão consumidas por um front-end desenvolvido em Angular.

Desenvolvimento de uma API com Ottoman.js, Express Framework e Couchbase NoSQL

A primeira etapa de qualquer projeto do Node.js é configurar um projeto e fazer download de todas as dependências. A criação de um novo projeto e o download das dependências podem ser feitos com os seguintes comandos:

O primeiro comando criará o arquivo package.json e o segundo comando obterá nossas dependências, que incluem o analisador de corpo para aceitar corpos JSON na solicitação e o cors para problemas relacionados a origens cruzadas que podem surgir ao usar o Angular em um domínio ou porta diferente.

Para inicializar nosso aplicativo, vamos criar um arquivo chamado app.js que contém o seguinte código JavaScript:

Essencialmente, acabamos de importar nossas dependências baixadas, definimos nossos pontos de extremidade de API, estabelecemos uma conexão com o Couchbase Server e começamos a servir o aplicativo.

Os pontos de extremidade da API serão para operações CRUD básicas em nosso banco de dados. Como estamos usando o Ottoman.js, que é um modelador de documentos de objetos (ODM), precisamos definir nosso modelo. Acima das definições de endpoint, adicione o seguinte:

Esse modelo pode ser infinitamente complexo, mas o nosso representará apenas um perfil de usuário simples. Esse é o modelo que manipularemos em nosso código, bem como no banco de dados.

Como nosso banco de dados está vazio no momento, faz sentido trabalhar em nosso endpoint para criar dados. Edite o seguinte trecho de JavaScript em seu projeto:

O endpoint acima é provavelmente a parte mais complexa do nosso projeto. Estamos dizendo que estamos exigindo um corpo POST. Não importa o que ele seja, desde que exista.

Com esse ponto de extremidade, atingimos dois coelhos com uma cajadada só. Estamos realizando uma criação e também uma atualização. Primeiro, fazemos uma pesquisa pelo ID passado. Não importa se um ID foi passado ou não. Se houver um erro, por exemplo, se a id não existir, será criado um novo modelo ODM com base em nossa definição; caso contrário, ele será mesclado com o que obtivemos em nossa pesquisa com base na id.

Quando o modelo estiver concluído, poderemos salvar e retornar os resultados ao usuário.

A próxima etapa lógica é concluir o endpoint para encontrar uma pessoa específica pelo valor de id. Adicione o seguinte JavaScript ao seu projeto:

Usando um valor de id passado, podemos obter alguém do banco de dados e devolvê-lo ao cliente que emitiu a solicitação.

Pode haver ocasiões em que desejamos obter todos os registros que correspondem ao modelo. Pode até haver ocasiões em que desejamos consultar com base em propriedades que não sejam o valor de id. Nesse caso, podemos usar um encontrar comando:

Ao fornecer um objeto vazio em nosso comando, estamos solicitando todos os documentos que correspondem ao modelo. Isso poderia ter sido facilmente estendido para propriedades correspondentes específicas. Também queremos ter certeza de que nosso índice está atualizado antes de concluirmos a consulta. Por padrão, o Couchbase é focado no desempenho, o que significa que, se o índice ainda não tiver sido atualizado, os resultados poderão não conter alguns dados. Dependendo da circunstância, você pode alterar a consistência da varredura, como fizemos no exemplo acima.

Por fim, podemos criar nosso ponto de extremidade para remover documentos do banco de dados:

Primeiro, obtemos um documento pelo id passado e, se ele existir, podemos emitir um remover para excluí-lo.

Se você executar esse aplicativo e usar uma ferramenta como CarteiroVocê pode testar sua API básica, mas totalmente funcional.

Desenvolvimento de uma API com Express Framework, N1QL e Couchbase NoSQL

Digamos que usar um ODM como o Ottoman.js não seja a sua praia e que você prefira criar suas próprias consultas. A remoção do Ottoman.js nos dá a pilha CEAN, e isso é possível com o N1QL.

Embora nossa estrutura de projeto seja bastante semelhante, vamos criar um novo projeto para nossa própria sanidade.

Temos dependências semelhantes às vistas no projeto anterior, mas, desta vez, estamos obtendo um pacote para gerar valores UUID. O Ottoman.js criou valores de id para nós, mas, com o N1QL, isso fica a cargo do desenvolvedor. Uma das muitas maneiras de criar um ID é por meio de um UUID.

Em um novo app.js você pode ter o seguinte código padrão:

Isso deve parecer bastante familiar, mas, desta vez, trocamos o Ottoman.js pela preparação do N1QL.

Assim como no exemplo anterior, vamos nos preocupar em salvar os dados antes de tentarmos ler do banco de dados. Confira o código do endpoint a seguir:

Se recebermos um ID com nossa solicitação, vamos usá-lo e presumir que estamos fazendo uma atualização; caso contrário, vamos gerar um novo ID e fazer uma criação. Ambas as operações podem ser realizadas com um único comando UPSERT consulta. Para evitar ataques de injeção de SQL, usaremos uma consulta parametrizada para parametrizar nossos dados definidos pelo usuário.

Se soubermos o ID e quisermos encontrar um documento específico, poderemos usar um SELECIONAR consulta para o trabalho:

Em ambas as consultas, estamos retornando o erro ou os resultados para o cliente que emitiu a solicitação.

Se quisermos consultar todos os nossos documentos, podemos eliminar a opção ONDE e definir nossa consistência de varredura da seguinte forma:

Como o N1QL é apenas outra variante do SQL, nossas possibilidades de consulta são bastante amplas. Este exemplo de API não cobre nem mesmo uma fração do que é possível.

Por fim, se quisermos remover um documento pelo seu valor de id, podemos fazer algo como o seguinte:

Nenhum desses pontos de extremidade baseados em N1QL foi difícil. Não há uma escolha errada quando se trata de Ottoman.js ou N1QL, tudo se resume à preferência.

Criação de um front-end de cliente com Angular e TypeScript

Com a API de backend fora do caminho, podemos nos concentrar em um frontend de cliente muito simples, mas funcional. Esse frontend funcionará tanto com a pilha OCEAN quanto com o exemplo da pilha CEAN. É sempre bom ter algo modular.

Supondo que você tenha o CLI angular instalado e configurado, precisamos ter um novo projeto:

O comando acima criará um novo projeto com todas as dependências necessárias do Angular.

Neste ponto, você pode usar a CLI para gerar cada uma de nossas páginas ou fazê-las manualmente. Ambos o colocarão no mesmo lugar.

Crie os seguintes arquivos e diretórios em seu projeto da maneira que desejar:

Começando com o que será nosso AlterComponent, abra o arquivo src/app/alter/alter.component.ts e inclua o seguinte código TypeScript:

Há muita coisa acontecendo no código acima, portanto, vamos detalhá-lo.

Dentro do construtor temos o seguinte:

Estamos inicializando nossas variáveis públicas, uma que representa os dados do nosso formulário e a outra que representa um possível ID para um documento existente. Além disso, também estamos injetando vários serviços do Angular para uso no componente.

Mais uma vez, vamos acertar dois coelhos com uma cajadada só. Esse componente representará uma tela para criar e atualizar documentos.

Dentro do ngOnInit pegamos um possível ID de documento e fazemos uma pesquisa dos dados que residem nele:

Se nenhuma identificação estiver presente, nada acontecerá e nosso entrada não será preenchida com nada além de strings vazias. A pesquisa será uma solicitação HTTP para o ponto de extremidade da API que criamos anteriormente com Ottoman.js ou N1QL.

A última coisa a ser feita para esse componente é salvar:

Se houver um ID, nós o passaremos com nossa solicitação POST. A solicitação POST terá os dados serializados do formulário. Se a solicitação for bem-sucedida, poderemos navegar para a tela anterior.

O HTML que acompanha essa lógica do TypeScript pode ser encontrado no arquivo src/app/alter/alter.component.html e ele se parece com o seguinte:

Como não sou um grande artista, esse HTML será muito básico e não terá nenhum estilo. Observe que cada elemento do formulário está vinculado ao nosso elemento público entrada objeto.

O segundo e último componente do projeto serve para listar todos os documentos salvos. Abra a seção src/app/list/list.component.ts e inclua o seguinte código TypeScript:

Mais uma vez, vamos detalhar isso.

Dentro do construtor inicializamos nossas variáveis públicas:

Nesse caso, a variável pública é a nossa lista de documentos que serão exibidos na tela. A próxima etapa é consultar qualquer um que possa existir e preencher a matriz agora vazia:

A esta altura, você já deve ter notado que o frontend é, em sua maior parte, apenas um conjunto de solicitações HTTP à nossa API. O backend faz a maior parte do trabalho pesado.

Precisamos consultar os documentos quando o aplicativo for carregado e quando navegarmos para trás na pilha de navegação do Angular. Isso pode ser visto na seção ngOnInit método:

Precisamos nos inscrever no ouvinte de localização para podermos determinar quando navegamos para trás. Fazemos isso porque o construtor e ngOnInit são acionados somente quando se navega para, e não quando se navega de volta para.

Isso nos leva à remoção de documentos:

No HTML, teremos um botão ao lado de cada item da lista. Esse botão nos permitirá remover documentos chamando a função excluir e passando o ID do documento específico. Se for bem-sucedido, o item será removido do banco de dados e colocado localmente na matriz.

O HTML por trás dessa lógica pode ser encontrado na seção src/app/list/list.component.html e tem a seguinte aparência:

O roteadorLink nos levará à página de criação ou atualização de dados. Em seguida, percorremos nossa matriz, apresentando cada documento na tela. Se o item for clicado, navegaremos até a página de atualização e passaremos o ID do documento que foi clicado. Isso nos permite preencher previamente o formulário. Caso contrário, se quisermos excluir um documento, clicamos no outro botão.

Embora o conteúdo principal seja feito com o lado angular das coisas, precisamos reuni-lo por meio do Angular Router.

Abra o arquivo src/app/app.module.ts e inclua o seguinte:

Observe que acabamos de importar nossos componentes e definimos uma rota para cada um deles. Não há nada muito sofisticado acontecendo aqui.

Dependendo da sua versão da CLI do Angular, talvez seja necessário alterar o arquivo src/app/app.component.html para conter o seguinte:

Isso permite que a navegação trabalhe no projeto.

Conclusão

Você acabou de ver o material da pilha OCEAN e da pilha CEAN que apresentei no Angular Orange County e o grupo Couchbase Los Angeles grupo.

Se você for um desenvolvedor de MongoDB e estiver pesquisando o Couchbase pela primeira vez, poderá dar uma olhada em um livro de receitas que escrevi, que se aprofunda no Ottoman.js e no N1QL e explica como migrar do MongoDB.

Para obter mais informações sobre o Couchbase e o Node.js, consulte o Portal do desenvolvedor do Couchbase.