[Imersão Dev Back-End] Criando e Estruturando sua Primeira API com GET e Banco de Dados

Chegamos na segunda aula da Imersão Dev com Google Gemini e eu adorei a primeira aula. Foi simplesmente incrível criar o ambiente com o Node, importar o Express, instanciar lá a execução do Express, criar o Endpoint. .

. foi tanta coisa bacana. Vamos fazer um resumo da primeira aula para o pessoal?

Vamos, um resumo muito rápido. O que a gente criou? O que é instanciar?

Criamos uma instância, criamos uma unidade, digamos assim, do nosso servidor que está lá na linha 3, Express, passamos tudo para dentro da variável app. Nosso servidor está fazendo duas coisas nesse momento. Ele está ouvindo requisições que chegam na porta 3000, como que estamos chegando nessa porta?

Através de localhost:3000 lá no navegador. E está voltando. Por enquanto, só temos uma rota, que é a rota "/api", e essa rota é uma rota do tipo GET, ou seja, uma rota que vai pegar algo do servidor, vamos também ver outros tipos de rota.

Vamos lá em localhost, que é a nossa URL base, como a gente diz, Em "/api", faz uma requisição para o nosso servidor. Nós estamos indo do nosso computador para o nosso computador mesmo, tudo bem, faz parte. E o que vem na nossa resposta?

A gente determinou que a nossa resposta tem um status de 200 e um send onde tem os dados. Vamos lá no status de 200. 200 é um dos números, um dos códigos HTTP.

O que é um código HTTP? É uma série de códigos numéricos com um texto associado a eles que indica basicamente tudo o que pode acontecer em uma conexão entre cliente e servidor. Vamos falar sobre cliente e servidor.

O 200 é o que sempre queremos, 200 significa OK. Ou seja, a nossa requisição foi enviada, foi recebida e devolveu uma resposta com sucesso. Nós que estamos determinando que a resposta da nossa requisição é 200, e junto com esse status de resposta vem algum dado.

No caso, o send. São muitos status de resposta. Existem vários.

Não vamos decorar todos, mas tem uma forma legal de consultar. Exato. Vamos fazer isso.

Vamos abrir uma aba do navegador. O que é que eu digito? Bom, você nem acredita na URL que você vai digitar.

A URL é http. cat. "cat" de "gato".

Está de zoeira. É isso mesmo? É isso mesmo.

É uma forma divertida de mostrar todos os status possíveis no que chamamos de comunicação HTTP. Eles vão da faixa do 100, que normalmente é o "continue". Faixa do 200, que é OK e derivados do OK.

Faixa de 300, que são redirecionamentos. E o mais famoso está na faixa dos 400, que você com certeza já viu na sua vida, que é o 404. O que é o 404?

404 é o status que a gente envia na resposta da requisição, dizendo o que você pediu não foi encontrado. Ou seja, "/api" não existe, o endereço que você digitou não existe. Não quer dizer que a sua requisição foi feita de um jeito errado.

Quer dizer que o recurso não existe. Então, quando a gente monta APIs, quando a gente constrói APIs, Mapeamos essa situação. A gente, quem está desenvolvendo.

O código 404 significa que seu recurso não foi encontrado. E as páginas web, normalmente têm layout, têm templates prontos, que quando a gente recebe uma resposta de requisição que bate nesse status, já coloca página. E é por isso que a gente vê as páginas 404.

E o mais legal é que dá para fazer uma malandragem que não recomendo a ninguém. Você pode retornar o código HTTP que você quiser. Você pode pegar uma requisição que deu sucesso, como a nossa, e colocar um 404.

Mas, como todo código, é um combinado entre os Devs do mundo inteiro. Então, o que a gente espera? Que toda vez que seja uma requisição que retorna sucesso, volte 200.

Se não retornar sucesso, temos que tomar o cuidado de não colocar o 200 lá. De novo, não é que não vai funcionar, é que vai estar fora do padrão. Acho que os outros devs vão te olhar meio torto, vão achar seu sistema meio esquisito.

Exato, isso é uma convenção, é um padrão que a gente utiliza. Nós, quando estamos desenvolvendo, é que definimos. E não, por exemplo, se caiu a conexão.

Não é a conexão que define, é a gente que define. E os erros 400 são erros da faixa do cliente. E o 500, erros da faixa do servidor.

Ou seja, o seu servidor caiu, recebeu muita requisição, etc. Vamos utilizar normalmente o 200. E status HTTP é um desses temas que é bacana você depois anotar ali para pedir para o Gemini explicar mais, pedir para ele dar mais exemplos, dar uma focada.

E o que mais precisamos saber agora? A nossa aplicação, nesse momento, funciona muito bem por um lado e decepciona por outro. Ela funciona muito bem porque temos um servidor.

Legal, esse servidor está funcionando, escuta lá na porta 3000. A gente já tem uma rota. E essa rota retorna algo, retorna a frase da torre Eiffel.

Por que é decepcionante? Porque o nosso objetivo, quando desenvolvemos o back-end de uma aplicação, é retornar informações e dados que possam ser consumidos no front. Ou seja, queremos retornar coisas que preencham a nossa página do Instalike.

Queremos retornar o ID de uma foto, a foto em si, a descrição dela. . .

talvez o número de comentários. Tem tanta coisa. O que nós vamos começar a construir aqui?

