O mundo mudou para a internet, e aplicativos web se tornaram os novos locais de trabalho e lojas comerciais. Para acomodar a variedade de propósitos que os aplicativos web modernos servem, cada um deles precisa ser projetado para alta performance e customização.
Arquiteturas de aplicativos web resolvem este problema.
A arquitetura de aplicativos web define como os vários componentes de um aplicativo baseados na web são estruturados. Esta arquitetura é altamente específica para a natureza e o propósito do aplicativo web. Escolher a arquitetura errada para o seu aplicativo web pode causar estragos em seu negócio.
Neste artigo, vamos detalhar o conceito de arquitetura de aplicativos web e entender como isso afeta a experiência do usuário final do seu aplicativo. No final, também analisaremos algumas das melhores práticas que você pode implementar para obter o máximo do seu aplicativo web.
O que é arquitetura de aplicativos web?
Para iniciar a discussão, vamos começar com a definição da arquitetura de aplicativos web.
Em palavras simples, a arquitetura de aplicativos web é um esboço de como vários componentes do seu aplicativo web interagem entre si.
Pode ser tão simples quanto definir o relacionamento entre o cliente e o servidor. Também pode ser tão complexo quanto definir as inter-relações entre um enxame de servidores, backend de contêineres, balanceadores de carga, gateways API e frontend de página única voltados para o usuário.
Dito isto, raramente se trata de escolher a linguagem de programação na qual você vai escrever seu código.
Como você projeta seu aplicativo web tem um papel fundamental tanto em sua usabilidade quanto em sua otimização de custos. Veja como é um exemplo de arquitetura de aplicativos web no papel:
Por que a arquitetura de aplicativos web é importante?
A arquitetura do aplicativo web é, sem dúvida, uma das partes mais importantes do seu aplicativo web. Caso você optar por desenvolver seu aplicativo web com uma arquitetura específica em mente, você certamente receberá muitos benefícios quando se trata de manter e crescer seu aplicativo.
Entretanto, a escolha da arquitetura certa, amplifica ainda mais esses benefícios.
Aqui estão algumas das principais razões pelas quais você deve considerar seriamente a adoção de uma arquitetura de aplicativos web.
Fácil adaptação às necessidades da empresa
Seu aplicativo é uma porta de entrada chave para o seu negócio, e às necessidades do negócio evoluem com as mudanças do mercado. Para manter-se atualizado, você vai querer que seu aplicativo seja flexível o suficiente para se adaptar às suas necessidades da empresa em constante mudança. E se você construir um aplicativo sem considerar a flexibilidade embutida, você estará sujeito a gastar cada vez mais tempo e esforço fazendo pequenos ajustes em seu aplicativo.
A arquitetura correta do aplicativo web já é responsável por algumas das mudanças que seu negócio pode precisar no futuro. Por exemplo, se você sabe que está construindo um aplicativo de eCommerce que irá escalar e atender uma ampla gama de serviços para um grande número de clientes um dia, escolher uma arquitetura de microsserviços em vez de uma arquitetura monolítica lhe proporcionaria mais flexibilidade.
Por outro lado, se você está construindo um aplicativo interno para sua empresa com apenas um ou dois requisitos fixos, você pode optar por um monólito mais simples para acelerar o desenvolvimento e manter sua base de código limpa.
Desenvolvimento organizado
Como mencionamos anteriormente, a arquitetura correta do aplicativo web fornece a você um itinerário mais conveniente para o desenvolvimento. A arquitetura fornece modularidade suficiente em seu sistema para isolar componentes conforme necessário, e você tem a liberdade de escolher a estrutura de projeto certa para cada um de seus módulos e componentes conforme necessário.
O desenvolvimento de aplicativos sem uma arquitetura em mente, você arrisca perder tempo e dinheiro reorganizando seus componentes e estabelecendo novas regras para ajudar a facilitar a colaboração entre os membros da sua equipe – tempo e dinheiro que de outra forma poderiam ter sido gastos em outro lugar.
Melhor gerenciamento da base de código
Além de escrever o código do seu aplicativo, você também vai gastar um tempo considerável gerenciando-o. Organizar seus arquivos de projeto, quebrar seu aplicativo em módulos e configurar pipelines personalizados são apenas algumas das tarefas que requerem manutenção ativa para garantir um desenvolvimento suave.
A arquitetura correta do aplicativo web facilita você fazer mudanças. Você pode implementar melhores práticas específicas para cada componente, separar os pontos de dor do seu aplicativo uns dos outros e manter cada recurso independente e frouxamente acoplado. Não é que essas coisas não possam ser feitas sem arquitetura; é que a arquitetura certa torna tudo muito mais simples.
Seguir uma arquitetura pré-definida também facilita o desenvolver de seus aplicativos mais rapidamente. A arquitetura certa combinada com uma sólida estratégia de controle de versão pode permitir que seus desenvolvedores trabalhem em paralelo entre si e construam recursos mais rapidamente.
A arquitetura de aplicativos web também prova seu aplicativo para o futuro. Assim que você definir uma estratégia sólida sobre como organizar os componentes do seu aplicativo, você pode facilmente migrar esses componentes para tecnologias mais novas, sem ter que refazer todo o seu aplicativo.
Segurança aprimorada
A maioria das arquiteturas de aplicativos consideram a segurança ao estruturar os componentes. Os desenvolvedores podem planejar, antes do tempo, às medidas e práticas a serem implementadas para melhorar a segurança do aplicativo antes que ele seja lançado para os usuários.
Por exemplo, construir um aplicativo de streaming de vídeo que oferece tanto conteúdo pago quanto gratuito usando microsserviços faz mais sentido, porque a arquitetura dos microsserviços permite dividir seu aplicativo em componentes adaptados às necessidades comerciais, tais como autenticação de usuário e streaming de conteúdo gratuito ou pago. Caso o seu módulo de autenticação de usuário falhar, você pode facilmente configurar seu aplicativo para restringir o acesso ao módulo de conteúdo pago até que a autenticação seja restaurado, enquanto o módulo de conteúdo gratuito permanece disponível para seus usuários.
Em um caso alternativo em que este mesmo aplicativo fosse projetado como um monólito estreitamente acoplado, levaria um serviço de autenticação em baixa ou um conteúdo pago sendo disponibilizado gratuitamente – resultados que você gostaria de evitar a todo custo.
Como funciona a arquitetura de aplicativos web?
Antes de falarmos sobre como a arquitetura de aplicativos web funciona, é importante entender como funciona um site simples:
- O usuário entra na URL do seu aplicativo na barra de endereços do navegador ou clica em um link.
- O navegador procura a URL nos servidores DNS e identifica o endereço IP do seu aplicativo.
- O navegador envia uma solicitação HTTP para o seu aplicativo.
- Seu aplicativo responde com o conteúdo correto (geralmente uma página da internet).
- O navegador torna a página da internet na tela.
Se você fosse um pouco mais fundo, aqui está como um aplicativo web lidaria com um pedido:
- O usuário envia uma solicitação para seu aplicativo através da sua interface de usuário frontend.
- Se você tiver um cache relevante configurado, o aplicativo primeiro verifica se ele tem um registro válido que pode ser enviado de volta ao cliente diretamente. Se sim, o conteúdo em cache será enviado de volta, e a solicitação será marcada como concluída.
- Se não houver cache, a solicitação é encaminhada para os balanceadores de carga.
- O balanceador de carga identifica uma instância do servidor que está disponível para lidar com a solicitação e a encaminha.
- A instância do servidor processa a requisição e chama quaisquer APIs externas, se necessário.
- Uma vez que os resultados são coletados em um lugar, o servidor envia de volta a resposta ao balanceador de carga.
- O balanceador de carga retorna a resposta para o gateway API, que por sua vez, envia para o usuário no cliente frontend. A solicitação é então marcada como concluída.
Tipos de arquitetura de aplicativos web
Agora que você tem uma ideia básica do que é arquitetura de aplicativos web, vamos dar uma olhada detalhada em alguns dos tipos populares de arquitetura de aplicativos web usados em toda a internet.
Arquitetura de página única
A arquitetura de aplicativos de página única (Single-Page Application ou SPA) é tão simples quanto seu nome: o aplicativo inteiro é baseada em uma única página. Uma vez que o usuário baixa o seu aplicativo, ele não precisa navegar para qualquer outra página da internet. O aplicativo é tornado dinâmico o suficiente para buscar e renderizar telas que atendam aos requisitos dos usuários enquanto eles navegam pelo próprio aplicativo.
Os SPAs são ótimos quando se trata de fornecer uma experiência rápida e perfeita para os usuários finais ou consumidores. Entretanto, eles não possuem o toque de um site tradicional e podem ser difíceis de otimizar para SEO.
Vantagens da arquitetura SPA
Alguns dos prós da arquitetura SPA incluem:
- Você pode construir aplicativos web altamente interativas.
- Os SPAs são fáceis de escalar.
- Otimizar o SPA para desempenho não requer muito esforço.
Contras da arquitetura SPA
Alguns dos inconvenientes da arquitetura de SPA são:
- SPA limitam a flexibilidade com hiperlinks e SEO.
- A renderização inicial é normalmente lenta.
- A navegação através do aplicativo pode ser pouco intuitiva.
Arquitetura progressiva de aplicativos web
A arquitetura Progressive Web Application (PWA) é construída com base na Arquitetura de Página Única, fornecendo capacidades offline para o aplicativo web. Tecnologias como Capacitor e Ionic são usadas para construir PWAs que podem fornecer aos usuários uma experiência uniforme entre plataformas.
Semelhantes ao SPA, os PWAs são suaves e sem problemas. Com a capacidade adicional de serem instalados em dispositivos do usuário (por workers de serviço), seus usuários obtêm uma experiência mais uniforme com seu aplicativo.
Ao mesmo tempo, pode ser difícil otimizar tais aplicativos para SEO, e atualizações em aplicativos instalados podem ser difíceis de serem empurradas.
Prós da arquitetura PWA
Há muitos benefícios da arquitetura do PWA, inclusive:
- Os aplicativos funcionam de forma muito suave e oferecem compatibilidade entre plataformas.
- A escalabilidade é simples.
- Acesso off-line e APIs nativas do dispositivo, como workers em segundo plano e notificações push, são acessíveis aos desenvolvedores.
Contras da arquitetura PWA
Alguns dos contras da arquitetura do PWA podem incluir:
- Há um suporte limitado para gerenciamento de links e SEO.
- Mover atualizações para PWA offline é mais complexo do que com aplicativos nativos.
- Há um suporte limitado para PWA em navegadores de internet e sistemas operacionais.
Arquitetura renderizada do lado do servidor
Na renderização do lado do servidor (SSR), às páginas da internet frontend são renderizadas em um servidor backend após serem solicitadas pelo usuário. Isto ajuda a reduzir a carga no dispositivo cliente ao receber um HTML estático, CSS, e JS webpage.
Os aplicativos SSR são muito populares entre os blogs e sites de eCommerce. Isto porque eles tornam o gerenciamento de links e SEO bastante simples. Além disso, a primeira renderização para aplicativos SSR é bastante rápida, já que o cliente não precisa processar nenhum código JS para renderizar às telas.
Prós da Arquitetura SSR
Alguns dos prós da arquitetura SSR estão listados abaixo:
- Estes aplicativos são ótimos para sites pesados em SEO.
- O carregamento da primeira página é quase instantânea na maioria dos casos.
- Você pode combiná-lo com um serviço de cache para melhorar ainda mais o desempenho do seu aplicativo.
Contras da arquitetura SSR
Alguns dos inconvenientes de usar a arquitetura SSR incluem:
- Não é recomendado para páginas de internet complexas ou pesadas, uma vez que o servidor pode levar tempo para gerar totalmente a página, resultando em um atraso na primeira renderização.
- Ele é recomendado principalmente para aplicativos que não focam muito na interface do usuário e estão apenas procurando por uma maior escalabilidade ou segurança.
Arquitetura de aplicativos pré-renderizadas
A arquitetura de aplicativos pré-renderizadas também é conhecida como arquitetura de geração de sites estática. Nesta arquitetura, às páginas de internet frontend do aplicativo são pré-geradas e armazenadas como arquivos HTML, CSS e JS simples no servidor. Uma vez que um usuário solicita uma página, ela é diretamente buscada e mostrada a ele. Isto torna o aplicativo web muito rápido, com tempos de carregamento mínimos de qualquer tipo. Entretanto, esta arquitetura aumenta o tempo de construção do aplicativo, uma vez que às páginas de internet são renderizadas durante o processo de construção.
aplicativos web pré-renderizadas são ótimas para quando você está procurando gerar conteúdo estático, como blogs ou detalhes de produtos que não mudam com frequência. Você também pode recorrer a templates para simplificar o design da sua página de internet. No entanto, é quase impossível construir aplicativos web dinâmicos com esta arquitetura. Se você está procurando construir uma página de pesquisa que leva a consulta em seu caminho (algo como https://myapp.com/search/foo+bar), você está no lugar errado.
Como cada rota possível do aplicativo é pré-renderizada durante o processo de construção, é impossível ter caminhos dinâmicos como acima, já que há infinitas possibilidades que não podem ser pré-renderizadas durante a construção (e também não faz sentido fazer isso).
Prós da arquitetura pré-renderizada
Alguns dos principais benefícios da arquitetura de aplicativos pré-renderizadas são:
- As páginas de internet são geradas em HTML puro, CSS e JS; portanto, seu desempenho é similar ao dos aplicativos construídos usando o vanilla JS.
- Se você conhece todas os caminhos possíveis do seu aplicativo, SEO se torna super fácil.
Contras da arquitetura pré-renderizada
Como em qualquer modelo arquitetônico, o pré-renderizado tem sua quota-parte de inconvenientes:
- Conteúdo dinâmico não pode ser servido com estes aplicativos.
- Fazer qualquer mudança no aplicativo web significa reconstruir e implantar o aplicativo completamente do zero.
Arquitetura de aplicativos isomórficos
Aplicativos isomórficos são aquelas que são uma mistura de aplicativos renderizadas do lado do servidor e SPAs. Isto significa que tais aplicativos são primeiro renderizadas no servidor como um aplicativo normal renderizada do lado do servidor. Uma vez que eles são recebidos pelo cliente, o aplicativo se hidrata e anexa o DOM virtual para um processamento mais rápido e eficiente do cliente. Isto essencialmente transforma o aplicativo em um aplicativo de uma única página.
Isomórfico reúne o melhor dos dois mundos. Você obtém um processamento super rápido e uma interface de usuário no cliente, graças ao SPA. Você também obtém renderização inicial rápida e SEO completo e suporte a links, graças à renderização do lado do servidor.
Prós da arquitetura isomórfica
Aqui estão apenas alguns dos benefícios de usar a arquitetura de aplicativo isomórfico:
- Aplicativos isomórficos têm renderização inicial super rápida e suporte total a SEO.
- Estes aplicativos também têm um bom desempenho para o cliente, uma vez que se transformam em um SPA após o carregamento.
Contras da arquitetura Isomórfica
Alguns dos consensos da arquitetura de aplicativos isomórficos podem ser:
- A criação de um aplicativo deste tipo requer talento qualificado.
- As opções da pilha de tecnologia são limitadas quando se trata de projetar um aplicativo isomórfico. Você só pode escolher entre um punhado de bibliotecas e frameworks (em sua maioria) baseados em JS.
Arquitetura orientada a serviços
A arquitetura orientada a serviços (Service-Oriented Architecture ou SOA) está entre às alternativas mais populares para a forma tradicional monolítica de construir aplicativos. Nesta arquitetura, os aplicativos web são divididas em serviços que representam uma unidade funcional de negócios cada uma. Estes serviços são acoplados frouxamente e interagem uns com os outros através da passagem de mensagens.
A arquitetura orientada a serviços adiciona estabilidade e escalabilidade à sua pilha de tecnologia do aplicativo. Entretanto, o tamanho dos serviços em SOA não está claramente definido e está normalmente ligado a componentes comerciais, não a componentes técnicos; portanto, a manutenção às vezes pode ser um problema.
Prós da arquitetura orientada a serviços
Os principais benefícios da arquitetura orientada a serviços incluem:
- Esta arquitetura ajuda a construir aplicativos altamente escaláveis e confiáveis.
- Os componentes são reutilizáveis, sendo compartilhados para melhorar os esforços de desenvolvimento e manutenção.
Contras da arquitetura orientada a serviços
Aqui está uma lista de potenciais inconvenientes para o uso de uma arquitetura orientada a serviços:
- Os aplicativos SOA ainda não são 100% flexíveis, uma vez que o tamanho e o escopo de cada serviço não são fixos. Pode haver serviços do tamanho de aplicativos empresariais que podem ser difíceis de manter.
- O compartilhamento de componentes introduz dependências entre os serviços.
Arquitetura de microsserviços
A arquitetura de microsserviços foram projetadas para resolver os problemas com a arquitetura orientada a serviços. Os microsserviços são componentes ainda mais modulares que se encaixam para construir um aplicativo web. Entretanto, os microsserviços se concentram em manter cada componente pequeno e com um contexto limitado. Contexto limitado significa essencialmente que cada microsserviço tem seu código e dados unidos com o mínimo de dependências de outros microsserviços.
A arquitetura de microsserviços é provavelmente a melhor arquitetura para construir aplicativos que visam escalar para milhares e milhões de usuários algum dia. Cada componente é flexível, escalável e fácil de manter. Entretanto, a manutenção do ciclo de vida do DevOps para um aplicativo baseado em microsserviços requer esforços adicionais; portanto, ele pode não ser adequado para casos de uso menores.
Prós da arquitetura de microsserviços
Alguns dos prós da arquitetura de microsserviços incluem:
- Os componentes dos aplicativos são altamente modulares, independentes e podem ser reutilizados em maior extensão do que aqueles da arquitetura orientada a serviços.
- Cada componente pode ser escalado independentemente para atender ao tráfego variável de usuários.
- Os aplicativos baseados em microsserviços são altamente tolerantes a falhas.
Contras da arquitetura de microsserviços
Uma desvantagem da arquitetura de microsserviços pode ser:
- Para projetos menores, a arquitetura de microsserviços pode exigir muito esforço de manutenção.
Arquitetura sem servidor
A arquitetura sem servidor é outro candidato no mundo das arquiteturas de aplicativos web. Esta arquitetura se concentra em quebrar seu aplicativo em termos das funções que ela deve realizar. Então estas funções são hospedadas em plataformas FaaS (Function-as-a-Service) como funções que são invocadas à medida que solicitam.
Ao contrário da maioria das outras arquiteturas desta lista, aplicativos construídos usando a arquitetura sem servidor não ficam rodando o tempo todo. Eles se comportam como funções fariam – esperar por serem chamados, e ao serem chamados, executar o processo definido e retornar um resultado. Devido a esta natureza, eles reduzem os custos de manutenção e são altamente escaláveis sem muito esforço. Entretanto, é difícil realizar tarefas de longa duração usando tais componentes.
Prós da arquitetura sem servidor
Aqui estão os principais benefícios da arquitetura sem servidor:
- Aplicativos sem servidor são facilmente escaláveis. Eles podem até mesmo se adaptar ao tráfego de entrada em tempo real para reduzir a carga em sua infraestrutura.
- Tais aplicativos podem usar o modelo de preços “Pague apenas pelo que utilizar” (pay-per-use) das plataformas sem servidor para reduzir os custos de infraestrutura.
- Aplicativos sem servidor são bastante fáceis de construir e implementar já que tudo que você tem que fazer é escrever uma função e hospedá-la em uma plataforma como funções Firebase, AWS Lambda, etc.
Contras da arquitetura sem servidor
Abaixo estão alguns dos inconvenientes da arquitetura sem servidor:
- Tarefas de longa duração podem ser caras para se fazer em tal arquitetura.
- Quando uma função recebe uma solicitação após um longo tempo, ela é conhecida como um cold start. Cold starts são lentas e podem proporcionar uma má experiência para o seu usuário final.
Camadas de arquitetura de aplicativos web
Enquanto as arquiteturas de aplicativos web que você viu acima podem parecer todas bem diferentes umas das outras, seus componentes podem ser logicamente agrupados em camadas definidas que ajudam a atingir um objetivo de negócios.
Camada de apresentação
A camada de apresentação é responsável por tudo em um aplicativo web, que é exposto aos usuários finais. Primeiramente, a camada de apresentação é composta pelo cliente frontend. No entanto, ela também incorpora qualquer lógica que você tenha escrito em seu backend para tornar seu frontend dinâmico. Isto lhe dá o espaço para servir seus usuários com interface personalizada de acordo com seu perfil e exigências.
Três tecnologias fundamentais são usadas para construir esta camada: HTML, CSS, e JavaScript. O HTML estabelece seu frontend, o CSS o estiliza, e o JS coloca vida nele (ou seja, controla seu comportamento quando os usuários interagem com ele). Além dessas três tecnologias, você pode usar qualquer tipo de framework para ajudar a facilitar o seu desenvolvimento. Alguns frameworks frontend comuns incluem Laravel, React, NextJS, Vue, GatsbyJS, etc.
Camada de negócios
A camada de negócios é responsável por manter e gerenciar a lógica de trabalho do seu aplicativo. Geralmente é um serviço backend que aceita solicitações do cliente e as processa. Ele controla o que o usuário pode acessar e determina como a infraestrutura é utilizada para atender as solicitações dos usuários.
No caso de um aplicativo de reserva de hotel, seu aplicativo cliente serve como um portal para os usuários digitarem os nomes dos hotéis e outros dados relevantes. No entanto, assim que o usuário clica no botão de pesquisa, a camada empresarial recebe a solicitação e inicia a lógica de procura de quartos de hotel disponíveis que atendam às suas necessidades. O cliente então apenas recebe uma lista de quartos de hotel sem qualquer conhecimento de como esta lista foi gerada ou mesmo porque os itens da lista estão dispostos da forma como foram enviados.
A presença de tal camada assegura que sua lógica comercial não seja exposta ao seu cliente e aos usuários. O isolamento da lógica de negócios ajuda imensamente em operações sensíveis, como o manuseio de pagamentos ou o gerenciamento de registros de saúde.
Camada de persistência
A camada de persistência é responsável por controlar o acesso aos seus armazéns de dados. Isto atua como uma camada adicional de abstração entre seus datas tores e sua camada de negócios. Ele recebe todas as chamadas relacionadas aos dados das camadas de negócios e as processa fazendo conexões seguras com o banco de dados.
Esta camada geralmente consiste em um servidor do banco de dados. Você mesmo pode configurar esta camada provisionando um banco de dados e um servidor do banco de dados em sua infraestrutura on-prem ou optar por uma solução remota/gerenciada por um dos principais provedores de infraestrutura de nuvem como AWS, GCP, Microsoft Azure, etc.
Componentes de aplicativos web
Agora que você entende o que vai para uma arquitetura de aplicativos web, vamos dar uma olhada detalhada em cada um dos componentes que compõem um aplicativo web. Vamos agrupar esta discussão em dois grandes cabeçalhos – componentes do lado do servidor e componentes do lado do cliente, ou componentes backend e frontend.
Componentes do lado do servidor
Os componentes do lado do servidor são aqueles que residem no backend do seu aplicativo web. Estes não são expostos diretamente aos usuários e possuem a mais importante lógica de negócios e recursos para o seu aplicativo web.
DNS & Roteamento
O DNS é responsável por controlar como o seu aplicativo é exposto na internet. Os registros DNS são usados por clientes HTTP, que também podem ser um navegador, para encontrar e enviar solicitações para os componentes do seu aplicativo. O DNS também é usado por seus clientes frontend internamente para resolver a localização de seus servidores web e endpoints de API para enviar solicitações e processar as operações dos usuários.
O balanceamento de carga é outro componente popular da arquitetura de aplicativos web. Um balanceador de carga é usado para distribuir solicitações HTTP entre vários servidores web idênticos. A intenção por trás de ter múltiplos servidores web é manter uma redundância que ajuda a aumentar a tolerância a falhas, bem como distribuir tráfego para manter um alto desempenho.
Os endpoints API são usados para expor os serviços backend o aplicativo frontend. Estes ajudam a facilitar a comunicação entre o cliente e o servidor, e às vezes até mesmo entre múltiplos servidores também.
Armazenamento de dados
O armazenamento de dados é uma parte crucial da maioria dos aplicativos modernos, pois há sempre alguns dados de aplicativo que precisam ser persistidos durante as sessões do usuário. O armazenamento de dados é de dois tipos:
- Bancos de dados: Os bancos de dados são usados para armazenar dados para acesso rápido. Normalmente, eles suportam o armazenamento de uma pequena quantidade de dados que é acessada regularmente pelo seu aplicativo.
- Armazéns de dados: Armazéns de dados são projetados para a preservação de dados históricos. Estes geralmente não são necessários com muita frequência no aplicativo, mas são processados regularmente para gerar insights comerciais.
Cache
O cache é um recurso opcional frequentemente implementado em arquiteturas de aplicativos web para servir conteúdo mais rapidamente para os usuários. Uma grande parte do conteúdo do aplicativo é frequentemente repetitiva por algum tempo, se não sempre. Ao invés de acessá-lo a partir de um armazenamento de dados e processá-lo antes de enviá-lo de volta para o usuário, ele é frequentemente colocado em cache. Aqui estão os dois tipos mais populares de cache usados em aplicativos web:
- Cache de dados: O cache de dados introduz uma maneira do seu aplicativo acessar fácil e rapidamente dados usados regularmente que não mudam com frequência. Tecnologias como Redis e Memcache permitem o cache de dados para economizar em consultas caras a bancos de dados apenas para recuperar os mesmos dados repetidamente.
- Cache de páginas de internet: Um CDN (Content Delivery Network) faz o cache de páginas de internet da mesma forma que o Redis faz o cache de dados. Semelhante a como somente dados que não mudam com frequência são armazenados em cache, geralmente somente páginas de internet estáticas são recomendadas para serem armazenadas em cache. Para aplicativos web renderizados do lado do servidor, o cache não faz muito bem, uma vez que seu conteúdo é supostamente altamente dinâmico.
Jobs e serviços
Além de expor uma interface aos usuários (frontend) e lidar com seus pedidos (backend), há outra categoria um pouco menos popular de componentes de aplicativos web. Os jobs são frequentemente serviços de fundo que são destinados a completar tarefas que não são sensíveis ao tempo ou síncronas.
Os CRON Jobs são aqueles realizados durante um período fixo de tempo repetidamente. Estes Jobs são programados no backend para executar rotinas de manutenção automaticamente em horários definidos. Alguns exemplos comuns de casos de uso para estes incluem a eliminação de duplicatas/ registros antigos do banco de dados, envio de e-mails de lembrete aos clientes, etc.
Componentes do lado do cliente
Os componentes do lado do cliente são aqueles sendo expostos aos seus usuários direta ou indiretamente.
Há principalmente dois tipos de componentes nesta categoria.
Interface do usuário frontend
A interface do usuário é o aspecto visual do seu aplicativo. É com ela que seus usuários veem e interagem a fim de acessar seus serviços.
A interface frontend é construída em sua maioria sobre três tecnologias populares: HTML, CSS, e JavaScript. A interface do usuário do frontend pode ser um aplicativo em si mesma com seu próprio ciclo de vida de desenvolvimento de software.
Estas interfaces de usuário não abrigam muita da sua lógica de negócios, uma vez que elas são expostas diretamente aos seus usuários. Caso um usuário malicioso tentar fazer engenharia reversa em seu aplicativo frontend, eles podem obter informações sobre como seu negócio funciona e realizar atividades ilegais como personificação de marca e roubo de dados.
Além disso, como a interface do usuário frontend é exposta diretamente aos usuários, você vai querer otimizá-la para um tempo mínimo de carregamento e capacidade de resposta. Às vezes isso pode ajudá-lo a fornecer uma melhor experiência aos seus usuários, aumentando assim o crescimento do seu negócio.
Lógica comercial do lado do cliente
Algumas vezes você pode precisar armazenar alguma lógica comercial em seu cliente para poder realizar operações mais simples rapidamente. A lógica do lado do cliente que normalmente reside dentro do seu aplicativo frontend pode ajudar evitando a viagem ao servidor e fornecer aos seus usuários uma experiência mais rápida.
Esta é uma característica opcional dos componentes do lado do cliente. Em alguns casos, a lógica comercial do aplicativo é armazenada inteiramente no lado do cliente (especialmente quando se constrói sem um servidor backend tradicional). Soluções modernas como o BaaS ajudam você a acessar operações comuns como autenticação, armazenamento de dados, armazenamento de arquivos, etc., em movimento no seu aplicativo frontend.
Existem maneiras de ofuscar ou minifique este código antes de enviá-lo aos seus usuários para minimizar as chances de engenharia reversa.
Modelos de componentes de aplicativos web
Existem múltiplos modelos de arquiteturas de aplicativos web, cada um baseado em como os servidores web se conectam aos seus armazéns de dados.
Um servidor, um banco de dados
O modelo mais simples de todos é um servidor web conectando-se a uma instância do banco de dados. Tal modelo é fácil de implementar e manter, e ir para produção com ele também é bastante fácil.
Devido à sua simplicidade, este modelo é adequado para o aprendizado e para pequenos aplicativos experimentais que não serão expostas ao alto tráfego. Desenvolvedores novatos podem facilmente configurar e mexer com estes aplicativos para aprender os fundamentos do desenvolvimento de aplicativos web.
No entanto, este modelo não deve ser usado na produção, uma vez que é altamente duvidoso. Um problema no servidor ou no banco de dados pode resultar em tempo de inatividade e perda de negócios.
Múltiplos servidores, um banco de dados
Este modelo eleva o nível do aplicativo através da configuração de múltiplos servidores para redundância com uma única instância comum do banco de dados.
Como vários servidores web acessam o banco de dados simultaneamente, podem ocorrer problemas de inconsistência. Para evitar isso, os servidores web são projetados para serem sem estado. Isto significa que os servidores não retêm dados durante as sessões; eles simplesmente os processam e armazenam no banco de dados.
Os aplicativos criados usando este modelo são certamente mais confiáveis do que aqueles com o modelo anterior, já que a presença de múltiplos servidores web aumenta a tolerância a falhas do aplicativo web. Entretanto, como o banco de dados ainda é uma instância comum, ele é o elo mais fraco na arquitetura e pode ser uma fonte de falhas.
Múltiplos servidores, múltiplos bancos de dados
Este modelo é um dos modelos mais comuns e tradicionais de projetar aplicativos web.
Neste caso, implante sua lógica de aplicativo como múltiplas instâncias idênticas de servidores web agrupadas atrás de um balanceador de carga. Seu armazenamento de dados também é mantido em múltiplas instâncias do banco de dados para maior tolerância a falhas.
Você também pode optar por dividir seu banco de dados entre as instâncias disponíveis para melhorar o desempenho ou manter duplicatas de todo o armazenamento de dados para redundância. Em ambos os casos, a falha em qualquer instância do seu banco de dados não levará a uma paralisação completa do aplicativo.
Este modelo é altamente apreciado por sua confiabilidade e escalabilidade. Entretanto, desenvolver e manter aplicativos usando este modelo é relativamente complicado e requer desenvolvedores experientes e caros. Como tal, este modelo só é sugerido quando você está construindo em larga escala.
Serviços de aplicativos
Enquanto os três modelos mencionados acima são bem adequados para aplicativos monolíticas, há um outro modelo para aplicativos modulares.
O modelo de serviços de aplicativo são divididos em módulos menores baseados na funcionalidade da empresa. Estes módulos podem ser tão pequenos quanto uma função ou tão grandes quanto um serviço.
A ideia aqui é tornar cada característica de negócio independente e escalável. Cada um desses módulos pode se conectar ao banco de dados por si só. Você pode até mesmo ter instâncias do banco de dados dedicadas para atender às necessidades de escalabilidade do seu módulo.
Entre os aplicativos não-monolíticas, este modelo é bastante popular. Os monólitos legados são frequentemente migrados para este modelo para usar sua escalabilidade e benefícios de modularidade. Entretanto, o gerenciamento de aplicativos construídos sobre tal modelo muitas vezes requer desenvolvedores experientes, especialmente experiência em DevOps e CI/CD.
Melhores práticas para arquitetura de aplicativos web
Aqui estão algumas das melhores práticas que você pode implementar em seu projeto de aplicativos web para obter o máximo da sua arquitetura do aplicativo web escolhida.
1. Torne seu frontend responsivo
Isto não pode ser estressado o suficiente: sempre vise para ter frontend responsivo. Não importa quão grande e complexo o seu aplicativo web internamente, tudo isso é exposto aos seus usuários através do frontend de páginas web, aplicativos e telas.
Caso seus usuários acharem estas telas pouco intuitivas ou lentas, eles não vão ficar por aqui o tempo suficiente para ver e admirar a maravilha da engenharia do seu aplicativo web.
Portanto, projetar frontend responsivos, fáceis de usar e leves é muito importante.
Existem amplas melhores práticas UI/UX disponíveis na web para ajudá-lo a entender o que funciona melhor para seus usuários. Você pode encontrar profissionais habilitados a fazer projetos e arquiteturas amigáveis que podem permitir que seus usuários tirem o máximo proveito de seus aplicativos.
Aconselhamos pensar seriamente na capacidade de resposta do seu frontend antes de lançar seu produto para seus usuários.
2. Monitore o tempo de carregamento
Além de ser fácil de entender, o frontend também precisa ser rápido ao carregar.
De acordo com Portent, as maiores taxas de conversão de eCommerce ocorrem em páginas com tempos de carregamento entre 0-2 segundos, e de acordo com Unbounce, cerca de 70% dos consumidores admitem que o tempo de carregamento de páginas é um fator importante em sua escolha para comprar de um vendedor on-line.
Ao projetar aplicativos móveis nativas, você normalmente não pode ter certeza das especificações do dispositivo de seus usuários. Qualquer dispositivo que não atenda aos requisitos do seu aplicativo é tipicamente declarado como não compatível com o aplicativo.
No entanto, isto é bem diferente com a web.
Quando se trata de aplicativos web, seus usuários podem estar usando qualquer coisa, desde o mais recente Apple Macbook M1 Pros até telefones antigos Blackberry e Nokia para visualizar seu aplicativo. Otimizar sua experiência de frontend para uma gama tão ampla de usuários pode ser difícil às vezes.
Serviços como o LightHouse e o Google PageSpeed vêm à mente quando se fala sobre o desempenho do frontend. Você deve usar tais ferramentas para comparar seu aplicativo frontend antes de implementá-lo na produção. A maioria dessas ferramentas fornece a você uma lista de dicas acionáveis para ajudar a melhorar o desempenho do seu aplicativo o máximo possível.
Os 5-10% finais do desempenho do aplicativo são geralmente específicos para o seu caso de uso e só podem ser corrigidos por alguém que conhece bem o seu aplicativo e suas tecnologias. Nunca custa investir no desempenho da web!
3. Prefira o PWA sempre que possível
Como discutido anteriormente, os PWAs são os projetos do futuro. Eles podem se encaixar bem na maioria dos casos de uso e fornecem a experiência mais uniforme entre as principais plataformas.
Você deve considerar o uso de PWA para seu aplicativo com a maior frequência possível. A experiência nativa através da web e do celular é extremamente impactante para seus usuários e pode reduzir muito da sua própria carga de trabalho também.
Os PWAs também são rápidos de carregar, fáceis de otimizar e rápidos de construir. Optar por PWAs pode ajudar você a mudar muito do seu foco do desenvolvimento para os negócios desde cedo.
4. Mantenha sua base de código limpa e simples
Uma base de código limpa pode ajudá-lo a identificar e resolver a maioria dos problemas antes que cause danos. Aqui estão algumas dicas que você pode seguir para garantir que sua base de código não esteja causando mais problemas do que deveria.
- Foque na reutilização do código: Manter cópias do mesmo código em toda sua base de código não só é redundante, como também pode causar discrepâncias, tornando sua base de código difícil de manter. Sempre que possível, concentre-se em reutilizar o código.
- Planeje a estrutura do seu projeto: Os projetos de software podem crescer muito com o tempo. Se você não começar com uma estrutura planejada de organização e recursos de código, você pode acabar gastando mais tempo para encontrar arquivos do que para escrever código útil.
- Escreva testes unitários: Cada pedaço de código tem uma chance de quebrar. Testar tudo manualmente não é viável, então você precisa de uma estratégia fixa para automatizar os testes para sua base de código. Os testadores e as ferramentas de Revisão de Código podem ajudá-lo a identificar se os seus esforços de teste unitário estão produzindo os resultados desejados.
- Alta modularidade: Ao escrever código, sempre se concentre na modularidade. Escrever código que está firmemente acoplado a outros pedaços de código torna difícil testar, reutilizar e alterar quando necessário.
5. Automatize seus processos CI/CD
CI/CD significa Integração Contínua e Entrega Contínua. Os processos CI/CD são cruciais para o desenvolvimento do seu aplicativo, pois eles ajudam você a construir, testar e implantar seu projeto com facilidade.
No entanto, você não quer ter que executá-los manualmente a cada vez. Ao invés disso, você deve configurar pipelines que acionem automaticamente com base nas atividades do seu projeto. Por exemplo, você poderia configurar um pipeline que executa seus testes automaticamente sempre que você submete seu código ao seu sistema de controle de versão. Há muitos casos de uso mais complexo, como a geração de artefatos entre plataformas a partir do seu repositório de código sempre que uma versão é criada.
As possibilidades são infinitas, então cabe a você descobrir como você pode tirar o máximo proveito de seus dutos CI/CD.
6. Incorpore recursos de segurança
A maioria dos aplicativos modernas são feitas de múltiplos componentes. Tome como exemplo o seguinte aplicativo:
As solicitações dos clientes são encaminhadas para o aplicativo através de um gateway API. Enquanto este atualmente só permite solicitações diretas ao módulo home do aplicativo, no futuro, ele poderá permitir o acesso a mais componentes sem passar pelo módulo home.
Em seguida, o módulo home verifica um BaaS de autenticação externa antes de permitir o acesso. Uma vez autenticado, o cliente pode acessar as páginas “Atualizar Perfil” ou “Ver Perfil”. Ambas às páginas interagem com uma solução do banco de dados comum e gerenciada que lida com os dados do perfil.
Como você pode ver, o aplicativo parece ser uma versão muito básica e mínima de um diretório de pessoas on-line. Você pode adicionar/atualizar seu próprio perfil ou visualizar outros perfis disponíveis.
Aqui está uma rápida lenda dos vários componentes da arquitetura:
- Caixas azuis: Módulos de aplicativo, que são possivelmente hospedados como microsserviços ou funções sem servidor.
- Caixas vermelhas: Componentes BaaS externos que fornecem autenticação e banco de dados.
- Caixas verdes: Componente de roteamento que modera as solicitações de entrada do cliente.
- Caixa preta: Seu aplicativo cliente exposta ao usuário.
Os componentes de cada uma das cores acima são vulneráveis a vários tipos de ameaças à segurança. Aqui estão algumas construções de segurança que você pode colocar em prática para minimizar sua exposição:
- Módulos de aplicativo (azul): Como estas são funções sem servidor, aqui estão algumas dicas para reforçar sua segurança:
- Isole os segredos do aplicativo e gerencie independentemente do seu código-fonte
- Mantenha controles de acesso através dos serviços do IAM
- Melhore seus esforços de teste para também procurar ameaças à segurança através de técnicas como SAST
- Serviços externos (vermelho):
- Configure controles de acesso através de seus módulos IAM para regular o acesso
- Opte pela limitação da taxa API
- Para serviços como bancos de dados, estabeleça permissões de controle mais precisas, como quem pode acessar os dados dos perfis, quem pode visualizar os dados dos usuários, e muito mais. Muitos serviços, como o Firebase, fornecem um conjunto detalhado de tais regras.
- Componente de roteamento (verde):
- Como todos os outros componentes, implemente controles de acesso
- Configurar autorização
- Checar duas vezes as melhores práticas standard, como CORS
- Cliente:
- Certifique-se de que nenhum segredo do aplicativo esteja disponível para seu cliente
- Ofusque o código do seu cliente para minimizar as chances de engenharia reversa
Embora estas sejam apenas algumas sugestões, elas servem para fazer notar que a segurança do aplicativo é complicada, e é sua responsabilidade garantir que você não deixe nenhuma ponta solta para os atacantes puxarem. Você não pode confiar em um componente central de segurança para proteger seu negócio; a segurança do aplicativo é distribuída por toda à sua arquitetura de aplicativo.
7. Colete feedback do usuário
O feedback do usuário é uma ferramenta crucial para entender o quão bem o seu aplicativo está se saindo em termos de desempenho comercial e técnico. Você pode construir o aplicativo mais leve e suave do mundo, mas se ele não deixar seus usuários fazerem o que eles esperam, então todos os seus esforços vão por água abaixo.
Há várias maneiras de coletar o feedback do usuário. Enquanto uma pesquisa rápida e anônima é a abordagem convencional, você também poderia optar por uma solução mais sofisticada, como um mapa de calor da atividade de seus usuários.
A escolha do método de coleta de feedback é menos importante do que tomar medidas em relação ao feedback coletado. Os clientes adoram empresas que escutam seus problemas. Gigantes como McDonald’s e Tesla fazem isso, e essa é uma das razões pelas quais eles continuam a ter sucesso em seus mercados.
Resumo
A internet é um enorme parque infantil de uma variedade de aplicativos, cada uma projetada em sua própria maneira única. Múltiplos tipos de arquiteturas dão lugar a aplicativos web para diversificar, prosperar e oferecer serviços aos usuários em todo o mundo.
Neste guia, detalhamos os diferentes modelos de arquitetura de aplicativos web e mostramos a você como eles são cruciais para o crescimento de um aplicativo.
Existe uma arquitetura de aplicativos web que você realmente adorou? Ou há outra que você gostaria de compartilhar com o mundo? Nos deixe saber nos comentários abaixo!
Kumar is a software developer and a technical author based in India. He specializes in JavaScript and DevOps. You can learn more about his work on his website.
Deixe um comentário