Proposta de Arquitetura about tabnews.com.br

[filipedeschamps]

@filipedeschamps essa arquitetura parece ser algo bem clean na minha visão. Talvez adicionaria uma pasta de mixins desde o início para evitar redundância de código. Só que lendo a discussão, observei que eles não tem o intuito de permitir a configuração do caminho relativo dos módulos web; tanto é que a comunidade criou uma bifurcação e adicionaram esse suporte 🤔🤔. Então nesse caso, para seguir a linha que você propôs, acredito que a melhor forma seria criar a camada do back a parte; porém perderia o propósito de nós juntos sentirmos a "dor" do pôrque não utilizar o api routes do nextjs por exemplo. De qualquer forma achei interessante sua abordagem, e vou continuar na pesquisa se é possível contornar esse problema; ou trazer uma sugestão 😉

@brunofamiliar ótimo comentário e eu vou ser sincero, não sei se nesse momento vale a pena comprar essa dívida com o Framework pela simples necessidade de separar arquivos em pastas. As pastas, por mais que ajudem a organizar o projeto, não são mais importantes do que como vamos modelar a aplicação.

Então dado que a gente não vai conseguir organizar de uma forma mais limpa como antes, minha sugestão para avançarmos nesse ponto é ir meio que para o outro extremo: vamos deixar o Next.js abraçar o projeto, vamos explodir a pasta core e fazer o que der o mais próximo do root. O que acaba se assemelhando bastante com o resultado da soma das propostas feitas pelo @dhanielsales @pscruzzz e @huogerac.

Então isso aqui é o começo de um projeto Next.js, correto?

📦 root
 ┣ 📂 pages        // Páginas Web + API

Importante notar que hoje o projeto tem uma pasta css na raiz, mas como estamos usando o custom page extensions, podemos mover para pages tudo que é relacionado a páginas mesmo:

📦 root
 ┣ 📂 pages
 ┃ ┣ 📂 css      // Arquivos de estilização

E querendo ou não, para arquivos estáticos e públicos, a única forma padrão atualmente fornecida pelo Next.js é criar uma pasta public no root do projeto, então, lá vai mais uma pasta na raiz:

📦 root
 ┣ 📂 pages
 ┣ 📂 public        // Arquivos estáticos e públicos, como `robot.txt`

O projeto já conta com uma pasta de scripts soltos, então fica aqui ela representada também:

📦 root
 ┣ 📂 pages
 ┣ 📂 public
 ┣ 📂 scripts        // Scripts do tipo que usamos para baixar avatares

Os nossos Models ou Entities (até hoje não entendo a diferença, mas estou a caminho de aprender, principalmente a parte de "use cases"), podem ficar na raiz também para fácil acesso (fora que podemos usar os alias do Framework):

📦 root
 ┣ 📂 pages
 ┣ 📂 public
 ┣ 📂 scripts
 ┣ 📂 models        // Principais regras de negócio
 ┃ ┣ 📜 post.js
 ┃ ┣ 📜 post.test.js
 ┃ ┣ 📜 user.js
 ┃ ┗ 📜 user.test.js

E nota que os testes estão junto destas unidades de funcionalidade e sugiro fazer a mesma coisa para o pages, mas mesmo assim iremos precisar de alguns utilitários de testes, talvez dados mockados, e que poderão ficar numa pasta separada tests.

📦 root
 ┣ 📂 pages
 ┣ 📂 public
 ┣ 📂 scripts
 ┣ 📂 models
 ┣ 📂 tests        // Arquivos auxiliares dos testes

De qualquer forma, o assunto testes é algo gigantesco, e muitas vezes vale a pena separar tudo numa pasta tests e organizar lá, pois ao invés de consolidar todos os testes em um único arquivo, por exemplo post.test.js, fica mais completo separar em vários arquivos de teste, e cada um explorando as condições por um ângulo.

Outra pasta importante é a que vai tocar diretamente em pontos da infraestrutura, como persistência através do conector de um banco de dados, cache através do conector de um Redis, Migrations, ou até uma pasta para automações da infraestrutura (baseando no que o @huogerac está fazendo em outra issue)

📦 root
 ┣ 📂 pages
 ┣ 📂 public
 ┣ 📂 scripts
 ┣ 📂 models
 ┣ 📂 tests
 ┣ 📂 infra        // Conectores, migrações e automações da Infraestrutura
 ┃ ┣ 📂 devops
 ┃ ┣ 📂 migrations
 ┃ ┗ 📜 postgres.js