Vamos construir uma rota que retorne fotos, que retorne dados, para a gente poder consumir no front? O primeiro passo será ter uma base de dados. Olha que bonito esse nome, hein?

Base de dados. Talvez você que esteja escutando e acompanhando o nosso papo estranhou que eu não falei "banco de dados". Eu falei "base de dados".

O que eu estou dizendo? Precisamos de algum lugar em que possamos olhar e puxar esses dados que queremos devolver. Mais para frente, isso até será um banco.

Agora, vamos criar um objeto especial que existe no mundo da programação que é chamado de array, é uma estrutura. O que essa estrutura faz? Permite guardar um montão de dados de uma vez só, em um lugar só.

Vamos criar uma estrutura que a gente possa consultar depois. Vamos para ela? Vamos lá.

Como a gente faz para criar? Eu vou criar uma pasta para manter esses dados? Eu crio aqui direto?

Nesse momento, como vamos fazer só alguns testes, vamos criar tudo no mesmo arquivo para facilitar? Beleza. Na linha 2, depois que você importou, vamos criar outra const, outra variável.

Podemos chamar essa const de posts. Ok, igual. Como é que a gente cria uma array, uma lista?

Começa abrindo e fechando colchetes. Sempre abrir e fechar colchetes significa que dentro vai ter uma lista de algum tipo de dado. Pode ser uma lista de strings, uma lista de números.

Nesse caso, é uma lista um pouco diferente, porque vamos criar dentro dessa lista alguns posts, com foto, com ID, etc. O que precisa ter? Vamos fazer o seguinte?

Vamos dizer que cada post tem uma descrição e o caminho da imagem. A descrição eu posso deixar sem nada ou preciso colocar entre. .

. Não precisa colocar entre aspas, porque é uma palavra só. Como criar esses grupos?

Dentro do colchetes, vamos criar esses grupos de informação entre chaves. Então, abre duas chaves e dentro dela vamos criar duplas de informação. Bem parecido com aquela do Alura Livros.

Isso. A primeira informação que temos é a descrição. Descrição, dois pontos, coloca a descrição.

Pode colocar uma foto, uma foto teste, etc. Vai ser uma string. Vírgula, fora da string.

Vamos criar a segunda coisa que o nosso post deve ter. Por exemplo, imagem. Imagem, dois pontos.

Também uma string. E aqui podemos colocar um placeholder de imagem ou. .

. Por enquanto podemos colocar. .

. Eu vou te falar um link que você pode usar toda vez que você precisar desse placeholder que a Ju está falando. Você pode usar esse link que eu anotei aqui.

https://placecats. com/millie/300/150 Isso não é um código. É só um link para algo que vai marcar a presença de uma imagem na página.

Deixa eu verificar se digitei certo. Quando a minha aplicação acessar esse link, vai ter uma imagem de um gatinho. Exato, deu para perceber uma certa temática aqui, uma tendência.

A gente usa essas imagens prontas justamente para fazer esse tipo de teste enquanto a gente ainda não tem o nosso. Tudo normal por aqui. Vamos fazer só com essas duas características por enquanto?

Vamos. Então, ok. Nós temos uma lista e dentro dessa lista nós temos um objeto.

Objeto é essa estrutura composta por conjuntos de chave e valor que a gente chama. Temos o tipo de informação que queremos passar e a informação em si. Então, descrição, coloca descrição, link da imagem, coloca link da imagem.

Cada um desses objetos é um item dessa lista. Para a gente testar legal, seria bacana se a gente tivesse uma lista com alguns desses conjuntos, alguns desses objetos. A gente deixa o Gui digitar aí o dia inteiro.

Vocês vão tomar um café, vão tomar um suco. O desenvolvedor é para isso, para ficar digitando coisas. Brincadeira, hein?

Não. Dá para ter um caminho melhor. Estamos falando do Gemini desde o começo.

E essa é uma funcionalidade que eu uso muito no meu dia a dia, que é de eu precisar fazer um mock, um objeto falso para eu consumir em algum lugar, eu não fico digitando não, só peço para a IA fazer para mim. Vamos levar esse código lá para o Gemini? Vamos.

Eu poderia selecionar todo esse trecho onde estamos gerando os objetos, dar "Ctrl+C" e ir lá no Gemini, ou eu posso fazer isso aqui, pessoal, tirar um print exatamente do trecho de código que eu quero e pedir para que através desse print ele analise o código. Pressionar "Ctrl+V" aqui no Gemini. Vai colar o print?

Colou o print. Caramba! Vou escrever e vou falar assim: baseado na imagem abaixo, crie mais cinco objetos JavaScript.

Vamos ver, eu vou torcer aqui. Olha, ele pegou, vai entender ali o print. Criando mais objetos JavaScript com base no exemplo.

Ele dá uma explicação sobre o que é cada um deles, tanto a descrição como a imagem. E olha aqui. Gato fazendo ioga.

Gatinho dormindo. Adorei já. Criou até mais do que eu imaginava.

Exatamente. Vou copiar todo esse conteúdo. Ele fala sobre tomar alguns cuidados.

Sim, e olha, o Gemini ajudou a gente numa coisa bacana. Ele está ajudando a explicar o que é objeto. Cada objeto é delimitado por chaves, as propriedades são separadas por vírgula, cada propriedade é um par chave valor.

Tudo que falamos anteriormente. Se você depois esquecer, quiser perguntar, o Gemini vai te ajudar a lembrar. Porque foi basicamente o que explicamos sobre objetos.

