DEV Community

Cover image for Arquitetura para aplicações REST com express (node.js) #01: Cada escolha uma renúncia
Afonso Pacifer
Afonso Pacifer

Posted on

Arquitetura para aplicações REST com express (node.js) #01: Cada escolha uma renúncia

Iniciar um projeto de API REST usando Node.js geralmente é algo rápido e relativamente fácil. Você escolhe um framework, lê um artigo e mete bronca no hello world. Simples assim 👍.

Feliz

Porém, algo não muito difundido no mundo "javascripteiro" do Node.js é que, ao escolher um framework para trabalhar você meio que escolhe automaticamente uma filosofia de arquitetura para seguir. Mesmo que, no caso do Express, a escolha seja não ter arquitetura 👀.

É complicado entender a necessidade de algo que não temos, nunca vimos ou ouvimos falar. Para termos o que comparar, vou apresentar um conceito que é um dos pilares do famoso e super desenvolvido Ruby on Rails.

Convenção sobre configuração

Por definição:

Convenção sobre configuração ou programação por convenção (do inglês Convention over configuration - CoC) é um modelo de desenvolvimento de software que busca diminuir o número de decisões que os desenvolvedores precisam tomar. Visa ganhar simplicidade sem perder flexibilidade.

Fonte: wikipedia

Aplicação do conceito no mundo Rails

Diferente do processo padrão (que você aprende em tutoriais pela internet a fora), para iniciar uma API usando Express, ao iniciar um projeto usando Ruby on Rails você roda a ferramenta de linha de comando e faz scaffolding da base do projeto. Onde já temos toda a estrutura de pastas, padrões de nomenclatura e comunicação entre módulos pré definidos pelo framework:

$ rails new projeto
Enter fullscreen mode Exit fullscreen mode

OBS: O exemplo abaixo é um resumo simplificado da estrutura do Rails. Para uma explicação melhor consulte a documentação oficial.

.
├── app/
|  ├-- assets/
|  ├── controllers/
|  ├── helpers/
|  ├── mailers/
|  ├── models/
|  └── views/
├── bin/
├── config/
├── db/
├── public/
├── test/
├── tmp/
├── vendor/
└── assets/
Enter fullscreen mode Exit fullscreen mode

Isso traz algumas vantagens e desvantagens:

Vantagens

Como descrito na definição do conceito, ao ter uma arquitetura pré definida, o desenvolvedor não gasta seu tempo e energia decidindo coisas que não influenciam nas regras de negócio do projeto. Ou seja... Você consegue focar "no que importa" e ganha de brinde uma ótima arquitetura, testada por milhares de pessoas e amplamente documentada.

Exemplo da vida real

Imagine que você estude Ruby on Rails por cerca de 1 ano. Após esse período você inicia em um trabalho novo onde sua tarefa é ajudar no produto da empresa (que usa Ruby on Rails).

Eu garanto que, em poucos minutos, você consegue (a partir do seu conhecimento prévio) saber exatamente o que cada tipo de arquivo faz, como estão organizados e cada comando para executar o projeto.

Nesse cenário, você consegue "pular" a etapa de entender o projeto e consegue partir para uma entrega de valor em um tempo bem curto.

Eu gosto disso

Desvantagens

Posso ser radical e dizer coisas como:

Em regimes ditatoriais é tirado o poder de escolha da população em prol de coisas como sua segurança e eficiência 👎.

Na China, por exemplo, a população escolheu abrir mão da própria "liberdade" em favor da segurança. Isso é uma boa troca? Para nosso caso é irrelevante! Mas entender que tirar o poder de escolha de alguém em prol de um ganho qualquer, sempre gera uma troca. Se vale a pena adotar essa escolha, só você pode responder 😱.

Sendo mais amigável posso dizer coisas como:

A partir do momento em que você aceita usar uma arquitetura pré pronta, você aceita uma listinha de desvantagens que vem junto. Temos como a mais notável a seguinte afirmação:

Cada projeto é um projeto, assumir que a mesma fórmula atende todos os casos é no mínimo ingenuidade 😑.

E o Express com isso?

Basicamente aprendemos a criar uma API de forma muito simples em um único arquivo ou, no máximo, com dois ou três tipos de arquivos (geralmente seguindo um MVC) que nos apresenta à uma filosofia totalmente oposta à escolhida pelo Rails. Finalmente lhes apresento o que torna a curva de aprendizado do Express tão interessante:

Definição do Express:

Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

fonte: expressjs.com

ou seja,

Aqui temos um framework totalmente flexível, que permite e estimula que o desenvolvedor crie e implemente sua própria arquitetura. Não importa o tamanho ou objetivo do projeto, você tem as ferramentas para organizar seu projeto da forma que melhor te atende.

Instale o Express:

$ npm install express
Enter fullscreen mode Exit fullscreen mode

Crie um arquivo index.js:

const express = require('express')
const app = express()

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(3000, () => {
  console.log('Example app listening on port 3000!')
})
Enter fullscreen mode Exit fullscreen mode

Execute o projeto:

$ node index.js
Enter fullscreen mode Exit fullscreen mode

Pronto, temos uma API rodando plenamente.

OBS: Existe uma ferramenta de linha de comando que faz scaffolding no Express, porém ela não é focada em APIs e quase não é utilizada.

Com Express você tem o poder de fazer do seu jeito. Isso é incrível! Mas é aqui que mora o principal problema:

Desvantagens

Ter o poder de fazer as coisas do seu jeito, pode ser lido como: "Ter o poder de fazer merda" 💩.

Fazendo besteira