E turma, dá pra ir jogando esse xadrez e tentando pensar em mais movimentos para frente, mas não sei se vale a pena. Acho que vale a pena irmos concretizando essas coisas e vendo se nossas ideias cabem nessa organização e ir mudando e sentindo para onde o projeto irá nos levar.

Votação

Então, para quem teve paciência e esforço em ler essa resposta, peço que faça seu voto com 👍 para darmos como "encerrado" esse assunto e deixar a realidade do projeto nos guiar, ou vote com 👎 e responda a issue com sua sugestão e que será muito bem vinda 🤝 🤝 🤝 🤝

[filipedeschamps]

Fala turma! To há alguns bons dias remoendo esse assunto, e confesso que não estou conseguindo avançar muito. Arquitetura é como jogar xadrez, e no meu caso não estou conseguindo visualizar muitas jogadas para frente 😂 então eu vou soltar aqui um blob de informação para avaliação de vocês.

Mas antes, eu estou a caminho de me educar melhor no assunto e terminei de ler o livro Clean Architecture (não gostei como a obra foi escrita), em paralelo comprei um curso do Rodrigo Branas que ele fala nesse vídeo e que vai começar semana que vem, e também quero assistir essa playlist e essa aqui também do @rmanguinho.

Mas nada disso vai caber dentro do prazo da Milestone, então minha sugestão vai juntar o que vocês discutiram aqui nessa issue, com minhas experiências passadas, começando pelo o que eu vi acontecendo no Pagar.me:

Pagar.me

Aconteceu uma coisa interessante lá, porque de todas as empresas na qual eu tinha trabalhado até então, as arquiteturas eram basicamente amebas no sentido de que não tinha arquitetura, o negócio só foi acontecendo e talvez pior que a falta de arquitetura era a falta de modelagem. Sem essa modelagem, as coisas não tinham começo nem fim, era uma responsabilidade invadindo o terreno da outra, e trabalhar em algo assim misturado é difícil porque você não sabe no que você está mexendo exatamente. E quando eu entrei no Pagar.me (que na época era altas empresa hype), eu pensei: "puts, aqui vai ter a arquitetura mais sensacional e sofisticada que eu vou presenciar na minha vida"... e turma, não, era extremamente simples, pelo menos na camada da API.

Essa camada, analisando de forma grosseira, não passava de um MVC simples, você tinha os Models muito bem modelados (muito bem mesmo, pouquíssimos eram muito grandes), os Controllers não tinham regras de negócio, eram apenas controladores de fluxo mesmo (e que colavam a parte de autenticação/autorização) e as Views nesse caso eram a renderização do retorno da API (um JSON). E era impressionante como que uma arquitetura tão simples poderia sustentar uma empresa que estava faturando milhões e milhões.

Onde isso quebrava?

Eu não quero entrar em muitos detalhes, pois nem sei se eu poderia estar falando essas coisas, mas a manutenção começava a ficar complicada quando esses Models eram compartilhados entre outros serviços, e também acabava sendo uma luta constante a quantidade de testes E2E para garantir o comportamento final da aplicação (por conta das inúmeras regras financeiras). Fintech é algo realmente arriscado, e tem muita coisa sensível, muita regra de negócio estranha, muitos detalhes e que muitas vezes nem estavam documentados e você só encontrava as informações que queria ou lendo a implementação, ou lendo os testes. Então o bololô real começava nas próprias regras financeiras... elas por si só, sem implementação alguma, já eram um inferno 😂

No final das contas, o que isso me mostrou?

Uma arquitetura simples, com uma ótima modelagem, faz você ir longe, e longe mesmo, tanto em aguentar pancada de tráfego, quanto na parte financeira. Qualquer pessoa consegue embarcar em algo assim simples e repetitivo, e a dificuldade vem quando você cresceu tanto, que a "obra" toda é complexa, independente de como ela foi aplicada. Então eu não tenho medo de arquitetura simples, eu tenho mais medo de modelagem mal feita. E claro que para tudo tem um limite e nenhuma arquitetura simples aguenta a pressão que vai se criando ao passar do tempo, principalmente quando o escopo do seu problema vai mudando.

Minha visão sobre o contexto que estamos inseridos no TabNews