E fizemos tudo isso para termos no nosso back-end dados para consumir e devolver por uma rota. O que vamos fazer agora? Vamos levar essa estrutura do Gemini para o array que criamos no JavaScript.

Pode dar um "Ctrl+V". E vamos começar a escrever uma rota. Uma rota para devolver dados que venham desse objeto.

Eu vou fazer um pequeno ajuste. Vou usar para todas as imagens, como estamos em fase de desenvolvimento, não precisa ser uma imagem real, no link da imagem eu vou usar sempre a mesma imagem. Assim a gente garante que vai ter o mesmo resultado para todas.

Sem problema algum. Então, temos ali uma estrutura com seis elementos agora. A primeira que a gente tinha, mais as cinco geradas no Gemini.

E agora ficou legal. Então, temos a mesma imagem gerada. Que no futuro vamos realizar o upload de imagens de fato.

Que vamos querer manter nossa página do Instabytes. Então, beleza. Pessoal, agora é o seguinte.

Tenho os dados aqui. Como chama quando os dados estão na aplicação, mas não estão no banco de dados? Eles são locais.

A gente está mockando eles. "Mock" é um nome muito comum. É um nome chique.

Estamos fingindo que aquele dado vem de um lugar onde ele não vem, mas não é pra enganar ninguém. É só para facilitar o fluxo de desenvolvimento. A gente está testando com um array em memória.

Aí foi chique demais. Aí é outro nível. Em memória também porque se subir o nosso servidor de novo, ele perde um pouco a memória e a gente perde essas alterações.

Mas vamos lá. Acho que o próximo desafio, talvez no lugar desse send voltar isso, é de alguma forma a gente executar aquilo. Trazer a nossa lista.

Você já teve uma abordagem muito correta. Porque você está indo numa rota que já está pronta e vamos repetir essa mesma estrutura quase sempre. Vamos ter o app.

get para dizer que criaremos uma rota usando esse método. Vamos ter o caminho da rota, que por enquanto era a "/api" e agora vamos pensar se esse é o melhor nome. Toda essa estrutura vai se repetir com frequência.

Então podemos adaptar no código. O que vocês sugerem de mudança? Lembra quando a gente comentou sobre JSON lá atrás?

Objeto JSON. Vamos voltar um pouco nesse assunto. Quando a gente manda e recebe dados nessa comunicação HTTP que a gente conversou, os dados só conseguem trafegar como texto.

Então texto vai, texto volta. Mas tem um problema. Texto é um monte de caracteres.

Então se esse array, se essa lista de objetos for um textão, não conseguimos acessar cada um desses objetos e pegar a informação dentro deles. O JavaScript tem que reconhecer como um objeto, que é diferente de uma sequência de caracteres. Para conseguir fazer isso, temos que adicionar uma rota no nosso Express, para o Express conseguir parcear, conseguir converter o texto em JSON.

Então no nosso server mesmo, vamos adicionar uma linha. Depois do app. Isso.

Depois do app express, vamos adicionar app. use, abre parênteses, express de novo, sem aspas, express. json.

Abre e fecha parênteses. Então você está falando assim, o json que é uma forma para transitar texto, muito usado por diferentes linguagens de programação, você está falando assim: express, servidor, você vai usar json. Vai devolver json para as pessoas.

Então tudo que você reconhecer, que dê para transformar no json, que tiver cara disso, é o que você vai fazer. Estamos indicando que a nossa aplicação usa essa funcionalidade de converter essa estrutura em um json. E vamos dar um ponto e vírgula no final dessa linha.

Beleza. Agora o express está pronto para receber isso que vem em texto e transformar em json de novo para a gente usar. Vamos na nossa rota.

Então isso que o André estava falando sobre "/api". Podemos trocar de "/api" para "/posts"? Porque temos alguns padrões que a gente utiliza quando cria essas rotas.

Então esse é o padrão. Estamos falando de posts da nossa aplicação. E toda vez que bater em /post, sabe que estamos falando, está se tratando desse recurso de posts.

Beleza. Mudamos. Vamos receber a requisição e resposta.

Ainda vamos devolver um status 200, que é o status de OK. Mas agora em vez de send, temos que avisar ponto json. No lugar do send é json.

E aí o que vamos passar dentro de json? O nosso array posts. Que é o posts ali em cima.

Agora ponto json, o Express sabe que ele tem que tentar pegar o que ele vai receber nessa resposta, que vai estar no formato de string, um textão gigante, e converter para um formato que o JavaScript consegue trabalhar. A partir daí, conseguimos ir lá no nosso servidor e subir o nosso servidor de novo. Nossa!

Ficou incrível isso aqui. Note que por estar adaptando uma rota que a gente já tinha antes, você só escreveu uma linha. Os posts você pegou lá do Gemini e escreveu uma linha para mandar o Express usar essa funcionalidade e converter para JSON.

Claro que a gente falando, codando e explicando, pode parecer que é muito trabalho, mas estamos tendo um trabalho mínimo para construir algo grande. Vamos subir esse servidor aí. Vamos lá.

Vamos fazer o seguinte? Node. .

. Vamos dar uma melhorada aqui. Node.

. . Antes de server, você vai adicionar dois hífens.

Dois hífens. Watch. W-A-T-C-H.

Isso. Watch de "observar". Espaço server.

js. Vamos ver o que acontece. Servidor está escutando!