Sim, é isso mesmo que você leu, a partir do momento em que você não delegou o trabalho de arquitetura para alguém que sabe o que está fazendo (mesmo que no caso do Rails tentando ser genérico para atender a todos os casos), fica muito fácil construir uma aplicação sem levar em consideração vários aspectos estruturais que são extremamente importantes. Principalmente se você pretende dar manutenção no projeto a longo prazo e em equipe.

Exemplo da vida real:

Imagine que você estude Express por cerca de 1 ano, após esse período, você inicia em um trabalho novo onde sua tarefa é ajudar no produto da empresa (que usa Express).

Eu garanto que o projeto está organizado de forma diferente do que você fez durante seus estudos, o que aumenta muito a curva de aprendizado para entregar algo de valor.

Vantagens

Obviamente, se você entende do que está fazendo, o poder de construir uma aplicação da forma que quiser é extremamente eficiente. É possível criar verdadeiras obras de arte em forma de arquitetura que vão poupar muitas horas e "dinheiros" a longo prazo. Isso inclui uma boa documentação, o que vai diminuir muito a curva de aprendizado de alguém novo no projeto, mitigando a principal desvantagem de um arquitetura "personalizada" 💚.

Claramente esse processo não é trivial, o que nos leva ao próximo tópico:

Requisitos

Chegamos à conclusão de que precisamos estudar bastante para entender o que estamos fazendo a nível de arquitetura.

Para criar um projeto que atende aos requisitos estruturais de uma boa arquitetura, primeiro precisamos saber quais são esses requisitos.

Vou compartilhar com vocês alguns dos meus objetivos ao criar um novo projeto:

  • Escalabilidade
    • Separação de responsabilidades.
    • Responsabilidade única.
  • Manutenibilidade
    • Maior facilidade para criação de error handlers.
    • Maior facilidade para escrita de testes automatizados.
  • Controllers isolados
    • Todos os controllers são assíncronos.
    • Facilidade para escrever validações.
  • Iterações em serviços de forma isolada
    • Serviços síncronos e assíncronos.
    • Múltiplos serviços para diferentes bancos de dados.
  • Error handler automático para todas as rotas

Essa listinha já é um bom ponto de partida para criar uma
aplicação com excelente qualidade (a de nível de arquitetura).

OK

Agora precisamos entender cada um desses requisitos e como implementá-los na prática usando Express. Mas como esse texto já está muito longo vamos deixar isso para a parte 2.

Conclusão

"Cada escolha uma renúncia" é uma ótima frase para explicar esses processos de decisão.

Espero que eu tenha conseguido trazer algo de relevante para você que chegou até esse momento da leitura 😁.

Se você ficou animado ao ler esse artigo, deixe um comentário e um ❤️ para eu saber que tem alguém interessado e que vale a pena continuar a compartilhar esse tipo de conteúdo.

Adeus

Um abraço e até a próxima.

Top comments (12)

Collapse
 
robsongap profile image
Robson Alves

Achei muito interessante parabéns, estou estudando back-end encontro muitos tutoriais na internet, com diversas soluções vou olhar com mais calma o problema e tentar estruturar melhor a solução para per formar melhor.
espero que você escreva outros artigos.

Collapse
 
afonsopacifer profile image
Afonso Pacifer

Muito bom <3
Fico feliz que foi útil p vc :)
Postarei a parte 2 em breve!

Collapse
 
maaprofit profile image
Marcelo Augusto

Sensacional, continua com os conteúdos. Esse foi um ponto que sempre tive dúvidas e acabo que consegui seguir a maior parte dos objetivos que listou no artigo. Mas estou ansioso pelo seu próximo, grande abraço.

Collapse
 
afonsopacifer profile image
Afonso Pacifer

Boa!
Vai ser legal p trocarmos ideias sobre como organizar tudo. O próximo não deve demorar p sair, tbm to ansioso p ter feedbacks sobre estrutura, etc..

Abraço :)

Collapse
 
notreniev profile image
Everton Canez

Achei teu artigo muito legal e pertinente. Sou adepto do express justamente pela liberdade que ele me dá. Mas realmente é preciso saber pra onde se está indo no projeto.

Meu feedback aqui é apenas que senti falta de um exemplo de estrutura de pastas e de código que vc citou ao final. Curiosidade minha mesmo.

Abraço!

Collapse
 
afonsopacifer profile image
Afonso Pacifer

Obrigado pela Feedback mano <3

Deixei a parte prática (mostrando a estrutura e code) p próximo artigo pq esse já estava muito grande :|

Quando terminar a parte 2, vou criar um repo no github com um exemplo completinho e documentado :)

Collapse
 
rafamarqueslearn profile image
Rafael Marques

Ei Afonso, antes de mais nada, obrigado pelo conteúdo. Você poderia indicar um projeto rest API no github que considera como tendo uma boa estrutura organizacional?

Collapse
 
afonsopacifer profile image
Afonso Pacifer

Massa!
Então, os que eu trabalho são privados :(
Maasss... eu montei um de exemplo que vai sair junto com a parte 2 desse texto :)

Collapse
 
waldemirflj profile image
Waldemir Francisco

Bem pertinente seu artigo, parabéns.

Collapse
 
afonsopacifer profile image
Afonso Pacifer

Vlw mano <3

Collapse
 
jgmenezes profile image
Jgmenezes

Excelente artigo, parabéns! Quando sai a parte 2 ?

Collapse
 
afonsopacifer profile image
Afonso Pacifer

Vlw!
Acho que em breve.. eu já escrevi a maior parte..
É que será um texto beemmm grandinho!