O Next.js, querendo ou não, toma por você algumas decisões de arquitetura e que na minha visão raspam um pouco no MVC, por exemplo: ele resolve automaticamente para você as rotas e já te joga ou numa View representado pelo que está dentro do /pages ou num Controller representado pelo que está dentro de /pages/api. Porém ele não resolve nada do Model, o que é ótimo. Mas numa visão ainda mais macro, como eu já falei dentro dessa issue, eu vejo ele como um grandissísimo Controller e quase tudo pode ser programado fora dele, incluindo os componentes em React, deixado o Next.js realmente como o controlador do que mostrar em qual "acesso" que o framework receber, seja acesso numa Página, ou numa rota de API. Tirando essa parte de Controller mais tradicional, ele também é responsável por ser um Controller Não Tradicional, ao trazer funcionalidades como o getStaticProps ou getStaticPaths por exemplo. E eu chamo de Controller Não Tradicional, porque também é só uma forma de coletar dados e jogar dentro de uma View (que é o componente final React).

E a palavra Controller em todas essas situações é importante, porque isso força a pensarmos sempre que não devemos programar regras de negócio nessa camada. E isso só reforça minha visão de que o Next.js é um grande Controller, e tudo de importante deve ser programado fora dele, deixando ao framework a responsabilidade de orquestrar o fluxo da requisição, conforme a reação de cada regra de negócio.

Onde respeitar essa ideia se torna contra-produtivo?

Antes de eu desenvolver essa parte, deixa eu mostrar em estrutura de pastas o que escrevi até agora:

📦 root
 ┣ 📂 core     # Tudo o que é de nossa responsabilidade
 ┗ 📂 web      # Tudo o que é responsabilidade do Next.js

Entenda o core onde tudo que nós vamos programar do zero, e que independe do Next.js, e que inclusive pode ser reaproveitado para qualquer outro Framework ou codebase teoricamente falando. Já a pasta web é o que vamos expor para a internet como web mesmo, como website, e que é o root do Next.js. Expandindo ela ficaria assim, e eu já volto aqui, porque tem um ponto que vai atrapalhar, mas por enquanto segue o jogo:

📦 root
 ┣ 📂 core
 ┣ 📂 web
 ┃ ┣ 📂 pages
 ┃ ┃ ┣ 📂 api
 ┃ ┃ ┃ ┗ 📂 news
 ┃ ┃ ┃ ┃ ┗ 📜 index.js
 ┃ ┃ ┣ 📂 noticia
 ┃ ┃ ┃ ┗ 📜 [slug].js
 ┃ ┃ ┗ 📜 index.js

E tudo o que está aqui, são apenas Controllers que usam o que está no core:

📦 root
 ┣ 📂 core
 ┃ ┣ 📂 components
 ┃ ┣ 📂 database
 ┃ ┃ ┣ 📂 migrations
 ┃ ┃ ┗ 📜 index.js
 ┃ ┗ 📂 models
 ┃ ┃ ┣ 📜 post.js
 ┃ ┃ ┗ 📜 user.js
 ┣ 📂 web
 ┃ ┣ 📂 pages
 ┃ ┃ ┣ 📂 api
 ┃ ┃ ┃ ┗ 📂 news
 ┃ ┃ ┃ ┃ ┗ 📜 index.js
 ┃ ┃ ┣ 📂 noticia
 ┃ ┃ ┃ ┗ 📜 [slug].js
 ┃ ┃ ┗ 📜 index.js

E é nesse ponto que eu acho que fica um pouco impraticável jogarmos tudo para o core, mesmo sabendo que Componentes React não são exclusivos do Next.js... você pode usar eles em qualquer lugar. Mas ao mesmo tempo, acho pouco produtivo ter que sempre ir no core para criar uma página, um componente, e daí grudar isso no Next.js. Então minha sugestão é deixar a pasta root do Next.js (web) abraçar a responsabilidade do que é React, e usar a estrutura de pastas por feature proposta lá em cima (e que se beneficia do custom page extensions e que já está configurado no projeto).

Então a pasta componentes que está dentro do core deixa de existir, e se transforma em páginas e componentes dentro da estrutura do Next.js. E se algum dia num futuro maluco chegue a necessidade de sair do Next.js, o core fica protegido e se o novo framework usar React nós podemos migrar os componentes, ou se não usar e nem tiver compatibilidade com as rotas da API, rm -rf web 😂

E testes?