Vamos no navegador que vamos bater agora na rota localhost:3000/posts. Vou fazer um teste. Se eu acessar o API agora.

Ele deu aqui um. . .

Cannot get. Não existe um get para API. Exato.

Não consegue fazer uma requisição do tipo get. Vamos guardar essa expressão. Provavelmente voltaria outro status code caso eu queira tratar isso.

Vamos acessar o /posts. E já está com aquela cara do nosso Instabytes. E estamos criando já, Gui, uma API.

Estamos falando muito dessa palavra "API". O que estamos criando? Nós estamos criando uma interface.

Toda vez quefalamos de interface, estamos falando de algo que está no meio, entre outras duas, que está interfaceando. Por exemplo, a minha caneca maravilhosa está interfaceando a minha água. Se ela não estivesse aqui, eu não ia conseguir usar.

Agora que eu bebi, a nossa solução está interfaceando o quê? Os dados estão de um lado e o front está de outro. Quando a gente bate nessa rota, nós devolvemos dados.

Por isso que já estamos começando a criar uma API. Tem outra coisa que quero chamar a atenção. A Ju sugeriu a gente criar essa rota com o nome de posts.

E esse nome não só está no plural, como de fato o que volta para a gente são todos os posts que estavam dentro daquele array. Será que é sempre isso que vamos querer fazer na solução? Será que toda vez que a gente entrar no Instabytes, vamos querer ver todas as fotos disponíveis?

É óbvio que não. Não é isso que vamos querer fazer. Tem hora que vamos querer ver só uma foto.

Que tal se a gente criar outra rota para retornar só um post, uma foto das que tem na nossa página? Pensando dessa forma, de algum jeito, vamos precisar indicar nas chaves que temos aqui, cada objeto. .

. Esse aqui é o objeto. .

. Vou chutar aqui o 1. Agora eu quero ver só o objeto 2.

Não tem aquela ideia que quando a gente clica e aparece de fato a imagem lá no Instabytes? É isso que queremos fazer. Para deixar claro todo esse passo, qual que é a ideia?

Estamos aqui simulando um ambiente real. Esses dados que estão aqui que criamos como mockados, eles provavelmente vão ficar em um banco de dados e de repente. .

. Posso dar o exemplo de vocês? Claro.

A Ju fala assim: "eu preciso de todos os posts" Aí a Ju vai passar o celular pra você, vai passar o JSON. Vamos supor que o André é o back-end. A Ju é o front-end.

A Ju pede. . .

André, eu preciso de todos os posts, que é o endpoint que está ali em cima. Todos? Espera aí.

Vou olhar aqui para o lado, pegar todos os posts que eu achar, eu vou montar em um formato JSON. E minha senhora, seus posts estão aqui. Muito obrigada, senhor.

Aí a Ju pega esses posts e cria aquela página que a gente vê. Exatamente. Gente, presta bastante atenção.

Isso não acontece só nesse sistema que estamos utilizando. Todas as aplicações, o Google, a Alura, o Spotify, o Airbnb, todos eles, utilizam dessa arquitetura, dessa solução de cliente-servidor. Hoje o nosso objetivo é o servidor.

Não estamos com ênfase em desenvolver a página de HTML, CSS. Deixa isso para a imersão de Front, a imersão React. Mas é por isso que eu quero tanto criar essa rota com um post só.

Já que estamos focando só no servidor, eu preciso dar potencialidade para quem for fazer o front usar as informações que precisa. Mas aí agora tem um ponto. Que a Ju levantou e é importante.

A Ju não precisa de todos os posts. Então, se eu acesso a minha aplicação, eu consigo visualizar que eu tenho um endpoint para todos os posts. Aqui, get posts.

Devolve todos os posts que você tem no formato JSON. Mudou. A Ju vai precisar agora para post por post.

Para visualizar só o primeiro post. Para visualizar só o segundo. De novo, ela vai precisar perguntar.

Podemos ter mais de um endpoint, mais de um endereço, para servir coisas diferentes? Você não só pode, como deve. Quando você vai comprar um lanche na sua lanchonete de fast food favorita, se você quer um hambúrguer, você vai no caixa do hambúrguer.

Se você quer um milkshake, vai lá na cabine do milkshake. Imagina, você vai na lanchonete e fala: "Me vê todos os lanches, mas eu só quero um. " Você não vai comer todos os lanches.

Não consegue. E você levantou um ponto, Ju, que foi aquela parte que o Gui falou: "Nossa, mas como vou saber qual objeto é qual? " Provavelmente, vamos ter que alterar essa estrutura.

Sim. Eu não previ na hora, quis fazer uma coisa muito simples e esqueci que toda vez que criamos um registro numa base de dados, esse registro precisa, de alguma forma, ser identificado. Ele precisa de um identificador.

Assim como temos o CPF de identificador, cada registro tem que ter o seu próprio. Mas podemos pedir isso para o Gemini. - Pode.

- Posso pedir? Pode. Fala assim: "Gemini, esquecemos um detalhe no nosso array de posts".

Eu vou selecionar toda a constante de posts, "Ctrl+C", voltar no Gemini, vou dar um "Ctrl+V" e falar para ele assim: Adicione um ID em cada objeto. Pode ser? Quando usamos ID, é o nome mais padrão possível para identificador.

Olhou a estrutura, leu "ID", você já sabe, a pessoa quer conseguir identificar cada elemento nessa estrutura. Vou dar um "Enter" e vamos ver o que ele vai gerar. Adicionando um ID para cada objeto no array de posts.

