Latest / Entre Chaves / Snippet #12 Dicas essenciais para organização de APIs no back-end

Transcript

Snippet #12 Dicas essenciais para organização de APIs no back-end · Entre Chaves

• 0:09
  Olá pessoal, eu sou o Arthur bom tempo desenvolvedor de software
• 0:12
  full Stack aqui na DCI digital e hoje eu vim conversar um pouco
• 0:16
  com você sobre desenvolvimento de APIs.
• 0:19
  Muito provavelmente que você já trabalhou com desenvolvimento
• 0:21
  web já pelos teus sites, muito provavelmente você geralmente
• 0:25
  fica com o servidor. Que é a parte polêmica com o
• 0:27
  banco de dados, né? E que a gente integra confronte
• 0:30
  aí da aplicação. E é sobre isso que eu vim
• 0:31
  conversar um pouco com vocês hoje.
• 0:33
  Muito provavelmente você deve saber desenvolver alguma PI.
• 0:36
  Já deve ter feito, feito seus primeiros servidores mexendo um
• 0:39
  pouco com isso. Mas há uma grande diferença
• 0:41
  entre você saber de desenvolver uma PI está funcionando e entre
• 0:44
  você saber arquiteturar essa API.
• 0:45
  Nós, como desenvolvedores de software, nós precisamos saber
• 0:48
  organizar muito bem elas, tanto para poder desenvolver.
• 0:50
  Fica performático, mas também para poder ficar melhor na hora
• 0:53
  de fazer os testes, na hora que outro desenvolvedor for mexer
• 0:56
  nessa API, poder mexer tranquilamente, né?
• 0:59
  Sem ter problemas. E também quando der algum bug,
• 1:01
  algum problema, a gente poder corrigir esse erro.
• 1:04
  No ponto onde a gente precisa mexer, tem que ter que estar
• 1:07
  olhando o código inteiro para isso, que tem as aquicultura de
• 1:09
  software. A gente pode se triturar para
• 1:11
  poder deixar o código bem distribuído, bem organizado e
• 1:14
  com essa organização. Qualquer um desses casos que eu
• 1:16
  comentei da gente, de testar outra pessoa que tem que
• 1:19
  desenvolver uma featuring ou talvez a gente tem que dar
• 1:21
  manutenção, a gente conseguir fazer isso de forma eficaz,
• 1:24
  então. Hoje vim trazer pra você daqui
• 1:26
  um pouco sobre arquitetura de camadas.
• 1:28
  Então era da das arquiteturas mais usadas aí em
• 1:30
  desenvolvimento de back end, né? Com APIE muito comumente usado,
• 1:34
  e assim eu vou mostrar aqui pra vocês um código Spring boot, né?
• 1:36
  Eu vou dar exemplos assim, mas não se empreende da tecnologia,
• 1:40
  não se empreende da arquitetura também.
• 1:41
  Vamos fixar mais aqui sobre cada responsabilidade e como é que
• 1:45
  funciona pra você poder usar no seu dia a dia, no dia a dia.
• 1:48
  Aqui na DTI eu mexo com mínimo EPI do DOT net em que.
• 1:52
  A arquitetura é um pouco diferente, mas se você entender
• 1:55
  bem como funciona, cada Canada, o que é uma controla, é uma
• 1:58
  service, você consegue fazer de forma adequada também.
• 2:01
  Quando você mexer em outra arquitetura, em outra estrutura,
• 2:04
  já pega o seu café, aí já pega o seu lanche, deita um pouco aí e
• 2:08
  vamos conversar aqui por alguns minutos, beleza?
• 2:11
  Pra isso eu tenho um fluxo que eu acho que vai facilitar
• 2:13
  bastante aqui pra gente poder aprender bem, mas lembrando, não
• 2:17
  se prende a isso então. Quando a gente vai desenvolver
• 2:20
  um API, muitas vezes a gente já pensa em criar um Ed point
• 2:24
  apenas pensa em conectar com o banco de dados ou qualquer
• 2:27
  tecnologia que a gente está usando.
• 2:28
  A gente não pensa como vai estar estruturado em nosso projeto.
• 2:31
  Mas é muito importante você pensar desde a hora que alguém
• 2:33
  acessa a sua API, é o primeiro clique, né?
• 2:35
  Pra poder usar essa sua requisição até quando ela acessa
• 2:39
  o banco de dados. A gente não quer que alguém