Não pensei muito além, mas os testes podem estar numa posição global, testando o core (mais unitário) ou web (mais e2e):

📦 root
 ┣ 📂 core
 ┣ 📂 web
 ┣ 📂 tests

Ou até colocar uma pasta de testes dentro do core, e outra pasta de testes dentro do web, cada uma com sua abordagem e com o seu próprio setup.

📦 root
 ┣ 📂 core
 ┃ ┣ 📂 tests
 ┣ 📂 web
 ┃ ┣ 📂 tests

Ou até "ao lado do arquivo", eu nunca fiz isso, mas acho massa para saber o que tem arquivo de testes, apesar de deixar um pouco mais de ruído nas pastas e ainda assim precisar de pastas num escopo superior para certos utilitários de testes.

📦 root
 ┣ 📂 core
 ┃ ┣ 📂 models
 ┃ ┃ ┗ 📜 post.js
 ┃ ┃ ┗ 📜 post.test.js
 ┣ 📂 web

E tem mais coisas

Mas como falei, precisava fazer um download desse blob de informações para avaliação de vocês e o raciocínio inicial que proponho é: O que eu vou implementar é algo que poderia ser usado fora do Next.js? Se sim, provavelmente deveria ficar dentro da pasta core, se não, deveria ficar dentro da pasta web.

E conforme vamos avançando na conversa, vou também começar a fazer PRs com as implementações para vermos as ideias se concretizando e entendendo se deu certo ou não.

E por favor, se possível, coloquem seus comentários também nesses PRs 👍 . E mesmo que algum seja merged, é software, dá pra mudar, sempre dá para mudar, principalmente no estágio atual do projeto e o mais importante é não parar de avançar e ir "vendo com os próprios olhos" os passos que estamos dando 🤝

[huogerac]

Fala pessoal,
Nunca fiz um projeto frontend com React do zero, tenho trabalhado últimamente com VueJS, vou compartilhar a estrutura que utilizo nos projetos VueJS, mais para comparação mesmo. Quem sabe tem algo útil para projetos React:

├── devops                 👉 Ansible para deploy
├── public
│   └── img
│   favicon.ico
│   manifest.json          👉 Para tornar o App Web PWA
└── src
    ├── router             👉 #1 - Rotas da aplicação
    ├── views              👉 #2
    │   ├── external       👉 Páginas públicas referente a uma rota
    │   │                     Tem Componentes, chamadas para API e chamadas a STORE
    │   └── internal       👉 Páginas privadas referente a uma rota
    ├── components         👉 #3 - Componentes puros, uma página (view) pode ter N componentes
    │                         Componentes podem enviar eventos (click, acaoX etc...)
    ├── api                👉 #4 - Camada para chamar o backend usando AXIOS
    ├── store              👉 #5 - Camada VueX (Igual Redux no React)
    ├── assets             👉 Imagens
    ├── filters            👉 Permite usar `| formataFone` no template (HTML)
    ├── layouts            👉 Base para o #2
    │   ├── Internal.vue   👉 Layout base com menu suporior para usuarios logados
    │   └── External.vue   👉 Layout base para usuarios sem login
    ├── mixins             👉 Código comum entre páginas (VIEW, ex: carregarUsuarioLogado)
    ├── plugins            👉 Conf. do VueJS
    ├── styles             👉 Estilos comuns (usando SCSS)

Um ponto de atenção, vê se faz sentido pra voces no contexto do React:
É a separação em camadas, onde cada camada tem sua responsabilidade. Por exemplo, imagina que a apenas a camada da API faz comunicação com o backend, que apenas páginas podem chamar a API (assim não temos regras de negócio dentro dos componentes)

Tem este video curto mostrando um pouco do código acima:
https://www.youtube.com/watch?v=OJBHV2o5xuw

Abraço

[wcarugatti]

Eu voto no redux ou contextAPI por serem duas libs muito usadas, de conhecimento geral. Já que é um projeto open source, muita gente já tem exp com redux, e quem não tem vai se beneficiar de aprender redux que é muito pedido no mercado.

[filipedeschamps]

Ahhh que issue importante 😍 vou precisar de bastante ante ajuda nisso 🤝

