Arquitectura em Front-end

E aí, malta! Hoje vamos mergulhar a fundo num assunto que está a dar que falar no mundo do desenvolvimento web: a arquitetura no ecossistema front-end. Pois é, malta, se achavam que o front-end era só separar o CSS do HTML direitinho, preparem-se para uma viagem e tanto!

Vamos começar por desconstruir essa ideia simplista. O front-end evoluiu muito nos últimos anos, e hoje estamos a falar de uma complexidade que rivaliza com o back-end em muitos aspetos. Não é à toa que surgiram termos como "back-end do front-end" e "micro front-ends". Mas calma, vamos por partes.

A evolução do Front-end

Lembram-se quando tudo era uma confusão, com HTML, CSS e JavaScript todos misturados numa só página? Pois é, passamos por uma fase de separação destas responsabilidades, criando ficheiros distintos para cada linguagem. Foi um avanço e tanto, mas o mundo não se ficou por aqui.

Com o passar do tempo, as aplicações web tornaram-se mais complexas. As páginas precisavam de ser mais dinâmicas, com interações mais elaboradas. E aí começou uma migração: parte da lógica que antes estava no servidor começou a ser executada no browser do cliente. O front-end ganhou músculo!

Mas, como diria o tio Ben do Spider-man, "com grandes poderes vêm grandes responsabilidades". E com esta complexidade crescente, surgiu a necessidade de organizar melhor o código front-end. Já não dava para atirar tudo para um ficheiro JavaScript gigante e esperar que funcionasse.

Arquitetura por camadas

Imagine só: está a trabalhar num projeto com outros 100 developers. Cada um trata de uma parte específica da aplicação. Como garantir que todos estão a falar a mesma língua? Como evitar que o código se transforme numa Torre de Babel digital?

É aí que entra a arquitetura. Ela não se trata apenas de dividir ficheiros ou usar frameworks modernos. Trata-se de criar estruturas que permitam que o código cresça de forma organizada, que seja fácil de manter e que sobreviva ao teste do tempo.

Pense na arquitetura como o projeto de uma cidade. Não sai construindo edifícios aleatoriamente, certo? Precisa de planear onde vão ficar as ruas, os bairros, o sistema de esgotos. No código é a mesma coisa: é preciso definir onde vão estar as diferentes responsabilidades, como os componentes vão comunicar, como lidar com o estado da aplicação.

Quando falamos de arquitetura front-end, não estamos apenas a falar de separar HTML, CSS e JavaScript em ficheiros diferentes (embora isso também seja importante!). Estamos a falar de uma organização muito mais profunda, que pode incluir:

• Camada de Apresentação: Responsável pela interface visual (HTML/CSS)
• Camada de Aplicação: Gere o estado e a navegação
• Camada de Domínio: Implementa as regras de negócio
• Camada de Dados: Ocupa-se da comunicação com APIs e armazenamento

Esta divisão em camadas não é muito diferente do que vemos no back-end com a Clean Architecture. E não é coincidência! Os princípios de uma boa arquitetura de software são universais.

O Back-end do Front-end (BFF)

Calma, não é uma nova boys band! BFF, neste contexto, significa "Backend For Frontend". É uma camada intermédia entre o front-end e os vários microserviços do back-end. (Já inclusive publicamos um artigo sobre BFF aqui no DevCafe!)

Pensa assim: antigamente, tinhas um monólito no back-end que fazia tudo. Depois vieram os microserviços, que são ótimos para o back-end, mas podem complicar a vida à frente. Imagina ter de fazer dezenas de chamadas a diferentes APIs só para montar uma única página!

O BFF resolve isso. Atua como um agregador, fazendo todas estas chamadas para o front-end e entregando os dados já mastigadinhos, da forma que o front-end precisa. Menos dores de cabeça para os devs front-end, menos tráfego de rede, todos felizes!

Micro Front-ends: Dividir para conquistar

Se pensava que os microserviços eram só coisa do back-end, surpresa! O conceito de micro front-ends está aí para provar o contrário. A ideia é aplicar os mesmos princípios dos microserviços no front-end.

Em vez de ter uma aplicação front-end monolítica, divide-a em pedaços mais pequenos, cada um responsável por uma funcionalidade específica. Cada micro front-end pode ser desenvolvido, testado e implementado de forma independente.

Imagina um site de e-commerce. Poderia ter um micro front-end para o catálogo de produtos, outro para o carrinho de compras, outro para o sistema de pesquisa... Cada um destes poderia ser desenvolvido por equipas diferentes, utilizando até tecnologias diferentes se fizer sentido.

SOLID no Front-end? Sim, é possível!

Provavelmente já ouviu falar dos princípios SOLID se trabalha com orientação a objectos. Mas aplicar estes princípios no front-end? Isto pode parecer estranho à primeira vista, mas faz todo o sentido quando pensamos em componentes modernos.

