Next.js: trabalhando com arquitetura Front-end

Uma tour sobre arquitetura e monorepos - Apresentação

Ola, pessoas! Eu sou o Mario Souto, do canal @devsoutinho do Youtube, e estou aqui com a Alura nessa parceria incrível trazendo para você um conteúdo bem massa feito com muito carinho sobre arquitetura no mundo do Front-End. Aqui aprenderemos fazer uma boa estrutura de aplicação trabalhando com Next JS e com lib de componentes, tudo isso voltado para o trabalho com Monorepo.

Nossa meta aqui é trazer muito conteúdo relacionado principalmente em cima desse projeto. Aqui temos e uma aia onde vocês podem guardar cada um dos projeto que você tem. Se você trabalha numa empresa como a Alura que tem a parte pública e a parte fechada, o site aberto e o site fechado, vocês vão entender como fazer para trabalhar com esse tipo de aplicação.

Vamos trabalhar bastante com padronização, organização, inter, setup da parte de testes e veremos como padronizar a parte configuração trabalhando no typescript. Além disso, vamos aprender como reusar configurações de typescript, teste e de link.

Vamos clarear um pouco sobre esses "arquivo ponto" que sempre vemos em muitos projetos de open source e para você conseguir trazer um pouco mais de definição. Talvez onde vocês trabalhem isso vai começar dentro de um retro e depois sair para uma outra lib, e ele definitivamente te dará essa estrutura para desenvolver e reaproveitar estruturas e conseguir escalar rápido, principalmente no começo. Muitas empresas optam por usar o monorepo e ele acaba sendo uma solução bem legal que muitas vezes ficam até longo prazo com essa solução, principalmente em estruturas de Front-End.

Enfim, temos várias ideias e vários pontos que traremos aqui para vocês, mas no próximo vídeo!

Uma tour sobre arquitetura e monorepos - Micro Services, Micro Front Ends e Arquitetura

Agora sim vamos começar a nos aprofundar nesse assunto de arquitetura, de monorepo, e como podemos trabalhar com elas.

A primeira coisa que podemos conceituar aqui é mostrar o projeto já pronto que basicamente é um monorepo, porque ele tem toda a estrutura de código que precisamos para fazermos diferentes aplicações trabalhando com Front-End.

Nesse caso em específico temos um repositório então queremos o projeto tanto público quanto privado, qualquer sistema que tivermos aqui e for ser deployado em algum lugar estará dentro Assim como todos os utilitários e componentes comuns que tivermos. Tudo isso fica organizado e separado com o seu contexto declarado e com seu próprio pack de json, com suas tendências.

Temos uma separação boa disso aqui. Trabalhando com monorepo, com vários times é uma coisa bacana. Hoje em dia o GitHub tem muitos recursos para isso. Ele tem recursos, por exemplo, para parte de code owners que ajuda cada time a ser dono de uma pasta. Existem vários recursos de plataforma que tornam viável o que vamos trazer ao longo dos próximos vídeos.

Vejo que muitas pessoas as vezes no começo da carreira acham que arquitetura é sobre como organizar pasta. Se procuramos no Google a definição de "Ariquitetura de Software" vamos encontrar muitas definições, como por exemplo:

"A arquitetura de software de um sistema consiste na definição dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares. O termo também se refere à documentação da arquitetura de software do sistema."

Essa é uma definição um pouco vaga, mas ouvimos muito falar que o pessoal trabalha muito com a arquitetura de micros serviço e muitos acham que é "micro serviço" porque é mais barato, ou porque tem um software menor, ou porque tem menos coisas. Sim, existem algumas dessas vantagens, mas o principal motivo de empresas optarem por trabalhar em uma arquitetura de micros serviços é que elas querem cada time conseguindo trabalhar na sua área individualmente e que seja possível ter uma estrutura de eventos na parte do Banck-End que faça as pessoas plugarem ali e faça funcionar.

Essa ideia foi trabalhada também trazendo para o Front-End. É um conceito que oscila de lugar para lugar, você pode ver gente usando o *Wirefram e outras falando que micro front-end são as pastas, mas vamos pensar em nosso caso aqui. Vamos pensar que queremos fazer, por exemplo, a Alura, que é foi o exemplo do vídeo anterior.

