Uma vez perguntei a um professor de desenvolvimento, que também era dev, o que um desenvolvedor backend junior precisava saber, isso há pouco mais de 2 anos atrás, essa foi a resposta dele:
1. Separação de camadas
É importante em uma aplicação backend que as responsabilidades sejam separadas, de maneira que as funções do seu código sejam independentes, mas que ao mesmo tempo trabalhem juntos, isso facilita na troca futura de ferramentas, manutenção do código e etc. Utilizando de uma explicação mais expositiva, olhe está imagem, mas não se preocupe em entender tudo agora:
Agora vamos por partes, nessa primeira parte temos a camada de routes, esta camada irá guardar as rotas da sua aplicação, que é basicamente a rota e o recurso que ela vai entregar - exemplo abaixo -, você pode utilizar de agrupamentos de rotas para modularizar mais ainda seu código.
Exemplo de routes:
2. O que vai no controller?
Agora, a camada Routes comunica com a Controllers, e essa, como o próprio nome sugere, controla o fluxo da requisição, é por ela e SOMENTE por ela que ocorre o recebimento da requisição e o envio da resposta, dentro dela não é aplicada nenhuma lógica ou regra de negócio. Segue abaixo um exemplo de controllers para login:
3. O que vai no services?
Falando sobre services, essa é a parte divertida, aqui você aplica toda a lógica e regra de negócio da sua aplicação e retorna para o controller, PORÉM não faça conexões com o banco de dados aqui, não coloque SQL e nem crie modelos do seu banco, APENAS lógica e regras de negócio. Então tá, senão aqui, onde aplicaríamos isso? Leia o próximo tópico.
3. Repository pattern?
Já falamos das rotas, da camada de controle e da aplicação de regra de negócio, resta a repository, essa é responsável pela manipulação do banco de dados, ela persiste, modifica e busca dados.
Se vai fazer login, é nesta que faz a busca do usuário, se vai cadastrar um novo usuário, é aqui que salva, se vai atualizar, também é aqui e assim por diante, toda comunicação com o banco de dados é por essa camada. Um exemplo muito simples abaixo de uma busca de usuário no banco Mongo, onde só é necessário passar um id utilizando o model.
Leia mais aqui
4. O que é um model?
Existe um modelo de projeto chamado MVC, onde o M significa _model _e nesse tipo de projeto implica na lógica completa da sua aplicação, inclusive na conexão do banco. Porém, na linha de raciocínio exposta anteriormente, essa pasta pode ser utilizada para organizar as estruturas básicas que envolvem seu banco, modelo de entidades/tabelas e schemas. Por exemplo, no mongo você utiliza de schemas que é um objeto JSON que define a estrutura e o conteúdo do seu dados e para realizar uma busca no banco, é utilizado o Schema para fazer isso, o model é uma boa pasta para deixar o Schema.
5. O que é um ORM?
Por fim, os ORM são ferramentas para abstração de querys de buscas em bancos de dados, garantindo segurança e velocidade no desenvolvimento. Ele faz a conversa entre um objeto e um banco relacional, que possui paradigmas diferentes de funcionamento. Conectar, buscar, inserir e etc, é responsabilidade da ORM. Uma ferramenta bem conhecida é a sequelize:
Leia mais aqui
Por fim, existem outras camadas que podem ser aplicadas e a melhor estrutura a ser utilizada depende do projeto, então o desenvolvedor deve analisar para saber qual faz mais sentido.
Saiba mais aqui
Top comments (0)