Ele deu um problema, que temos um array, mas queremos conseguir recuperar essas informações de posts de forma individual. Ele criou um "let id", mas fez uma estrutura um pouco diferente. Ele criou um código para fazermos isso.

Aqui tem um exemplo um pouco melhor. Assim, já está a estrutura final. O que o Gemini fez foi criar um código que iterasse pelo nosso array e adicionasse em cada um, o ID.

É uma solução possível. Vamos pelo caminho mais simples, ao invés de fazer um código que percorra o array adicionando, nós mesmos vamos adicionar um campo a mais em cada um. Ele mostrou, vou pegar dessa aba de resultado, caso você tenha um prompt parecido com o meu, o que importa para mim são esses dois primeiros.

- Acho que os outros podemos… - Podemos copiar e colar. Copiar e colar. Vou fazer o seguinte: vou pegar toda essa seleção aqui.

Por isso, é bom não se preocupar com esses dados, principalmente na fase de desenvolvimento. Vamos colocar aqui, para ficar indentado corretamente. Temos o ID 1, o ID 2.

- Pode ser só mais um? - Pode. Colocamos um ID 3.

Vou mudar a descrição. Foto teste, um gato fazendo ioga, um gato fazendo panqueca. É importante a gente ter isso na nossa ferramenta.

E ID 3, os identificadores são únicos. - Teríamos um problema. - Exato.

Ou ele devolveria os dois. Não sei qual seria o comportamento. Só fizemos isso porque queremos arrumar um jeito de retornar um post só.

Foi só por isso que fizemos essa alteração. E aí, Ju, poderíamos só dar "Ctrl+C", "Ctrl+V" na nossa rota e fazer um esquema mais simples? Dá, porque também estamos dentro de posts, pense que ainda estamos buscando recursos de post.

Como passamos para o Express organizar uma rota de forma que possamos passar a informação? Porque posts são meio fixo. Mas o ID que queremos não é fixo.

Podemos querer o ID 1, ID 2, ID 3. Gui, copia esse app. get, que vamos ver como o Express faz isso para nós.

Legal. Dei um "Ctrl+V" aqui embaixo. Beleza.

Se já tiver observado as URLs que usa para navegar pela internet, você pode ter visto essa estrutura que vamos fazer agora. Vamos lá em "/posts", adicionar uma barra dentro da string, e adicionar ":id". O que é o ":"?

É como dizemos para o Express que essa informação, quando formos no navegador, será substituída por um dado variável. Vamos substituir no navegador por 1, por 2, por 3. Como se estivéssemos identificando uma variável pelo nome ID.

Beleza? Então, fizemos isso e nossa rota já está pronta. O que podemos fazer aqui, vamos tirar isso de dentro do get?

Pode criar uma função em cima dos apps. get, vamos criar uma função para fazer esse trabalho de ir no array… E pegar exatamente o ID que queremos. Exato, vamos criar uma function que podemos chamar de buscaPost.

Posso colocar buscarPostPorId? Pode. Beleza.

O que precisamos passar para essa função? O número do ID que queremos buscar. Então, colocamos aí "id".

Beleza. Maiúscula ou minúscula, você escolhe. Dentro da função, agora, pense, temos um array.

Como fazemos para entrar dentro de um array e pegar um dado? Aqui não tem nada a ver com Express, é puro JavaScript, porque é um array, uma estrutura do JavaScript, é uma variável. O que vamos fazer?

Vamos retornar, "return". Vamos na variável posts, onde está a nossa lista. Ponto.

Vamos usar um método interno do JavaScript para encontrar um dado pelo índice, que é findIndex. findIndex com I maiúsculo, está certo. Esse método tem dentro dele outra função.

Abrimos, fechamos. Agora, vamos abrir uma arrow function dentro do parâmetro. Parênteses também?

Parênteses também, para ficar organizado. Dentro desses parênteses que criamos na arrow function, vamos escrever posts ali na linha de cima. Que é como a função vai receber o dado que vem de fora dela.

É no plural ou no singular? Post, porque é no singular. Porque ele vai selecionar um post.

Vou falar assim, da minha lista de posts, encontra o index, aí ele vai pegar post por post para ver se é aquele index. Exato. Dentro dessa função, vamos dar um return porque queremos tirar de dentro da função, post.

id === Number, com N maiúsculo, e, dentro do Number, que é uma função, um construtor, id. Olha só, o que estamos passando aqui? Essa função está recebendo um número de id, pode ser 1, 2 ou 3, está entrando… isso na linha 20.

Depois ela entra dentro do array de posts, usa um método do JavaScript para entrar em array, e esse método vai entrar em cada um dos objetos que estão dentro do array. Nós temos três. Então, no primeiro objeto, vai dentro de id.

Então, vai ver se o id bate com o que passamos para a função, por parâmetro, lá na linha 20. Bateu? E estamos fazendo uma coisa simples.

Isso é lógica de programação com JavaScript, nada de novidade. Buscar um dado dentro de uma estrutura, só isso. É uma coisa bem do dia a dia.

Mas sabe que é legal você falar isso, Gui? Às vezes, imaginamos que o que acontece no dia a dia é sempre complexo, que você vai construir uma montanha, e não é. É usar os recursos simples que tem para resolver um problema.