A Alura tem a parte logada e deslogada, tem os componentes genéricos que ela usa para todos os casos, tem funções comuns que usa para todo o lugar e queremos garantir que todo mundo vai escrever o código baseado no mesmo padrão. Baseado nessas características que temos desse projeto e que se aplicam a vários outros projetos que vocês podem estar trabalhando, essas questões podem aparecer assim como vários pontos que posso trazer aqui.

Nessa estrutura conseguimos organizar tudo isso porque dentro da pasta "projects" fica tudo que for publicado externamente, tudo que vai ser publicado na Versel, na WS e tudo que for um pacote reutilizável vai estar dentro da pasta "backages".

Reparem que só de termos essas duas definições, estamos falando a nível de projeto, todo projeto que formos deployar fica na pasta "projects". Ou seja, podemos ter a pasta do web publico, podemos ter a área logada, poderíamos ter só o projeto da parte de autenticação. Poderíamos quebrar isso, ter testes e assim por diante, mas quando você começa nessa estrutura de micros serviços, você vai precisar fazer muitas configurações. Tanto é que temos uma pasta só de setup com a parte de ESLint, de teste, e de configuração.

O monorepo começa a brilhar quando você quer trabalhar com alguma dessas formas de micro porque podemos fazer reuso de algumas dessas configurações. A a minha ideia aqui ao longo dos próximos vídeos é não só falar de micro front-end e micros serviços como se fossem pequenos pedacinhos de código que você coloca no ar e por isso é melhor. Mas porque estaremos padronizando configurações, todo mundo vai programar em cima de bons default, ou seja, bons padrões para programar e se você precisar mexer nisso, você vai precisa mexer em um lugar só.

Vamos plataformizar a estrutura base para todo mundo programar e todo mundo vai programar em cima da estrutura. Nesse caso, vamos aprender a montar essa casquinha que você pode estender como achar melhor para o seu projeto.

Vou deixar na descrição dessa aula alguns materiais complementares que acho importantes para vocês lerem e mais contextos sobre o assunto e assim vocês conseguiram ter outras visões também.

Uma tour sobre arquitetura e monorepos - Configurações iniciais do mono-repo

Até agora focamos mais na teoria, no worksapece, micro front-end e micro serviços, mas acho que está na hora de começarmos a prática.

Em minha área de trabalho, tenho criada uma pasta chamada "NEXT-JS-ARQUITETURA" que vou abrir no VSCode. Começaremos a replicar essa estrutura com então se queremos criar o site da Alura, podemos começar criando a pasta onde está o projeto que será publicado, que é a pasta "projects". Dentro dela, criamos o "web-public" e via Terminal vou acessar essas pastas

nextjs-arquitetura git:(main) cd projects/web-public
web-public git:(main) yarn init -y

O "name" vou deixar como @alura/web-public porque quero deixar claro que estamos trabalhando com um projeto da Alura.

{
"name": @alura/web-public
"version": "1.0.0",
"main": "index.js",
"license": "MIT"
}

Na documentação do Next, podemos copiar as libs bases dele e, usando o terminal, dentro da pasta "web-public" vamos rodar o comando para instalá-las.

web-public git:(main) yarn add next react react-dom

Essa estrutura que eu trouxe do @alura é algo que se vê em vários projetos como, por exemplo, o próprio Babel do JavaScript. Várias empresas quando tem muitos pacotes criam essa estrutura de monorepo para facilitar a gestação.

Se formos no npm "@babel/core - npm", ele sempre tem @babel/core. Tudo para o Babel é como se fosse uma lib a partir da mesma coisa que está dentro do repositório e aqui dentro dele tem "lib", "eslint", "pakages" e todas as configurações que eu trouxe para vocês. E dentro dele tem cada uma das libs do Babel que se propõe a resolver problemas.

Voltando ao nosso código.

{
"name": @alura/web-public
"version": "1.0.0",
"main": "index.js",
"license": "MIT"
"dependencies": {
    "next": "^12.1.6",
    "react": "^18.1.0",
    "react-fom": "^18.1.0"
    }
}

Uma vez que criamos essa estrutura, podemos voltar para a documentação do Next e copiar os scripts.

"scripts": {
    "dev": "next-dev",
    "build": next build",
    "start": "next start",
    "lint": "next lint"
}

Por enquanto não vamos explorar todos eles, mas quero criar um projeto typescript com vocês, então vamos usar o Next dev enquanto isso, primeiro precisamos da pasta "pages" do Next. Dentro dela criaremos o arquivo "index.tsx".

Em seguida, exportamos. Colocamos um return com a tag main e Home.