O princípio da Responsabilidade Única (S do SOLID), por exemplo, é super aplicável: um componente deve ter uma única razão para mudar. Se tem um componente que tanto procura dados como os renderiza e ainda gere estado, talvez esteja na altura de dividir essas responsabilidades.

Frameworks: Vilões ou bons bons?

Ah, os frameworks! React, Angular, Vue... Vieram para nos facilitar a vida ou para complicar tudo? A resposta, como sempre na programação, é: depende!

Os frameworks modernos trouxeram conceitos importantes, como a componentização, que ajudam bastante na organização do código. Mas é verdade que também acrescentam a sua própria camada de complexidade.

A questão é: a complexidade dos frameworks vem normalmente resolver problemas reais que enfrentamos em aplicações de maior dimensão. O truque é saber quando é que esta complexidade adicional se justifica. Para um site simples de poucas páginas? Talvez seja um exagero. Para uma aplicação web complexa utilizada por milhões de pessoas? Aí a coisa muda de figura.

Performance: Não é só porque se pode fazer que se deve fazer

Um ponto importante quando falamos de arquitetura front-end é a performance. Lá porque temos computadores mais potentes e ligações mais rápidas, não significa que possamos esbanjar recursos.

Lembra-se daquele site que faz o seu portátil querer levantar voo? Pois, provavelmente há um JavaScript a correr solto por lá. Uma boa arquitetura front-end também se preocupa em otimizar a utilização dos recursos.

E não é só pelo seu computador, não. Pense nos utilizadores que vão aceder ao seu site a partir de um telemóvel com uma ligação 3G instável. Cada kilobyte conta! É aí que entram técnicas como lazy loading, code splitting, e otimização de assets.

O fator humano na arquitetura

Um aspeto da arquitetura que por vezes é esquecido é o fator humano. Não estamos a falar apenas de código, mas de como as equipas estão organizadas.

A arquitetura do seu sistema reflete muitas vezes a estrutura da sua organização. É o famoso "Lei de Conway". Se tiver equipas muito separadas, provavelmente vai acabar com um sistema mais modular. Se tem uma equipa única e coesa, pode acabar com um monolito.

Não existe aqui um certo ou errado absoluto. O importante é que a arquitetura escolhida faça sentido para a realidade da sua equipa e do seu projeto.

Trade-offs: A Palavra mágica da arquitectura

No final de contas, a arquitetura é fazer escolhas. Cada decisão que toma traz vantagens e desvantagens. Quer usar micro front-ends? Ótimo para escalabilidade, mas acrescenta complexidade na integração. Prefere um monólito front-end? Mais simples de início, mas pode tornar-se difícil de manter à medida que cresce.

O segredo está em perceber bem o seu contexto, as necessidades do seu projeto e da sua equipa. Não existe bala de prata em arquitetura. O que funciona para o Facebook pode ser um pesadelo para a sua app de listas de tarefas.

E lembre-se: a arquitetura não é algo que se define uma vez e se esquece. É um processo contínuo de avaliação e adaptação. O que funciona hoje pode não ser o ideal amanhã, à medida que o seu projeto evolui.

A Maturidade do Front-end

O desenvolvimento front-end tem crescido muito nos últimos anos. Frameworks como React, Angular e Vue.js trouxeram novas possibilidades e desafios. O React, por exemplo, auto-intitula-se de biblioteca, dando-lhe liberdade para organizar o seu código como preferir. Já o Angular é mais opinativo, proporcionando um ecossistema mais completo e estruturado.

E sabe o que é mais interessante? Essa evolução continua a acontecer. Conceitos como Server Components, Islands Architecture e Resumability estão a mudar a forma como pensamos na arquitetura front-end.

No final de contas, o importante é lembrar que a arquitetura não se trata de seguir regras rígidas ou usar as últimas tecnologias. Trata-se de criar soluções que resolvam problemas reais, sejam sustentáveis ​​a longo prazo e facilitem o trabalho em equipa. E sim, por vezes o melhor código é aquele que resolve o problema atual da forma mais simples possível, mesmo que não siga todos os padrões do momento.

Afinal, como se diz por aí: o melhor código é aquele que funciona e que outras pessoas conseguem compreender e manter. E se está a começar agora, não se assuste com todos estes conceitos. Comece pelo básico, perceba bem os fundamentos, e vá incorporando conceitos mais avançados à medida que a sua aplicação e a sua equipa crescem.

Enfim, malta, esperamos que este passeio pelo mundo da arquitetura front-end tenha sido esclarecedor. Da próxima vez que alguém disser que o front-end é só "fazer um site bonito", já sabem: há muito mais por baixo do capot! Continuem a estudar, a experimentar e, acima de tudo, a construir coisas incríveis. O futuro da web está nas suas mãos!