• 2:41
  entre com algum dado indevido no banco de dados, a gente não quer
• 2:43
  que tenha algum problema. Então tem várias camadas, várias
• 2:47
  partes que a gente precisa passar por elas antes de te
• 2:48
  salvar no banco de dados com um dado ou até mesmo antes de
• 2:51
  recuperar um dado do banco. Vamos supor que você acessou o
• 2:54
  API, seja via front end, seja via postman.
• 2:57
  De alguma forma, quando você acessa essa API, o browser, né?
• 3:01
  Oo que você está fazendo, vai fazer uma requestra, então
• 3:04
  primeiro vai ter uma. Agradecer Quest aqui pra fazer
• 3:07
  essa solicitação e a primeira camada, né?
• 3:09
  Data e que vai chegar quando a gente fala disso é a controle, a
• 3:13
  controle, basicamente ela é responsável por receber essa
• 3:15
  requisição, validar os dados iniciais, né?
• 3:18
  Saber qual que é o verbo HTTPE tudo e também vai enviar para o
• 3:22
  service pra poder fazer o processamento de todos os dados,
• 3:26
  mas antes de processar em si, vai ser ODTOODTO né?
• 3:29
  Que é o data transfection object.
• 3:30
  Ele serve pra poder pegar os dados, verificar se eles estão
• 3:33
  no formato correto pra então enviar pro servidor.
• 3:35
  Evidor é basicamente o núcleo da nossa aplicação, a nossa regra
• 3:38
  de negócio. O clube que for mais crucial vai
• 3:40
  estar aqui no nosso service. Eu peguei aqui né, no por pra
• 3:43
  nossa PIPI receitas. Aqui eu estou usando o
• 3:45
  claudinari que é pra poder fazer o piloide de imagem na nuvem,
• 3:48
  mas poderia ser qualquer servidor.
• 3:49
  Então se a gente perceber aqui nosso service vai solicitar o
• 3:53
  serviço. Claudinari, por exemplo, quando
• 3:55
  a gente também quer tratar os dados, né?
• 3:57
  A gente não quer que o usuário veja exatamente o dado do banco
• 4:00
  de dados, porque esse dado ele pode de insensível, pode ter um
• 4:03
  ID que ele é pessoal. Enfim, aí a gente não pode
• 4:07
  passar direto, então a gente precisa de um map, o map,
• 4:09
  basicamente, ele vai ao a service solicitar esse map.
• 4:13
  Ah, ele vai transformar o dado da entidade para um dit, ou ou
• 4:18
  do dit, ou para uma entidade, para que esse dado fique de
• 4:21
  forma mais segura. E também nós temos o repository,
• 4:24
  que é a parte que vai conectar em si com a nossa entidade e
• 4:28
  buscar o dado do banco de dados. No caso do Spring boot
• 4:30
  específico, a nossa repositura conecta diretamente com o banco
• 4:33
  de dados. Através do JPA então eu fiz esse
• 4:36
  esquema aqui, né? Pois você não reposito, comente,
• 4:38
  tem outra tecnologia como o DOT net através do inst framework
• 4:42
  node, através do TAP RM por exemplo, você vai ter essa intit
• 4:46
  no meio, mas em algumas outras tecnologias podem direto.
• 4:50
  Então basicamente quando a gente acertar nosso controle, vai
• 4:52
  solicitar o dado da da nossas teses de via de ti ou né?
• 4:55
  Vai validar esses dados nas teses, vão ter nossa
• 4:57
  orquestração de todos os dados, então a service vai solicitar o
• 5:00
  lado do repositório né, pra poder.
• 5:02
  Ao valor do banco de dados ou retornar ao dado do banco de
• 5:04
  dados fazer AA conversão de é via mepper, né?
• 5:07
  Do nosso DTU para a nossa enche e vai retornar para o usuário.
• 5:11
  Então se a gente ver que o serve, se também retorna.
• 5:13
  E ele tirou response para controle, né?
• 5:15
  Que é controle que recebeu esse dado, foi solicitado, vai para
• 5:19
  dar uma resposta HTTP, que aí tem os demos HTTP tem várias
• 5:22
  burocracias também e vai retornar para o cliente apenas
• 5:25
  os dados. Da forma correta.
• 5:27
  Então essa é a arquitetura básica que vocês precisam
• 5:29
  compreender muito bem cada camada dessa daqui, né?