export default function HomeScreen(){ 
    return (
        <main>
            <h1> Home </h1>
        </main>
    )
}

Essa é a base da nossa Home. Aqui dentro eu inicializei o repositório Git sem vocês terem visto, então na raíz temos a pasta "git", como podemos ver pelo Terminal.

drwxr-xr-x 9 mariosouto staff 288 May 2 17:54 .git

Essa pasta nós iniciamos com git nit, sem mistérios. Qualquer dúvida vocês podem olhar na minha série de GitHub que está no YouTube da Alura gratuitamente.

nextjs-arquitetura git:(main) git init

Reparem que criamos a estrutura base do projeto e tem dois mil arquivos sendo monitorados pelo git. Isso não é interessante, nós queremos monitorar só os códigos do nosso projeto. Para isso, vamos criar um gitgnore.

nextjs-arquitetura git:(main) npx gitgnore node

Aqui estamos pegando um padrão usando o projeto "gitgnore" que você já deve ter visto funcionando em algum outro momento se você me acompanha no canal ou até aqui na Alura mesmo. Note que ele caiu de dois mil para quatro arquivos, chegamos em um ponto bom.

Por mais que tenhamos múltiplos projetos, assim como o Babel faz, vamos tentar centralizar esses arquivos de configuração sempre no ponto mais alto do projeto porque isso ajuda a termos um pouco mais de consistência e usar para todos os outros projetos que estamos trabalhando e tudo mais. Por isso o ".gitgonore" fica na raíz.

Outro arquivo . que queremos aqui serve para garantir espaçamento, algumas configuração mais que é o EditorConfig. Não sei o quanto vocês o conhecem, mas eu gosto bastante de trabalhar com ele. Com o EditorConfig temos o plugin dentro do VSCode e uma vez que temos ele, ele padroniza várias configurações de quando você abre o arquivo.

Em nossa área "NEXTJS-ARQUITETURA" vamos clicar com o botão direito do mouse e selecionar "Generate .editorconfig" e geramos ele.

Queremos que a indentação seja de dois espaço, então para isso ident_size deve ser igual 2. Além disso, queremos que no final ele sempre insira uma nova linha, para isso insert_final_newline deve ser igual a true.

ident_style = space
ident_size = 2
end_of_line = lf
charset = utf-8
trim-trailing_whitespacce = false
insert_final_newline = true

Isso ajuda o GitHub a não mostrar uma bolinha vermelha que incomoda algumas pessoas. Não vou entrar em detalhes de como o Linux e o Windows leem arquivos, mas quero grantir isso. Toda vez que salvar um arquivo ele insere uma linha no final.

É um detalhe importante e que todo mundo do seu time deveria ter para ficar padronizado e conseguirmos trabalhar.

Agora falta conseguirmos rodar nosso projeto, vamos dar um cd na pasta projects e em web-public pelo Terminal.

projects git:(main) cd web-public
web-public git:(main) ls

Agora aqui dentro de web-public git vamos dar o yarn dev.

web-public git:(main) yarn dev

Ele diz que queremos usar o typescript mas ainda não temos os pacotes, então vamos copiar yarn add --dev typescript @types/react @types/node e instalar. Vamos mover essas configurações, mas por enquanto fazemos tudo dentro da pasta projects para vocês acompanharem as mudanças.

Vamos tentar rodar o dev de novo.

web-public git:(main) yarn dev

Ele gera um arquivo "tsconfig.json" e se abrirmos o localhost:3000, ele abre a nossa Home. Logo, está funcionando.

Agora vamos caminhar para os próximos passos começarmos a ter nossa lib de componentes com os pacotes com a parte do desing system. Termos a nossa lib de utilitários, conseguirmos reaproveitar as configurações e assim por diante. E, claro, o mais importante que é conseguir trabalhar com os workspaces que comentei anteriormente, mas ficou um pouco vago. Basicamente será a forma que estruturará para nós com o yarn para termos esses múltiplos pacotes.

Sobre o curso Next.js: trabalhando com arquitetura Front-end

O curso Next.js: trabalhando com arquitetura Front-end possui 131 minutos de vídeos, em um total de 40 atividades. Gostou? Conheça nossos outros cursos de Next.JS em Front-end, ou leia nossos artigos de Front-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Uma tour sobre arquitetura e monorepos
• Estruturando a base do nosso mono-repo
• Configurações de linter compartilhadas
• Configurações de teste compartilhadas
• Dicas finais