Algo lá no fundo da minha cabeça diz que a gente deveria se isolar ao máximo do Next.js, por exemplo programar o máximo que der tudo de funcionalidade numa pasta core que é cega ao que é implementado dentro da visão do Next.js... isso inclui desde os models, acesso ao banco, mas a minha visão começa a se quebrar quando se é ou não certo colocar os componentes em React, pois eu vejo que eles não são o framework Next.js, eles são usados por ele. Em resumo, para mim o Next.js é um grande controller de páginas e endpoint de APIs. Mas como eu nunca construi uma aplicação Next.js grande na minha vida, eu provavelmente estou redondamente enganado e eu vou estudar mais para poder contribuir com essa discussão.

Em paralelo, o que facilitaria é a gente olhar para os layouts e tentar entender o que são os componentes, e o que eles vão precisar de dados e de onde eles vem. O que acham? 🤝

[marcostaborda]

Olá pessoal, conforme a live de hj, eu mencionei um tipo Design System para front-end que acho válido dar uma olhada, se chama Atomic Design.

Foi criada por Brad Frost. Eu acho bacana pois não estamos projetando páginas e sim um sistema com vários componentes, e esse design system cai como luva para o projeto.

Fica um vídeo do Rodrigo Branas sobre o assunto - https://www.youtube.com/watch?v=d_zG_KrXiLo

Não sei o que acham, comentem 😅

[rodrigoKulb]

Achei esse artigo bem completo e simples:
https://medium.com/nerd-for-tech/building-solid-next-js-architecture-a8c6702dc67d

Utilizaremos Redux?

[brunofamiliar]

Muito bom o artigo @rodrigoKulb

Sobre se vamos utilizar Redux, eu particularmente não gosto muito (pode ter sido experiências frustrantes minhas), eu acredito que ele adiciona uma super complexidade onde geralmente nem é necessária, como estamos usando next e acredito eu que algumas coisas vamos manter estáticas e outras renderizando do lado do server. Não sei se precisamos mas é um bom questionamento para discutirmos.

Ps: usei Mobx no flutter, não sei se é exatamente igual mas eu achei mais "pratico" do que o Redux

Já usei o Mobx em um projeto react, achei também mais prático que o Redux. Acredito que para uma construção rápida, o mobx deve ser a melhor opção. Agora se parar pra pensar em escalabilidade, o Redux é melhor por se trabalhar com funções puras; isso torna a aplicação mais fácil de escalonar.

[filipedeschamps]

@filipedeschamps então, eu estou acompanhando a discussão e eu acho que teria que ter uma API para o projeto separada do front, para talvez no futuro fazer um app mobile. Dai ficaria uma API Node.js e um Next.js para front-end.

@marcostaborda show meu caro!!! Muito obrigado pela contribuição 🤝 De fato, o Front e o Back devem estar desacoplados no sentido de que, não é o back quem renderiza uma página no Front, ela só recebe os dados e se renderiza. Como estamos usando Next.js, ganhamos isso dentro do mesmo projeto, então agora no começo eu vejo ele resolvendo muito bem toda a parte web/http e isso inclui as páginas e as rotas da API (que pode e vai ser usada por qualquer outro client como a própria página web, aplicativo mobile, aplicativo no command line, etc... é uma API http).

Então para simplificar, eu altamente sugiro começarmos resolvendo tudo isso no mesmo repositório, e ter cuidado total para não desenvolver nossas regras de negócio dentro dessas camadas 👍

[pscruzzz]

Fala, Dhaniel! Tudo certo?

Concordo 100% que é necessário, até mesmo no curto prazo, tem sido complicado sempre recomponentizar para iniciar o desenvolvimento. Daria até mesmo para botar essa estrutura sugerida por você dentro da pasta 'pages' se quisesse, através do page-extensions como sugerido na doc.

Inserindo um pageExtension como ['page.jsx', 'page.js'] daria para ter componentes que não são páginas dentro da pasta pages.

Note: configuring pageExtensions also affects _document.js, _app.js as well as files under pages/api/. For example, setting pageExtensions: ['page.tsx', 'page.ts'] means the following files: _document.tsx, _app.tsx, pages/users.tsx and pages/api/users.ts will have to be renamed to _document.page.tsx, _app.page.tsx, pages/users.page.tsx and pages/api/users.page.ts respectively.

Podendo ficar algo como (enxuguei um pouco só pra exemplificar):

src
├── pages # Módulos. Um para cada página, com a lógica de negócio.
│      └── home-01
│              ├──  index.page.js/ts 
│              ├──  hooks
│              ├──  components
│              ├──  service
│              └──  utils
│      └── home-02
│              ├──  index.page.js/ts
│              ├──  hooks
│              ├──  components
│              ├──  service
│              └──  utils