• 5:32
  Por isso, nomear criatura de camada deve ter pena, deve ter
• 5:34
  sua responsabilidade única, não deve ter algo a mais porque
• 5:37
  verificar porque que deu um status diferente, porque que vem
• 5:40
  um verbo HTTP errado, muito provavelmente o erro vai estar
• 5:44
  na controle, que é a parte que vai criar nosso eadpoint.
• 5:47
  Vamos supor que você teve algum erro ao salvar no banco de dados
• 5:49
  do claudinari, muito provavelmente, ou vai estar no
• 5:51
  próprio servidor do claudinari ou vai estar no nosso service.
• 5:54
  Consegue perceber a importância disso?
• 5:56
  E vocês estiverem mexendo com esse QL diretamente com o
• 5:58
  entist, o repository, muito provavelmente na hora de salvar,
• 6:02
  se der algum erro no seu banco de dados, pode estar ou no
• 6:05
  repositório ou no ente. Então é muito importante a gente
• 6:08
  ter essa noção básica de como funciona, APIE, saber estruturar
• 6:11
  muito bem. Então eu vim aqui para o código
• 6:13
  para mostrar para vocês como funciona essa estrutura básica
• 6:16
  da PIA. Gente, vai começar no nosso
• 6:18
  controle. Que a nossa camadona vai criar a
• 6:20
  nossa requisição, vamos pegar, por exemplo, aqui o nosso post,
• 6:23
  né? A gente vai definir o nosso
• 6:24
  verbo, que é o post, né? No caso, aqui vai ser o primeiro
• 6:27
  de imagens. A gente está mostrando um
• 6:28
  formato de dado, a gente vai fazer uma validação básica aqui
• 6:31
  e se a gente perceber aqui embaixo, vai chamar o nosso
• 6:34
  servidor no método create. Então, se a gente vier para
• 6:38
  nosso serviços aqui embaixo, a gente vai ter o nosso método
• 6:41
  create. Aquele basicamente vai verificar
• 6:43
  se tem 11 imagem, verificar se Ela Foi preenchida, né, se foi.
• 6:48
  Vai criar um objeto aqui, né? No caso do Java, e com esse
• 6:52
  objeto a gente vai chamar o nosso repositório.
• 6:54
  Então, como eu falei, vai dar controle para o server, dos
• 6:57
  server para o repositor, essa estrutura básica.
• 7:00
  E lembrando também que a gente tem o nosso mepper aqui para
• 7:02
  poder reservar o formato que vai exibir.
• 7:06
  No caso, vai pegar o novo DT ou e vai enviar para uma gente para
• 7:09
  poder ter mandado. Para o nosso repositório e no
• 7:12
  nosso repositório. Nesse caso aqui a gente está com
• 7:14
  Spring boot, então sempre fica muito.
• 7:17
  Mas basicamente vão ter verbos aqui, né?
• 7:18
  Vão ter métodos e colegas estão com o nosso banco de dados, por
• 7:22
  exemplo. É buscar pelo título, que foi o
• 7:25
  que eu fiz aqui. Então a gente consegue ver que
• 7:28
  vai ter cada um deles, vai ter uma responsabilidade.
• 7:32
  Que tendo muito bem cumprida, facilita o desenvolvimento da
• 7:36
  nossa API e posteriormente da manutenção de forma muito mais
• 7:40
  estruturada e mexendo apenas em determinados pontos, porque a
• 7:44
  aplicação já está muito mais bem organizada em camadas.
• 7:47
  Agora vou deixar aqui também o nosso GitHub, caso você queira
• 7:50
  dar uma estudada nesse código e também entender um pouco melhor
• 7:53
  o diagrama. Então, caso você queira o código
• 7:55
  fonte, pesquise por Arthur. Bom tempo deve barra heatsiple,
• 7:58
  volt e π. E vai ser com o nosso código
• 8:01
  completo dessa apê de receitas. É com tutorial explicando como
• 8:04
  rodar. E eu espero ter contribuído um
• 8:06
  pouco com o seu ensino aí sobre apê e desenvolvimento backend.
• 8:09
  Espero que você tenha tido um pouco um gosto de como funciona
• 8:13
  uma apê e porque é muito importante você dividi la em
• 8:15
  responsabilidade e camada, vejo vocês em uma próxima
• 8:18
  oportunidade, até mais.