Recursos simples que temos: O array. Problema: Preciso retornar um. Solução: Criar uma função que busca pelo índice quem tem aquele id.

Sim. E para garantir que é o número, já pedi por antecipação: converte esse id para número, porque caso chegue um string, vai converter para número. Se chegar como um número, não acontece nada.

- Legal. - Beleza? Agora, essa função não está sendo executada ainda.

Ela só foi declarada. Vamos declarar essa função dentro do nosso app. get.

Então, antes de retornar a resposta, vamos preparar essa resposta. Vamos adicionar na linha anterior ao res. status.

Isso, na linha 27. const index igual à nossa função buscaPostPorId. Agora, vamos executar essa função.

Passando para ela, e agora? Ela está esperando receber um número. De onde vai vir esse número agora?

Provavelmente, lá do endpoint mesmo. Isso. Mas vai bater no endpoint?

Como passamos isso? Da seguinte forma: rec. params P-A-R-A-M-S.

. id Olha que interessante! A requisição tem o valor de id.

- Exato. - Você pegou bem. E veja que rec é um dos parâmetros que já estamos recebendo.

Inicialmente, não tínhamos usado. Ele estava até com outra cor. Agora, estamos usando.

Porque dentro de toda a requisição, ela tem um objeto chamado params, que são os parâmetros da requisição. E dentro tem id. Por que tem id?

Porque id, na linha 26, é como identificamos esse parâmetro. Se colocássemos outra coisa, gui, api, post aí seria rec. params.

post. Estamos identificando como id, o padrão, para bater o olho e saber que isso é um id. E a partir daí, ele identifica e guarda dentro.

E conseguimos recuperar esse dado de dentro da requisição. E dá para a galera reparar no código que a função que demos "Ctrl+C", "Ctrl+V" ficou muito parecida com a de cima. A estrutura da rota é sempre muito parecida.

O que mudou é que estamos chamando uma função para nos ajudar a retornar um único dado daquele array. Vamos testar batendo nessa rota de id? A última coisa que temos que fazer antes de testar é alterar.

Porque agora não queremos mais… Retornaria post? Retornaria porque ia encontrar a variável, mas agora queremos retornar index. Como faço?

Eu vou colocar, do lado dos posts, que continua sendo o meu objeto. Na verdade, se dermos o buscaPost, ele vai retornar o objeto que foi encontrado. Então, o index já deve ser a resposta final.

Ou eu tinha pensado em ser o posts no index. Exatamente. É verdade, é verdade.

Então, só recapitulando. O posts é o nosso array. Tem um montão de posts lá dentro.

Quando colocamos os colchetes e passamos a variável index lá dentro, estamos passando a posição do post que queremos retornar. Como a gente descobriu essa posição? Com aquela função que acabamos de escrever.

Que curioso. Vou ler a função de trás para frente até chegarmos nesse post. Esse primeiro return post.

id === Number(id) vai falar assim: Existe alguém que tem o ID1 igual ao ID1? Existe. Vai ser um verdadeiro.

Então, ele vai devolver. De toda a sua base de posts, que são essas aqui em cima, um, dois e três, tem um que tem o valor 2, por exemplo. O que acontece?

Quando formos pedir para exibir o status code, anteriormente, não tinha isso falando qual era o ID que queremos retornar. Só tinha assim: Devolve todos os posts. Agora, não.

Agora, quero que você devolva, da lista de posts, só o que tenha esse index. - Perfeito. - Beleza?

Podemos testar isso. Não precisa alterar mais o servidor ou precisa? Exato.

O que acontece? Colocamos aquele --watch. Não precisa mais quebrar e subir o servidor toda vez que alteramos alguma coisa.

Podemos continuar, toda vez que salvarmos o nosso arquivo, o servidor reinicia automaticamente com as alterações. Legal. Sempre que eu salvo, ele pisca.

"Servidor escutando…". Muito da hora isso! Então, voltando.

Acessando aqui posts. Vou testar aqui o post de novo. - Parece que está tudo certo.

- Continua funcionando. Devolveu todos. Agora só temos 3.

E se eu coloco no posts "/2", é o gato fazendo ioga. Você prefere o gato fazendo ioga ou o gato fazendo panqueca? Eu quero testar os dois para ver se não tem alguma malandragem aí.

Beleza. Vamos lá. 1, 2, 3.

ID 2. Gato fazendo ioga. Temos o mesmo resultado.

Vou até dar um zoom. E se eu coloco ID 3, aparece aqui. Gato fazendo panqueca.

- Olha, Gui. - Que nem se vê todo dia. Para mim, isso é muito emocionante.

Não o gato fazendo panqueca, mas termos conseguido construir isso. Dependendo do que colocamos na nossa rota e do parâmetro, do número que colocamos ali, estamos conseguindo chegar no post certo. É exatamente assim que uma API funciona.

Recebemos uma requisição, faz algo no back-end e envolve isso em forma de JSON para quem precisa consumir. Só para eu conseguir entender de uma forma mais clara. Qual que é a grande vantagem de eu conseguir acessar um post e não devolver todos toda hora?

Olha, quando você está na sua página e quer, por exemplo, mandar uma foto para alguém e dizer: "acabei de fazer um post do gato panqueca. Curta lá". E você manda aquilo para a pessoa, vem um link enorme, não é?

E por trás da página fazendo aquilo tem uma requisição para dizer: "olha, nessa página, que é igual para todo mundo, que foto que eu coloco? Deixa eu fazer uma busca por uma foto única. É essa aqui".

