Olá! Sejam bem-vindos a mais este curso na Alura. Meu nome é Vinícius Neves, conhecido como o Dev careca barbudo. A proposta deste curso é discutirmos sobre arquitetura, com um enfoque significativo em front-end.
Audiodescrição: Vinícius é um homem branco, careca, com barba cheia e escura. Ele veste uma camiseta preta e está em um ambiente de estúdio com fundo neutro.
Se já possuímos experiência com React, seja por meio dos cursos da carreira ou pela prática diária, estaremos preparados para aproveitar ao máximo este conteúdo, que se diferencia dos demais. Neste curso, não estaremos desenvolvendo um protótipo ou projeto, mas sim abordando conceitos importantes relacionados ao nosso cotidiano.
Vamos discutir decisões arquiteturais e design de software, abordando documentação, ADR, tech radar, técnicas disponíveis, soft skills (habilidades interpessoais), hard skills (habilidades técnicas), e padrões de componentes, como container presented (apresentação de contêiner) ou render props (propriedades de renderização). Temos muitos tópicos interessantes para explorar, pois o objetivo deste curso é compartilhar experiências e conhecimentos. Vamos apresentar padrões bem conhecidos e discutir o que temos observado no mercado.
A proposta deste curso é ampliar nosso conjunto de ferramentas, trazendo novas ideias para que possamos nos aprofundar quando fizer sentido. Assim, estaremos mais preparados para tomar decisões informadas, pois já teremos experimentado ou ouvido falar de determinadas ferramentas.
Além de ferramentas, também abordaremos padrões de código e decisões arquiteturais. Essa é a nossa jornada e a abordagem deste curso. Se estivermos tão animados quanto eu para começar essa trajetória, estou aguardando no próximo vídeo da primeira aula. Não sairei daqui até que iniciemos este curso. Até mais!
Agora é o momento de analisarmos o famoso POV, ponto de vista, sob a perspectiva do front-end. Vamos observar o que devemos considerar quando o assunto é arquitetura. Afinal, o front-end não se resume apenas à camada visual. Ele interage com diversas APIs, pode envolver um BFF, lidar com gateways e diferentes serviços. Por exemplo, além de consumir dados do nosso back-end, precisamos considerar o analytics, ou seja, como registramos o uso, a performance e a segurança, que também influenciam. Portanto, a arquitetura do front-end é tão importante quanto a do back-end.
Vamos pensar em uma linha do tempo para entender como tudo começou e evoluiu. Inicialmente, tínhamos páginas estáticas com HTML e CSS. No começo, era apenas HTML, depois veio o CSS e, em seguida, o JavaScript. Isso era o que tínhamos nos primórdios. Posteriormente, passamos para o server-side rendering, onde o servidor montava o HTML e o CSS. Utilizávamos tecnologias como PHP, ASP.NET, JSP, Rails, entre outras, que renderizavam e entregavam tudo pronto.
Com o tempo, surgiram as single-page applications. Isso significa que transferimos a responsabilidade de montar e gerenciar o HTML do servidor para o cliente. Agora, o navegador, através do motor do JavaScript, cria e altera elementos HTML em tempo real, sob demanda. A necessidade por trás disso era ter um front-end mais interativo. Quando tudo era feito no lado do servidor, cada interação do usuário exigia o recarregamento da página inteira. Imagine preencher um formulário extenso, como o de imposto de renda, enviar e receber um erro, e às vezes o formulário não voltava preenchido, exigindo que tudo fosse refeito. Precisávamos de interfaces ricas para interação com o usuário.
Depois, surgiram alternativas intermediárias, como Next.js, Nuxt, Gatsby, entre outras, que retomaram o contexto de renderização no lado do servidor, mas com conceitos diferentes. Mesmo com o front-end sendo renderizado no servidor, ele poderia permanecer separado do back-end. Outra abordagem foi a dos micro front-ends, uma forma de pensar e arquitetar nosso cenário, especialmente quando temos muitos times verticais distribuídos. O micro front-end ainda pode ser uma boa opção.
Atualmente, temos um híbrido de todas essas abordagens. Temos o SSR (Server Side Rendering) misturado com o CSR (Client Side Rendering), onde o servidor e o cliente realizam tarefas. Além disso, temos o Static Side Generation, que gera tudo de forma estática no momento do build. Também existe uma combinação de estático com incremental, onde incrementamos o site estático ao longo do tempo. Hoje, dispomos de um vasto leque de ferramentas para escolher a melhor opção, considerando as condições de temperatura e pressão. Dado o cenário e os requisitos, escolhemos a ferramenta mais adequada.
A arquitetura define como nossos componentes se organizam e interagem. O código começa a crescer com muitas funcionalidades, várias pessoas mexendo, reuso de componentes e múltiplos produtos compartilhando a mesma base. As decisões sobre renderização, cache, infraestrutura e distribuição são decisões arquiteturais. Não vamos escrever código durante este curso, mas temos alguns exemplos para analisar. Vamos considerar um exemplo de drop-down, um menu suspenso para escolher uma opção. Neste exemplo, temos um componente único que recebe uma lista de itens e uma função que é chamada quando alguém seleciona um item. Esse é um estilo de abordagem.
Pensemos agora na necessidade de, além de exibir o perfil e o nome do item, incluir um ícone. Precisaremos modificar esse componente, pois ele agora requer um ícone. Em vez de receber um array de strings, passaremos a receber um array de objetos complexos, que contêm uma label e um ícone. Esse objeto complexo pode crescer indefinidamente. Embora funcione, em cenários com ou sem ícone, sempre que precisarmos fazer alterações nesse drop-down, será necessário modificar o contrato e a interface.
Se tivéssemos optado por uma abordagem diferente, entregando um componente drop-down que recebe itens, poderíamos ter um componente composto. Assim, teríamos um drop-down e um componente externo, o drop-down item, que possui children, permitindo incluir o que quisermos, com ou sem ícone. A questão não é sobre certo ou errado, mas sobre qual é a melhor decisão pensando no futuro. A arquitetura visa projetar para o futuro, criando algo duradouro. Um drop-down composto pode ser uma opção mais interessante, pois é escalável. No entanto, há um trade-off: antes, precisávamos de poucas linhas de código, agora é mais verboso. A quantidade de linhas de código é apenas uma das métricas que podemos considerar.
Tudo tem um trade-off. Para criar um componente escalável, pagamos o preço de ser mais verboso. Será que isso é um problema significativo? Depende. O importante é pensar no futuro. Nosso foco é olhar para a arquitetura pela perspectiva do front-end, analisando componentes React e o papel da pessoa arquiteta. Essa função pode ser um cargo ou uma liderança situacional. Às vezes, não há um arquiteto de software na empresa, mas alguém precisará assumir essa responsabilidade ao desenvolver um novo sistema.
Entre as responsabilidades dessa pessoa, está traduzir requisitos em decisões. Um exemplo é a escolha entre Next.js com SSR ou single page application com cache, equilibrando performance e custo. Outra responsabilidade é definir padrões e princípios, como estabelecer um padrão de pastas, convenções de nome, e organização do código. Precisamos definir claramente o que é UI (componentes visuais), o domínio (regra de negócio) e a infraestrutura (leitura de arquivos, envio para uma API, etc.).
Além disso, a pessoa arquiteta deve ser a ponte entre disciplinas. Por exemplo, ao desenvolver um design system com o time de design, será necessário publicá-lo, o que envolve interação com a equipe de infraestrutura. Assim, centralizamos a comunicação entre diferentes disciplinas, como design, infra, produto, entre outras.
Em resumo, a arquitetura de front-end é sobre clareza e sustentabilidade, garantindo que o código cresça, se integre e permaneça eficiente ao longo do tempo. As conexões entre as partes são constantes, e estamos criando algo para durar. Com isso, encerramos este tema e aguardamos a próxima discussão. Até lá!
Vamos iniciar nossa discussão. Como dizem os grandes mestres, "bem começado, metade feito". Vamos entender o que é, afinal, arquitetura de software. No slide, apresentamos a etimologia da palavra "arquitetura". Ela vem do latim, derivado do grego, e pode ser dividida em duas partes: a primeira parte traz um sentido de princípio, de autoridade, e a segunda parte refere-se a um artesão, um construtor, um criador. Assim, podemos entender como a arte ou técnica do construtor principal, ou seja, o ofício do mestre construtor.
Ao nos aprofundarmos em arquitetura de software, trazemos uma citação de Robert Martin, conhecido como Uncle Bob. Ele afirma que a arquitetura de um sistema de software é a forma dada a esse sistema pelos seus criadores. Essa forma está na divisão do sistema em componentes, na organização desses componentes e nos modos como eles se comunicam entre si. Quando Uncle Bob menciona componentes, ele se refere a partes de um sistema, não a componentes de uma aplicação front-end feita em React. Trata-se de algo muito mais abrangente.
Podemos visualizar a pirâmide da arquitetura, que abrange três conceitos: arquitetura, design e implementação. Esses conceitos estão interligados. A arquitetura está em um nível mais alto, envolvendo decisões sobre a estrutura e o comportamento do sistema. O design oferece soluções detalhadas dentro dos limites da arquitetura. A implementação é a execução prática, onde codificamos essas soluções.
Uma citação de Grad complementa essa ideia: "toda arquitetura é design, mas nem todo design é arquitetura". Os conceitos de design e arquitetura de software se misturam, mas não precisamos nos preocupar com isso agora, pois teremos um momento específico para discutir esses conceitos.
Para ilustrar na prática, apresentamos uma comparação entre Single Page Application (SPA) e Server-Side Rendering (SSR). Queremos decidir entre usar o React Router com SPA no React puro ou utilizar o Next.js. Fazemos uma tabela para comparar critérios, prós e contras de cada abordagem. Esse tipo de decisão é uma decisão arquitetural do sistema.
Quando falamos de arquitetura de software, ela define os componentes principais e como eles interagem entre si, estabelece regras e orienta todo o desenvolvimento do software. Nosso objetivo é garantir a qualidade, abordando aspectos como performance, escalabilidade e segurança.
Há um detalhe importante a considerar quando falamos em escalabilidade. Muitas vezes, ao pensar em escalabilidade, podemos imaginar que basta aumentar os recursos do servidor. No entanto, não é exatamente isso que queremos dizer aqui. A escalabilidade refere-se à capacidade do sistema de evoluir, receber novas funcionalidades, modificar funcionalidades existentes e continuar saudável em termos de código. O sistema deve ser capaz de se manter ao longo do tempo. É comum encontrarmos software legado em que a tecnologia limita as possibilidades de implementação de novos requisitos. Em vez de fazermos o que é necessário, acabamos fazendo o que é possível no momento, com a tecnologia disponível. Quanto mais tempo o software conseguir se manter, significa que ele escalou adequadamente, estando pronto para receber todas as mudanças necessárias.
Vamos discutir alguns exemplos de decisões arquiteturais. Isso inclui a escolha da linguagem, o stack como um todo, os frameworks, o estilo de desenvolvimento, a comunicação e a integração entre os componentes. Além de tomar essas decisões, é fundamental documentá-las. Um tipo de documento comum em arquitetura é o ADR (Architectural Decision Record), que é um registro de uma decisão arquitetural. Ele segue um modelo que, dado o contexto de um requisito e uma preocupação específica, nos permite decidir a melhor opção para alcançar o objetivo, aceitando as desvantagens. É importante deixar claro os prós e contras, pois tudo envolve um trade-off. Estamos sempre comparando aspectos como performance e escalabilidade, simplicidade e flexibilidade, segurança e usabilidade, custo e robustez. Cada decisão de software é baseada em um conjunto específico de condições, como tempo, orçamento, equipe, pressão para entrega, ambiente de execução, entre outros. A decisão arquitetural deve ser baseada nesse contexto. Retirar uma decisão do contexto dificulta avaliar se foi uma boa ou má escolha.
A comunicação é essencial. Precisamos entender por que uma decisão foi tomada e quais condições a influenciaram. Devemos alinhar com a equipe, gestores, stakeholders e donos do produto, diagramar, criar documentos e ADRs, e garantir que tudo esteja bem documentado. A arquitetura não é apenas sobre criar um sistema funcional; é também sobre garantir que, ao analisarmos o sistema internamente, ele faça sentido.
O que podemos concluir deste primeiro encontro? Depende. Sempre depende das condições. A ferramenta React é a melhor para determinado software? Depende dos requisitos e objetivos do software. Não existe uma solução única que se aplique a todos os tipos de software. Tudo depende do contexto.
Agora que discutimos arquitetura de forma geral, vamos focar mais especificamente no front-end. O que devemos considerar e planejar ao desenvolver software que será executado no navegador, próximo ao cliente? Nos encontramos no próximo encontro. Até lá!
O curso Arquitetura no front-end: estruturando aplicações com decisões técnicas sustentáveis possui 103 minutos de vídeos, em um total de 28 atividades. Gostou? Conheça nossos outros cursos de React 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:
Impulsione a sua carreira com os melhores cursos e faça parte da maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Mobile, Programação, Front-end, DevOps, UX & Design, Marketing Digital, Data Science, Inovação & Gestão, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
Acelere o seu aprendizado com a IA da Alura e prepare-se para o mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Luri é nossa inteligência artificial que tira dúvidas, dá exemplos práticos, corrige exercícios e ajuda a mergulhar ainda mais durante as aulas. Você pode conversar com a Luri até 100 mensagens por semana.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Para estudantes ultra comprometidos atingirem seu objetivo mais rápido.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Mensagens ilimitadas para estudar com a Luri, a IA da Alura, disponível 24hs para tirar suas dúvidas, dar exemplos práticos, corrigir exercícios e impulsionar seus estudos.
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