Isso até o momento em que uma home oficial seja escolhida.

[renant]

Muito bom o artigo @rodrigoKulb

Sobre se vamos utilizar Redux, eu particularmente não gosto muito (pode ter sido experiências frustrantes minhas), eu acredito que ele adiciona uma super complexidade onde geralmente nem é necessária, como estamos usando next e acredito eu que algumas coisas vamos manter estáticas e outras renderizando do lado do server. Não sei se precisamos mas é um bom questionamento para discutirmos.

Ps: usei Mobx no flutter, não sei se é exatamente igual mas eu achei mais "pratico" do que o Redux

[filipedeschamps]

Minha dúvidia aqui é: embora eu vi que o Next.js é server side rendering, mas como não conheço, gostaria de entender se a ideia é um repo mesmo? ou se faz sentido fazer uma separação bem clara (via repo ou via pastas) do backend e suas responsabilidades.

Fala @huogerac a ideia é resolver toda a parte web (tanto as páginas quanto a api) pelo mesmo repositório. Então sim, vamos por enquanto usar o combo backend+frontend fornecido pelo Next.js 👍

[cezarmezzalira]

Super apoiado essa estrutura! Vamos estudar juntos no curso do Branas e ver o que dá pra gente mudar, porque estou curioso sobre vários pontos, principalmente o que já estamos discutindo na issue #61, que tá bem interessante😁

PS: quando tu entrar no grupo do telegram do curso do Branas, tem muita coisa lá que tá alinhada com o momento do projeto. O curso veio na hora certa pra mim pelo menos.

[filipedeschamps]

Ahhhh que massaaaa @cezarmzz 😍 e sobre o Telegram do curso, caramba só vi o acesso disso agora 😂 to entrando lá 👍

[cezarmezzalira]

Vai ser massa demais! O mango vai fazer o curso também!
Eu tô estudando o curso javascript masterclass e aprendendo muita coisa da linguagem que nem fazia ideia que existia!
Será um divisor de águas esse curso, ainda mais com tanta gente diferente e com as experiências aqui e lá, vai ser delicinha 😂😂

[rodrigoKulb]

Sou novato na utilização Next.js, não tenho uma opinião formada sobre qual a melhor Arquitetura.
Olhando a estrutura sugerida pelo @filipedeschamps achei simples e muito lógica. A final para o servidor não faz diferença em qual pasta está o que. A Arquitetura será 100% para nossa organização e facilidade nas manutenções.

PS. Bora fazer o curso do Branas e ver se podemos alterar algo!

[marcostaborda]

Vi um artigo do medium, não sei se ajuda, mas tem uma configuração para reescrever algo dentro do Next.js.

https://medium.com/geekculture/how-to-use-nodejs-backend-for-your-next-js-project-or-both-b36d9dc9ab0a

[filipedeschamps]

Show! Eu sempre tento ao máximo visualizar quem é o "controller" de um sistema, para mim é uma camada tão interessante quanto o core/lógica de negócio, pois é quem leva as informações pra lá e pra cá.

De qualquer forma, não sei o quanto a minha sugestão se sustenta, dado ao modelo proposto pelo @pscruzzz com o pageExtension 👍

[filipedeschamps]

Pessoal, acho que não vamos conseguir colocar o Next.js para rodar dentro de uma pasta web, não sem talvez abrir margem para dor de cabeça. Tem uma discussão antiga, mas que foi evoluindo e chegou ao ponto de criarem uma configuração para poder colocar dentro da pasta src que é um dos padrões adotados em projetos Node.js. Vou pensar mais a respeito e começar a mandar PRs e daí a gente vai vendo como está ficando 👍

[marcostaborda]

@filipedeschamps então, eu estou acompanhando a discussão e eu acho que teria que ter uma API para o projeto separada do front, para talvez no futuro fazer um app mobile. Dai ficaria uma API Node.js e um Next.js para front-end.

Teriamos que ver dai a arquitetura do back e do front, eu tenho alguns projetos que fiz que utilizei o TDD e SOLID em Node.js e para front utilizei diversas abordagens 😅

[dhanielsales]

Muito interessante! Não conhecia essa feature do next.config.js. Pode ser tranquilamente dentro da pasta pages de fato.

