{"componentChunkName":"component---src-templates-blog-post-js","path":"/express-rest-db/","result":{"data":{"markdownRemark":{"html":"

Introdução

\n

No último artigo foi apresentado como construir uma API REST do zero usando NodeJS e Express, foi mostrado como usar o príncipio de injeção de dependências para conseguirmos desacoplar detalhes de implementações.

\n

Agora iremos evoluir um pouco mais esse projeto e iremos adicionar um banco de dados real, no caso será usado MongoDB. Vamos configurar o ambiente usando Docker Compose e vamos entrar em detalhes que não foram apresentados no artigo anterior como os verbos HTTP PUT e PATCH.

\n

Adicionando MongoDB

\n

Vamos adicionar o MongoDB no projeto e para isso iremos começar adicionando essa dependência com o comando abaixo:

\n
npm install --save mongodb
\n

Rodando esse comando o NPM irá adicionar e baixar as dependências necessárias.

\n

Como estamos usando o Docker Compose vamos criar o arquivo docker-compose.yml na raiz do projeto (caso não tenha o Dokcer ou o Docker Compose instalados basta seguir esse tutorial):

\n
version: '3'\n\nservices:\n\n  mongo:\n    image: mongo\n    container_name: mongo\n    environment: \n      MONGO_INITDB_ROOT_USERNAME: admin\n      MONGO_INITDB_ROOT_PASSWORD: password\n      MONGO_INITDB_DATABASE: phonebook\n    volumes: \n      - ./data/init.js:/docker-entrypoint-initdb.d/init.js:ro\n    ports:\n      - 27017:27017
\n

Analisando o arquivo acima além da definição da versão que será usada pelo Docker Compose temos a declaração services que serão os serviços que serão inicializados, que no caso foi chamado de mongo.

\n

Logo após temos a o campo image onde definimos o nome e a versão da imagem Docker que será usada, nesse caso será usada a imagem do MongoDB e como não foi passado uma versão especifica será usado a versão latest.

\n

No campo environment definimos todas as variáveis de ambiente que usaremos nessa imagem. Basicamente definimos um user e password admins do banco e já iniciamos o MongoDB com o database phonebook que usamos na aplicação.

\n

Por fim seria útil além de iniciar o banco já iniciarmos com a collection de contatos, na documentação do MongoDB no DockerHub encontramos uma forma de fazer isso, basta mapearmos um volume contendo um arquivo .sh ou .js e apontarmos para docker-entrypoint-initdb.d que ele será executado. Então aqui é o lugar perfeito para incluirmos a inicialização da collection como mostrado abaixo:

\n
print('---> CONNECTING DATABASE <---');\n\ndb = db.getSiblingDB('phonebook');\n\nprint('---> CREATING COLLECTION <---');\n\ndb.createCollection('contact');\n\nprint('---> CREATING INDEX <---');\n\ndb.contact.createIndex({ name: 1 }, { unique: true })\n\nprint('---> SUCCESS TO RUN SCRIPT <---');
\n

No código acima basicamente nos conectamos no database phonebook e criamos a collection contact e por fim criamos um índice para o campo name.

\n

Se iniciarmos o Docker Compose teremos uma saída que deverá conter entre outras coisas essa informação:

\n
> docker-compose up\n>\n> mongo    | /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/init.js\n> mongo    | {\"t\":{\"$date\":\"2021-04-12T19:35:18.705+00:00\"},\"s\":\"I\",  \"c\":\"NETWORK\",  \"id\":22943,   \"ctx\":\"listener\",\"msg\":\"Connection accepted\",\"attr\":{\"remote\":\"127.0.0.1:38750\",\"connectionId\":3,\"connectionCount\":1}}\n> mongo    | {\"t\":{\"$date\":\"2021-04-12T19:35:18.705+00:00\"},\"s\":\"I\",  \"c\":\"NETWORK\",  \"id\":51800,   \"ctx\":\"conn3\",\"msg\":\"client metadata\",\"attr\":{\"remote\":\"127.0.0.1:38750\",\"client\":\"conn3\",\"doc\":{\"application\":{\"name\":\"MongoDB Shell\"},\"driver\":{\"name\":\"MongoDB Internal Client\",\"version\":\"4.4.5\"},\"os\":{\"type\":\"Linux\",\"name\":\"Ubuntu\",\"architecture\":\"x86_64\",\"version\":\"18.04\"}}}}\n> mongo    | ---> CONNECTING DATABASE <---\n> mongo    | ---> CREATING COLLECTION <---\n> mongo    | {\"t\":{\"$date\":\"2021-04-12T19:35:18.720+00:00\"},\"s\":\"I\",  \"c\":\"STORAGE\",  \"id\":20320,   \"ctx\":\"conn3\",\"msg\":\"createCollection\",\"attr\":{\"namespace\":\"phonebook.contact\",\"uuidDisposition\":\"generated\",\"uuid\":{\"uuid\":{\"$uuid\":\"dfab7eaa-99b0-4b3b-9f41-07b104a27fdb\"}},\"options\":{}}}\n> mongo    | {\"t\":{\"$date\":\"2021-04-12T19:35:18.738+00:00\"},\"s\":\"I\",  \"c\":\"INDEX\",    \"id\":20345,   \"ctx\":\"conn3\",\"msg\":\"Index build: done building\",\"attr\":{\"buildUUID\":null,\"namespace\":\"phonebook.contact\",\"index\":\"_id_\",\"commitTimestamp\":{\"$timestamp\":{\"t\":0,\"i\":0}}}}\n> mongo    | ---> CREATING INDEX <---\n> mongo    | {\"t\":{\"$date\":\"2021-04-12T19:35:18.739+00:00\"},\"s\":\"I\",  \"c\":\"INDEX\",    \"id\":20438,   \"ctx\":\"conn3\",\"msg\":\"Index build: registering\",\"attr\":{\"buildUUID\":{\"uuid\":{\"$uuid\":\"b8a5db18-ea67-4b2b-aad0-fe81e6f46df6\"}},\"namespace\":\"phonebook.contact\",\"collectionUUID\":{\"uuid\":{\"$uuid\":\"dfab7eaa-99b0-4b3b-9f41-07b104a27fdb\"}},\"indexes\":1,\"firstIndex\":{\"name\":\"name_1\"}}}\n> mongo    | {\"t\":{\"$date\":\"2021-04-12T19:35:18.811+00:00\"},\"s\":\"I\",  \"c\":\"INDEX\",    \"id\":20345,   \"ctx\":\"conn3\",\"msg\":\"Index build: done building\",\"attr\":{\"buildUUID\":null,\"namespace\":\"phonebook.contact\",\"index\":\"name_1\",\"commitTimestamp\":{\"$timestamp\":{\"t\":0,\"i\":0}}}}\n> mongo    | {\"t\":{\"$date\":\"2021-04-12T19:35:18.812+00:00\"},\"s\":\"I\",  \"c\":\"INDEX\",    \"id\":20440,   \"ctx\":\"conn3\",\"msg\":\"Index build: waiting for index build to complete\",\"attr\":{\"buildUUID\":{\"uuid\":{\"$uuid\":\"b8a5db18-ea67-4b2b-aad0-fe81e6f46df6\"}},\"deadline\":{\"$date\":{\"$numberLong\":\"9223372036854775807\"}}}}\n> mongo    | {\"t\":{\"$date\":\"2021-04-12T19:35:18.812+00:00\"},\"s\":\"I\",  \"c\":\"INDEX\",    \"id\":20447,   \"ctx\":\"conn3\",\"msg\":\"Index build: completed\",\"attr\":{\"buildUUID\":{\"uuid\":{\"$uuid\":\"b8a5db18-ea67-4b2b-aad0-fe81e6f46df6\"}}}}\n> mongo    | ---> SUCCESS TO RUN SCRIPT <---
\n

Com isso já teremos uma instância do MongoDB rodando e pronta para usar.

\n

Injetando o banco como dependência

\n

Voltando agora para a aplicação precisamos conectar o MongoDB no projeto, para isso iremos começar criando o arquivo mongo_repository.js na pasta repository do projeto:

\n
const MongoClient = require('mongodb').MongoClient\n\nclass MongoRepository{\n\n    constructor(connectionString){\n        this.connectionString = connectionString\n        this.contactCollection = null\n    }\n\n    async init(){\n        await this._connect(this.connectionString)\n    }\n\n    async _connect(connectionString){\n\n        const client = await MongoClient.connect(connectionString, {useUnifiedTopology: true})\n        const db = client.db('phonebook')\n        this.contactCollection = db.collection('contact')\n\n        return this.contactCollection\n\n\n    }\n\n    insert(contact){\n        this.contactCollection.insertOne(contact)\n        .then(result => console.log(\"Dados inseridos com sucesso\", result.result))\n        .catch(err => {throw new Error(err)})\n    }\n\n    async selectAll(){\n        return await this.contactCollection.find().toArray()\n    }\n\n    async selectById(name){\n        return await this.contactCollection.findOne({name: name})\n    }\n\n    async update(name, contact){\n        return await this.contactCollection.findOneAndUpdate(\n            {name: name},\n            {\n                $set: {\n                    name: contact.name,\n                    telephone: contact.telephone,\n                    address: contact.address\n                }\n            },\n            {\n                upsert: true\n            }    \n        )\n    }\n    \n    remove(name){\n        this.contactCollection.deleteOne({name: name})\n        .then(result => console.log(result.result))\n        .catch(err => {throw new Error(err)})\n    }\n}\n\nmodule.exports = MongoRepository
\n

O código acima é uma classe JavaScript onde no seu construtor definimos que queremos receber a string de conexão com o MongoDB, logo abaixo temos a função init que se conectará ao banco e a collection e na sequência temos os métodos para realizarmos as operações de CRUD no MongoDB.

\n

Com isso podemos trocar a classe InMemoryRepository pela MongoRepository no projeto facilmente de forma transparente para a aplicação:

\n
const router = require('express').Router()\nconst MongoRepository = require('../repository/mongo_repository.js')\nconst Service = require('../service')\nconst MongoRepo = new MongoRepository('mongodb://admin:password@localhost:27017')\nMongoRepo.init()\nconst service = new Service(MongoRepo)\n\nrouter.param('name', (req, res, next, name) => {\n    req.name_from_param = name\n    next()\n})\n\nrouter.post('/', async (req, res) => {\n    const contact = req.body\n\n    service.create(contact)\n\n    res.status(201).json(contact)\n})\n\nrouter.get('/:name', async (req, res) => {\n\n    const id = req.name_from_param\n\n    const result = await service.getById(id)\n    if(result !== undefined){\n        res.status(200).json(result)\n        return\n    }\n    \n    res.sendStatus(204)\n    \n})\n\nrouter.get('/', async (req, res) => {\n\n    const result = await service.getAll()\n\n    if(result.length > 0){\n        res.status(200).json(result)\n        return\n    }\n\n    res.sendStatus(204)\n    \n})\n\nrouter.put(\"/:name\", async (req, res) => {\n\n    const name = req.params.name\n    const body = req.body\n\n    const result = await service.put(name, body)\n\n    res.status(200).json(result)\n})\n\nrouter.delete(\"/:name\", async (req, res) => {\n\n    const name = req.params.name\n\n    service.remove(name)\n\n    res.sendStatus(204)\n})\n\nmodule.exports = router
\n

Entendo o código acima por partes, primeiramente temos a importação e nela já iniciamos o banco e o injetamos como dependência na Service:

\n
const MongoRepository = require('../repository/mongo_repository.js')\nconst Service = require('../service')\nconst MongoRepo = new MongoRepository('mongodb://admin:password@localhost:27017')\nMongoRepo.init()\nconst service = new Service(MongoRepo)
\n

E o restante do código basicamente não se altera, essa é uma das grandes vantagens de não usar um código acoplado, é a facilidade que temos de trocá-lo rápidamente quando necessário, então temos um código com baixo acoplamento mas com alta coesão já que suas funcionalidades estão explicitas e segregadas.

\n

Testando as alterações

\n

Da mesma forma que foi dito anteriormente nada foi alterado com a mudança do banco de dados então para quem estiver usando a aplicação nada deve mudar. Vamos testar isso agora.

\n

Realizando um POST teremos o seguinte resultado:

\n
curl --location --request POST 'http://localhost:3000/api' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n\n    \"id\": 1,\n    \"name\": \"Kelly\",\n    \"telephone\": \"118888888\",\n    \"address\": \"Rua dos Bobos n 1\"\n\n}' | json_pp
\n

Teremos o seguinte resultado:

\n
{\n    \"id\": 1,\n    \"name\": \"Kelly\",\n    \"telephone\": \"118888888\",\n    \"address\": \"Rua dos Bobos n 1\",\n    \"_id\": \"607d805caa972341ebd3e568\"\n}
\n

Está muito parecido com o que tínhamos porém temos um detalhe que não havia antes que é o campo _id que está retornando.

\n

Isso é um problema por alguns motivos mas o principal deles é que o nosso modelo está seguindo a implementação do banco de dados e isso causa uma aplicação acoplada, para resolver isso teremos que começar a usar o modelo que foi definido no primeiro artigo, mas não será visto agora pois teremos que fazer algumas alterações para isso e acredito que ficará muito extenso fazer aqui e foge um pouco da temática desse artigo que é de se conectar ao banco do MongoDB; porém para agora vamos deixar assim mas sabendo que é um ponto de alteração também pelo fato de expor um id interno poder ser considerado uma falha de segurança da aplicação.

\n

Obs: Foi realizada uma alteração no módulo de rotas pois as chamadas GET /health e GET /:name estavam conflitando então foi necessário adicionar a seguinte configuração:

\n
router.param('name', (req, res, next, name) => {\n    req.name_from_param = name\n    next()\n})
\n

E após isso o roteamento do GET /health deve ser feito antes do roteamento do GET /:name

\n
router.get('/health', (req, res) => {\n\n    res.status(200).json({status: \"Ok\"})\n})\n\nrouter.get('/:name', async (req, res) => {\n\n    const id = req.name_from_param\n\n    const result = await service.getById(id)\n    if(result !== undefined){\n        res.status(200).json(result)\n        return\n    }\n    \n    res.sendStatus(204)\n    \n})
\n

PUT vs PATCH

\n

Temos hoje no projeto configurado as rotas para fazer criação, leitura, escrita e deleção de dados, mas como pode ser visto nós usamos o verbo HTTP PUT quando queremos atualizar um contato, porém o PUT é usado quando queremos realizar atualizações completas em uma entidade, o que devemos fazer nesse caso se quisermos atualizar somente um campo do contato?

\n

Para isso existe o verbo HTTP PATCH e ideia por trás dele é usarmos quando precisamos fazer atualizações parciais em uma entidade. Para isso vamos preparar a partir das rotas até a persistência no banco de dados.

\n

Começando pelo módulo router:

\n
router.patch(\"/:name\", async (req, res) => {\n\n    const name = req.params.name\n    const body = req.body\n\n    service.patch(name, body)\n\n    res.sendStatus(204)\n})
\n

Não muda muita coisa do que já foi feito nas outras rotas, usamos a função patch do Express e informamos no path que passaremos o name como parâmetro e o body com o objeto que conterá a atualização parcial e chamamos a service que também deverá possuir uma função chamada patch.

\n

Agora no módulo service:

\n
patch(name, body){\n    return this.repository.patch(name, body);\n}
\n

Aqui é mais simples pois só é usado como um adaptador para a chamada ao módulo de persistência nesse momento.

\n

E por fim no arquivo mongo_repository.js no módulo repository:

\n
async patch(name, contact){\n    return await Object.entries(contact).forEach(([key, value]) => {\n        let obj = {}\n        obj[key] = value\n        return this.contactCollection.findOneAndUpdate({name: name}, {$set: obj})\n    })\n}
\n

Aqui usamos a função Object.entries que itera sobre um objeto e devolve um array onde a chave é o nome do atributo e o valor é o valor daquele atributo e com isso conseguimos iterar por esse array e realizar a operação que atualizará somente os campos que informamos.

\n

Agora conseguimos testar e teremos a atualização parcial:

\n
curl --location --request PATCH 'http://localhost:3000/api/Kelly' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n    \"address\": \"novo endereco novo\"\n}'
\n

Mas a questão que pode ser discutida é por que usar dois verbos HTTPs diferentes para fazer quase a mesma coisa? Por que não usar o PUT e fazer a atualização do que for passado, seja uma entidade inteira ou apenas parcial?

\n

A resposta pra isso é que os verbos HTTPs são guias de como a sua API funciona então a semântica deles importa e quando entrarmos nos detalhes sobre documentação de APIs vamos conseguir entender melhor que para quem usar a API é melhor se usarmos um padrão do que ter que ter uma longa documentação sobre os detalhes internos do processamento de dados. Mais detalhes sobre o PATCH podem ser encontrados aqui.

\n

Conclusão

\n

Nesse artigo vimos como configurar o MongoDB usando o Docker Compose e como podemos usufruir da inversão de dependências para poder trocar facilmente dependências sem quebrar o nosso código ganhando mais produtividade.

\n

Vimos como conectar a aplicação ao MongoDB e também aprendemos um pouco sobre o verbo HTTP PATCH e saímos com um ponto de melhoria que é a exposição de entidades pela nossa API, veremos como melhorar essa parte no próximo artigo.

\n

Código do projeto

\n

Segue o GitHub com o projeto usado nesse artigo.

","fields":{"slug":"/express-rest-db/"},"frontmatter":{"date":"19 de abril de 2021","description":"Conectando uma aplicação web ao MongoDB","title":"Express e MongoDB","tags":["JavaScript","NodeJS","Express","Rest","Mongo"],"author":"Guilherme Alves","image":{"id":"712e371f-ffda-5698-be36-3c2be008aeca","publicURL":"/static/360b3ef7da0d7f14b487bd1dcaba8d90/capa-node-express-mongo.png","childImageSharp":{"fluid":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAA7EAAAOxAGVKw4bAAABYUlEQVQoz51TS0rEQBDNUo/gYq6gIrjREVy4GBeiLgRhVAYUFD/gAUTwCh5B8QCKrsWN6IwhmAmZbEQU8v+YAW0hk+5n7EzCqAuNBUVVd/q9flWpFpAYY4w7ZZR7ts6+FTEhB9GeXYr/E2aARBscosN9N8C67L2kf3Wu8CFQsbU3g+r6BBbXxrC9P4vHFy29iNHiJZ/dHmGw1IeVgwrmdssYKvXj4u6EH+h0IhiGAcdx0G6389w0Tei6Dsuy4Louj7nCS+UU46MDqB3PY+FwGuUkv2qdc8I38op6vQ5RFHlUVRWSJEFRFDQaDTSbTciyzCMhJCUMYgfVpNTK5gimVoexnJQeUo8TxjSG53lcne/70DQNYRhy8Oc6CAKu2LZtRFEEgdK0R/f6NZY2yqjtTEI2btL+0WL9y3uYAU3yBIs8fyEr8ofTHnbHjCal5WOY5Qw/hvy3+RR6D2Uv5Tu4iH0A+Rg146gZ2kMAAAAASUVORK5CYII=","aspectRatio":1.7777777777777777,"src":"/static/360b3ef7da0d7f14b487bd1dcaba8d90/0823f/capa-node-express-mongo.png","srcSet":"/static/360b3ef7da0d7f14b487bd1dcaba8d90/c67b7/capa-node-express-mongo.png 320w,\n/static/360b3ef7da0d7f14b487bd1dcaba8d90/d3930/capa-node-express-mongo.png 640w,\n/static/360b3ef7da0d7f14b487bd1dcaba8d90/0823f/capa-node-express-mongo.png 1280w,\n/static/360b3ef7da0d7f14b487bd1dcaba8d90/c730b/capa-node-express-mongo.png 1920w,\n/static/360b3ef7da0d7f14b487bd1dcaba8d90/55bfe/capa-node-express-mongo.png 2240w","sizes":"(max-width: 1280px) 100vw, 1280px"}}}},"timeToRead":11}},"pageContext":{"slug":"/express-rest-db/","previous":{"fields":{"slug":"/express-rest-I/"},"frontmatter":{"title":"NodeJS e Express","date":"06 abr, 2021"}},"next":{"fields":{"slug":"/express-celebrate-joi/"},"frontmatter":{"title":"Validando endpoints com NodeJS","date":"27 abr, 2021"}}}},"staticQueryHashes":["63159454"]}