Puxei nesse campo que é a descrição, que é igual para todo mundo. Nela, vou puxar a descrição associada a essa foto única. Se expandirmos isso para outros exemplos, no e-commerce, por exemplo, quando o e-commerce mostra todos os produtos?

Quando você entra na categoria. Cadeiras gamer. Ele mostra um monte.

Mas eu quero acessar essa cadeira gamer. Dou um clique e ele vai montar uma página só daquela cadeira. - Vou ser polêmico agora.

Posso? - Pode. Eu não tenho cadeira gamer.

Você acredita? Eu também não tenho. Não tenho.

A cadeira é normal. Você tem? Vamos para o próximo assunto da imersão.

Esse é muito polêmico. Eu vou tolerar esse bullying comigo. Pegar algo por ID, pelo identificador único, também é útil quando você quer atualizar.

Você quer atualizar seu endereço, sua foto, atualizar um post. Como ele sabe que é aquele post? Pelo identificador.

Posso dar um exemplo da vida real? Vamos supor a seguinte situação: Uma pessoa começa um relacionamento com outra pessoa. Comum.

Temos amigos, amigas que começam o relacionamento. Terminou o relacionamento. Na base de dados, nunca apagamos as fotos.

Aí vão ficar as fotos para sempre marcadas, mas aquilo machuca a pessoa. - Eu estou ficando triste. - Exatamente!

Onde vai chegar essa história? A grande vantagem da gente conseguir deletar um post, igual a Ju falou, não é só para que a pessoa não fique emocionalmente triste. Vendo as fotos de uma pessoa que talvez amava, que talvez não gostasse tanto dela.

A pessoa vai conseguir editar. A pessoa vai conseguir atualizar. Vamos pensar isso no cenário real, na engenharia, de uma maneira aberta?

Então, quando eu abro uma conta num determinado banco, existe um identificador meu. Existem detalhes e informações que eu posso alterar da minha conta. O que estamos fazendo inspirados numa rede social é exatamente isso.

Estamos tornando possível talvez a edição, a atualização ou até eu remover um determinado post que eu fiz lá através desses IDs. Por isso que isso aqui é importante. Essa linha é importante.

Tudo que você falou é verdade, mas tem gente chorando até agora com o exemplo que você começou do ex-namorado. Eu peço desculpa. Foi só um exemplo.

Conseguimos deletar nas redes sociais. Consegue. Inclusive na nossa.

Vamos chegar lá. Sim, mas vamos fazer o seguinte: Agora que já entendemos como funciona você pedir dados numa requisição, voltar numa resposta, etc. No dia a dia, não trabalhamos com um array fixo.

Mesmo porque, quando reiniciamos o servidor, qualquer alteração feita, por exemplo, deletado o ID1, teria voltado. Porque esse array está fixo aí. O que fazemos agora?

Agora acho que é a hora de dar o próximo passo. Podemos começar a pensar em banco de dados, e é claro que não vamos conseguir fazer uma imersão de banco de dados agora durante a aula 2, mas começamos a beliscar um pouco esse assunto. Primeiro, precisamos de uma estrutura para guardar dados.

Como Ju falou, não pode ser array porque a memória é apagada depois. Mas se você for pesquisar bancos de dados existentes, existem vários, existem muitos. A área de banco de dados, por si só, é super ampla e conta com profissionais especializados.

Então, o que vamos fazer? Para a nossa solução, nós escolhemos um banco de dados que entendemos que vai precisar de menos adaptações para a lógica do nosso sistema funcionar. É um banco baseado em documentos, não vamos entrar nessa seara do que é cada tipo de banco, mas o mais importante é: vamos usar um banco chamado MongoDB.

Esse nome é bom de colocar no currículo, a galera gosta, não é? Gosta. O MongoDB é um tipo de banco de objetos, não vamos entrar muito nessa seara, porém, ele é muito usado em API.

Ele é um dos bancos mais usados em desenvolvimento web back-end, tem algumas características próprias, porém, o que importa para nós é que nós vamos utilizar esse tipo de banco específico na nuvem. Nossa! Porque bancos de dados… criamos um servidor, criamos um tipo específico de servidor, existem vários tipos de servidor, o nosso é o mais querido, é o servidor de aplicação, onde guardamos nossos sistemas, as lógicas dos nossos sistemas.

Existem servidores de bancos de dados, existem servidores de arquivo estático, existem servidores de e-mail, existem muitos tipos. Mas tivemos um pouco de trabalho para subir o nosso, não muito, mas vamos querer fazer isso de novo? Nem pensar!

Vamos utilizar um recurso de nuvem. O banco é o Mongo e vamos acessar o recurso de nuvem do Mongo para subir o nosso banco, que será muito mais simples. Vamos, no navegador, procurar pelo site Mongo, Atlas, A-T-L-A-S.

Ok, é o primeiro mesmo, Mongo Atlas. O Atlas é o nome desse serviço que oferece um banco de dados do Mongo na nuvem, ok? Criar uma conta é rápido, você pode criar com a sua conta do Google.

Eu vou fazer isso e daqui a pouco a gente volta. Maravilha! Agora que eu já estou logado, ele fala para eu aceitar as políticas de privacidade.

Como sempre, aceitamos. Nós lemos, enquanto estávamos… Enquanto você digitava seus dados. Nós lemos.