Após ter postado aqui, me recordei que a proposta do TabNews é de ser monorepo, com backend acoplado, então acredito que sua solução proposta, possa até fazer mais sentido realmente, tentando enxugar mais a pastas, já que haverão pastas também para o backend.

Vou colocar outro mapa abaixo do que eu entendi, para termos em mente algo e irmos evoluindo. 😄

src
├── components   # Componentes globais de uso geral do projeto.
├── layout       # Wrappers padrões para componentes ou páginas.
├── hooks        # Hooks globais de uso geral do projeto.
├── contexts     # Contexts para gerenciamento de estado global do projeto.
├── pages        # Cada página associada com uma rota e com a lógica de negócio. 
│      ├── example-page
│      │      ├──  index.page.js/ts  # Ponto de partida dessa rota.
│      │      ├──  hooks        # Hooks globais de uso exclusivo desse módulo.
│      │      ├──  components   # Componentes de uso exclusivo desse módulo.
│      │      ├──  service      # Funções e lógicas de utilização geral e genérica de uso exclusivo desse módulo.
│      │      └──  utils        # Componentes de uso exclusivo desse módulo.
│      └── api
│             └──  example-api-route.page.js/ts
├── services     # Lógica de comunicação com o backend.
├── shared       # Tudo que for compartilhável entre módulos. Sendo configuração de temas, etc.
└── utils        # Funções e lógicas de utilização geral e genérica.

Gostei bastante dessa ideia! 😆

[dhanielsales]

Gosto muito da ideia de utilizar do NextJs como um grande Router com seus "Controllers" pro frontend e backend, nunca havia pensado nele dessa maneira. 🤔
Vou tentar pensar em algo hoje a noite e coloco aqui amanhã 😄

[filipedeschamps]

@huogerac muito massa vir trazer sua experiência com VueJS 🤝 excelente poder analisar o problema sob ângulos diferentes 👍

[brunofamiliar]

Fala pessoal,
Nunca fiz um projeto frontend com React do zero, tenho trabalhado últimamente com VueJS, vou compartilhar a estrutura que utilizo nos projetos VueJS, mais para comparação mesmo. Quem sabe tem algo útil para projetos React:

├── devops                 👉 Ansible para deploy
├── public
│   └── img
│   favicon.ico
│   manifest.json          👉 Para tornar o App Web PWA
└── src
    ├── router             👉 #1 - Rotas da aplicação
    ├── views              👉 #2
    │   ├── external       👉 Páginas públicas referente a uma rota
    │   │                     Tem Componentes, chamadas para API e chamadas a STORE
    │   └── internal       👉 Páginas privadas referente a uma rota
    ├── components         👉 #3 - Componentes puros, uma página (view) pode ter N componentes
    │                         Componentes podem enviar eventos (click, acaoX etc...)
    ├── api                👉 #4 - Camada para chamar o backend usando AXIOS
    ├── store              👉 #5 - Camada VueX (Igual Redux no React)
    ├── assets             👉 Imagens
    ├── filters            👉 Permite usar `| formataFone` no template (HTML)
    ├── layouts            👉 Base para o #2
    │   ├── Internal.vue   👉 Layout base com menu suporior para usuarios logados
    │   └── External.vue   👉 Layout base para usuarios sem login
    ├── mixins             👉 Código comum entre páginas (VIEW, ex: carregarUsuarioLogado)
    ├── plugins            👉 Conf. do VueJS
    ├── styles             👉 Estilos comuns (usando SCSS)

Um ponto de atenção, vê se faz sentido pra voces no contexto do React:
É a separação em camadas, onde cada camada tem sua responsabilidade. Por exemplo, imagina que a apenas a camada da API faz comunicação com o backend, que apenas páginas podem chamar a API (assim não temos regras de negócio dentro dos componentes)

Tem este video curto mostrando um pouco do código acima:
https://www.youtube.com/watch?v=OJBHV2o5xuw

Abraço

Hoje parei pra ler melhor sobre essa arquitetura, vai me ajudar bastante! Estava em busca de algo que pudesse me auxiliar em um projeto vuejs que venho atuando 😄

[rodrigoKulb]

Sobre se vamos utilizar Redux, eu particularmente não gosto muito (pode ter sido experiências frustrantes minhas), eu acredito...

Concordo, nunca trabalhei com Redux estava lendo que ele centraliza o comportamento / interações entre os componentes. Mas acredito que em projeto de pequeno / médio porte não seja tão necessário.

