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 👍.
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
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/
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.
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.jsweb 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
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!')
})
Execute o projeto:
$ node index.js
Pronto, temos uma API rodando plenamente.
OBS: Existe uma ferramenta de linha de comando que faz
scaffoldingnoExpress, porém ela não é focada emAPIse 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" 💩.
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.
- Maior facilidade para criação de
-
Controllers isolados
- Todos os
controllerssãoassíncronos. - Facilidade para escrever validações.
- Todos os
-
Iterações em serviços de forma isolada
- Serviços
síncronoseassíncronos. - Múltiplos serviços para diferentes
bancos de dados.
- Serviços
- 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).
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.
Um abraço e até a próxima.
Top comments (12)
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.
Muito bom <3
Fico feliz que foi útil p vc :)
Postarei a parte 2 em breve!
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.
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 :)
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!
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 :)
Bem pertinente seu artigo, parabéns.
Vlw mano <3
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?
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 :)
Excelente artigo, parabéns! Quando sai a parte 2 ?
Vlw!
Acho que em breve.. eu já escrevi a maior parte..
É que será um texto beemmm grandinho!