Mentira. Aceitamos aqui, demos um "Submit". Vamos esperar.

- Ok. - Seja bem-vindo. Você está pronto para deployar, para publicar uma database na cloud.

E agora, Ju, o que eu faço? Tem alguns dados. Você pode dizer que é um estudante, "learning MongoDB", queremos aprender.

Vamos dizer que somos iniciantes. Nunca desenvolvi antes. Ok.

Qual linguagem vamos usar? Vai ser no JavaScript/Node. js.

E qual tipo de dados. Pode ser catálogo. É legal contar para a galera que esses dados que estamos preenchendo não vão influenciar na nossa aplicação.

É só para a equipe do Mongo Atlas saber quem é o tipo de usuário que eles estão tendo. A sua aplicação vai incluir… Não. Não vai incluir nada disso.

Nada. "Not sure or no". No último lá.

A nossa aplicação não inclui absolutamente nada. Vamos lá, que eu dei o "Finish" aqui. Agora vamos… temos três opções de… Banco de dados é uma coisa que custa dinheiro.

Especialmente na nuvem. Mas o Atlas oferece uma opção grátis, a M0 Free. É essa que vamos selecionar.

Podemos deixar o nome do nosso cluster de "Cluster0". Vamos selecionar Google Cloud. Para o nosso banco fica hospedado na nuvem do Google.

Que da hora, hein? Podemos tirar o Preload sample dataset, que é aquela segunda opção. O que isso aqui faria?

Ele ia subir um banco de dados… Já íamos subir esse banco com alguns dados. Não, deixa quieto. Ele ia fazer baseado na pesquisa que respondemos.

Pode deixar quieto. Estamos em São Paulo. Pode deixar São Paulo, recomendado com a estrela.

Não precisa nenhuma tag. - Criar? - Criar.

Create Deployment. Fácil. Doeu?

Com meia dúzia de cliques, só. Exato. Agora, o que acontece?

Precisamos criar. Isso é muito importante. Você vai criar um usuário e uma senha para acessar o seu banco, que é o passo que está ali no 2.

E qual o nome que podemos dar? Pode ser gui, gui-lima. É o seu usuário.

Pode ser gui-user-dinossauro Pode ser imersao-panqueca. - Pode ser gui-lima. - imersao-gui-lima.

Mais importante que ser criativo na hora de criar o usuário e a senha é nós nos lembrarmos dessas credenciais. Porque estamos criando um usuário que será capaz de manipular esse banco. Exato.

Sem esse usuário guardado, não conseguimos guardar nada. Acho que o "guilima" tem que ser direto. Sem nada.

Já tem um password preenchido, você pode copiar. E é muito importante. Copie esse usuário e senha, guarda em algum local.

Eu posso ir no arquivo TXT? Pode ir no TXT, que ele não será comitado. E não tem problema porque depois que acabar a invenção, vamos destruir esse banco.

Então, todos esses dados vão para o espaço. Ele vem em sua senha. Aí você tem que escrever o "guilima".

"guilima" tudo junto. - Beleza, salvou. - Vai que eu esqueço o nome.

Salvou, tudo certo. Vamos voltar para o Mongo, terminar a configuração. Create database user, botão verde lá embaixo.

Criou, perfeito. Vamos para o próximo, escolher um método de conexão. Existem algumas formas de um banco se conectar a uma API, a uma aplicação.

Vamos escolher a primeira, Drvers. E podemos até explorar mais na próxima aula. Aqui o foco é só criar.

- Vamos escolher Drvers. - Olha aí. Já deu uma coisa que conhecemos.

"npm install" já sabemos o que é. Já sabemos que, no futuro, vamos ter que instalar essa dependência no nosso, mas não precisa ser exatamente agora. Ok.

Que mais? Instalou o Drver. E agora ele está pensando um pouco.

Ele está provisionando o nosso cluster e provisionando o espaço na cloud do Google, onde vai morar o banco de dados. Vamos esperar um pouco. Se demorar, voltamos daqui a pouco.

E sabemos que ele provisionou, porque vai aparecer um texto embaixo que chamamos de string de conexão. Esse texto não é secreto, nem nada disso, mas vamos precisar guardá-lo para usar depois. Posso colocar no grupo da família?

Pode colocar. Esse não tem problema, porque esse é público, conseguimos consultar na internet. Mais ou menos.

Tem um espaço de senha que vamos construir daqui a pouco. Vou colocá-lo no nosso chave… "chave-api. txt" E depois debatemos o melhor lugar.

Ok. Já criamos uma string de conexão, parece um endereço HTTP, mas não é, o princípio será parecido. Criamos o nosso banco, já temos uma forma de conectar nosso banco ao API.

Pelo amor de Deus. Olha só, a próxima aula, o que vamos fazer? Esses dados que estamos vendo, posts, vamos armazenar tudo lá no MongoDB, no cloud.

Não só isso: vamos armazenar no MongoDB e trazer de volta. A próxima aula está incrível. Se você chegou até aqui, você está finalizando a segunda aula da Imersão Dev.

Lembrando que, para que você tenha acesso ao seu certificado, é necessário que você assista as cinco aulas da Imersão. E hoje nós estamos fechando a aula 2 de uma forma muito incrível. Na próxima aula, amanhã, vamos, de fato, conectar a aplicação com o banco de dados, trazer os dados de lá, realizar algumas operações a mais.

Vai ficar simplesmente sensacional. Te espero lá.