[victorbiasibetti]

Olá a todos.

Pensando em um crescimento mais saudável do projeto, mas sem trazer complicações e Overengineering, pensei em trazer um modelo de arquitetura para o frontend do projeto.

Indo direto ao ponto, esse é o modelo:

src
├── components   # Componentes globais de uso geral do projeto.
├── layout       # Wrappers padrões para componentes ou páginas.
├── hooks        # Hooks globais de uso geral do projeto.
├── contexts     # Contexts para gerenciamento de estado global do projeto.
├── modules      # Módulos. Um para cada página, com a lógica de negócio.
│      └──   example-module
│              ├──  index.js/ts  # Ponto de partida desse módulo. Esse arquivo será importado na página pertinente.
│              ├──  hooks        # Hooks globais de uso exclusivo desse módulo.
│              ├──  components   # Componentes de uso exclusivo desse módulo.
│              ├──  service      # Funções e lógicas de utilização geral e genérica de uso exclusivo desse módulo.
│              └──  utils        # Componentes de uso exclusivo desse módulo.
├── pages        # Cada página associada com uma rota e um módulo. 
├── services     # Lógica de comunicação com o backend.
├── shared       # Tudo que for compartilhável entre módulos. Sendo configuração de temas, etc.
└── utils        # Funções e lógicas de utilização geral e genérica.

Essa estrutura interna aos Módulos é opcional e pode ser criada mediante necessidade, precisando inicialmente só do index.js/ts

Caso queiram agregar em algo, criticar ou propor melhorias, por favor coloquem aqui nessa Issue. Sei que queremos manter KISS, mas acredito que isso não seja distante do simples e intuitivo, mas agregue muito a longo prazo na manutenibilidade do projeto.

Um forte abraço pessoal.

Particularmente eu gostei bastante desta arquitetura, pois com ela daria para isolar a parte de server-side no pages/page.js(ts) e o módulo tratar apenas os dados, sem se preocupar de onde eles estão vindo.

[huogerac]

Oi pessoal,

Vejo nos projetos a separação em 2 estruturas (frontend e backend), independente se é no mesmo repositório ou em repositórios diferentes.
Minha dúvidia aqui é: embora eu vi que o Next.js é server side rendering, mas como não conheço, gostaria de entender se a ideia é um repo mesmo? ou se faz sentido fazer uma separação bem clara (via repo ou via pastas) do backend e suas responsabilidades.
Em outras palavras, estas estruturas de pastas me parecem focarem mais na camada do frontend apenas, talvez precisamos tambem pensar na estrutura do backend (que irá no mínimo ter uma camada de API e outra de acesso ao banco/ORM/Migrations), faz sentido?

Posso estar enganado, mas as vezes parece que os devs backend acham que 80% é do backend e no frontend é só "uma pagininha" e os devs frontend acham que 80% é no front e o backend é só acesso ao banco..rs
Meu ponto é que os 2 lados tem complexidades, vai ter milestone que 100% do trabalho vai ser no backend e outro no frontend, acredito que ambos precisam de atenção (estrutura de pastas/camadas/separação de responsabilidade etc..)
E da a impressão que o Next.js trata que o "server side" é a parte mais simples...e ele faz a mágica pra gente

Enfim, só para entender e confirmar que vai ser apenas um repositório mesmo, onde o tabnews vai utilizar o SSR e recursos server side. Me parece bem interessante isto, mas ao mesmo tempo, tendo a separar em 2 projetos/repos, onde cada um segue sua vida independente...voces que já trabalham Next.js neste modelo de server side, quais mais vantagens temos?
Valeu e []'s

[brunofamiliar]

@filipedeschamps essa arquitetura parece ser algo bem clean na minha visão. Talvez adicionaria uma pasta de mixins desde o início para evitar redundância de código. Só que lendo a discussão, observei que eles não tem o intuito de permitir a configuração do caminho relativo dos módulos web; tanto é que a comunidade criou uma bifurcação e adicionaram esse suporte 🤔🤔. Então nesse caso, para seguir a linha que você propôs, acredito que a melhor forma seria criar a camada do back a parte; porém perderia o propósito de nós juntos sentirmos a "dor" do pôrque não utilizar o api routes do nextjs por exemplo. De qualquer forma achei interessante sua abordagem, e vou continuar na pesquisa se é possível contornar esse problema; ou trazer uma sugestão 😉