O que \u00e9 arquitetura de aplicativos web?<\/h2>\n
Para iniciar a discuss\u00e3o, vamos come\u00e7ar com a defini\u00e7\u00e3o da arquitetura de aplicativos web.<\/p>\n
Em palavras simples, a arquitetura de aplicativos web \u00e9 um esbo\u00e7o de como v\u00e1rios componentes do seu aplicativo web interagem entre si.<\/p>\n
Pode ser t\u00e3o simples quanto definir o relacionamento entre o cliente e o servidor. Tamb\u00e9m pode ser t\u00e3o complexo quanto definir as inter-rela\u00e7\u00f5es entre um enxame de servidores, backend de cont\u00eaineres, balanceadores de carga, gateways API e frontend de p\u00e1gina \u00fanica voltados para o usu\u00e1rio.<\/p>\n
Dito isto, raramente se trata de escolher a linguagem de programa\u00e7\u00e3o<\/a> na qual voc\u00ea vai escrever seu c\u00f3digo.<\/p>\n Como voc\u00ea projeta seu aplicativo web tem um papel fundamental tanto em sua usabilidade quanto em sua otimiza\u00e7\u00e3o de custos. Veja como \u00e9 um exemplo de arquitetura de aplicativos web no papel:<\/p>\n A arquitetura do aplicativo web \u00e9, sem d\u00favida, uma das partes mais importantes do seu aplicativo web. Caso voc\u00ea optar por desenvolver seu aplicativo web com uma arquitetura espec\u00edfica em mente, voc\u00ea certamente receber\u00e1 muitos benef\u00edcios quando se trata de manter e crescer seu aplicativo.<\/p>\n Entretanto, a escolha da arquitetura certa, amplifica ainda mais esses benef\u00edcios.<\/p>\n Aqui est\u00e3o algumas das principais raz\u00f5es pelas quais voc\u00ea deve considerar seriamente a ado\u00e7\u00e3o de uma arquitetura de aplicativos web.<\/p>\n Seu aplicativo \u00e9 uma porta de entrada chave para o seu neg\u00f3cio, e \u00e0s necessidades do neg\u00f3cio evoluem com as mudan\u00e7as do mercado. Para manter-se atualizado, voc\u00ea vai querer que seu aplicativo seja flex\u00edvel o suficiente para se adaptar \u00e0s suas necessidades da empresa em constante mudan\u00e7a. E se voc\u00ea construir um aplicativo sem considerar a flexibilidade embutida, voc\u00ea estar\u00e1 sujeito a gastar cada vez mais tempo e esfor\u00e7o fazendo pequenos ajustes em seu aplicativo.<\/p>\n A arquitetura correta do aplicativo web j\u00e1 \u00e9 respons\u00e1vel por algumas das mudan\u00e7as que seu neg\u00f3cio pode precisar no futuro. Por exemplo, se voc\u00ea sabe que est\u00e1 construindo um aplicativo de eCommerce que ir\u00e1 escalar e atender uma ampla gama de servi\u00e7os para um grande n\u00famero de clientes um dia, escolher uma arquitetura de microsservi\u00e7os em vez de uma arquitetura monol\u00edtica lhe proporcionaria mais flexibilidade.<\/p>\n Por outro lado, se voc\u00ea est\u00e1 construindo um aplicativo interno para sua empresa com apenas um ou dois requisitos fixos, voc\u00ea pode optar por um mon\u00f3lito mais simples para acelerar o desenvolvimento e manter sua base de c\u00f3digo limpa.<\/p>\n Como mencionamos anteriormente, a arquitetura correta do aplicativo web fornece a voc\u00ea um itiner\u00e1rio mais conveniente para o desenvolvimento. A arquitetura fornece modularidade suficiente em seu sistema para isolar componentes conforme necess\u00e1rio, e voc\u00ea tem a liberdade de escolher a estrutura de projeto certa para cada um de seus m\u00f3dulos e componentes conforme necess\u00e1rio.<\/p>\n O desenvolvimento de aplicativos sem uma arquitetura em mente, voc\u00ea arrisca perder tempo e dinheiro reorganizando seus componentes e estabelecendo novas regras para ajudar a facilitar a colabora\u00e7\u00e3o entre os membros da sua equipe<\/a> – tempo e dinheiro que de outra forma poderiam ter sido gastos em outro lugar.<\/p>\n Al\u00e9m de escrever o c\u00f3digo do seu aplicativo, voc\u00ea tamb\u00e9m vai gastar um tempo consider\u00e1vel gerenciando-o. Organizar seus arquivos de projeto, quebrar seu aplicativo em m\u00f3dulos e configurar pipelines personalizados s\u00e3o apenas algumas das tarefas que requerem manuten\u00e7\u00e3o ativa para garantir um desenvolvimento suave.<\/p>\n A arquitetura correta do aplicativo web facilita voc\u00ea fazer mudan\u00e7as. Voc\u00ea pode implementar melhores pr\u00e1ticas espec\u00edficas para cada componente, separar os pontos de dor do seu aplicativo uns dos outros e manter cada recurso independente e frouxamente acoplado. N\u00e3o \u00e9 que essas coisas n\u00e3o possam ser feitas sem arquitetura; \u00e9 que a arquitetura certa torna tudo muito mais simples.<\/p>\n Seguir uma arquitetura pr\u00e9-definida tamb\u00e9m facilita o desenvolver de seus aplicativos mais rapidamente. A arquitetura certa combinada com uma s\u00f3lida estrat\u00e9gia de controle de vers\u00e3o<\/a> pode permitir que seus desenvolvedores trabalhem em paralelo entre si e construam recursos mais rapidamente.<\/p>\n A arquitetura de aplicativos web tamb\u00e9m prova seu aplicativo para o futuro. Assim que voc\u00ea definir uma estrat\u00e9gia s\u00f3lida sobre como organizar os componentes do seu aplicativo, voc\u00ea pode facilmente migrar esses componentes para tecnologias mais novas, sem ter que refazer todo o seu aplicativo.<\/p>\n A maioria das arquiteturas de aplicativos consideram a seguran\u00e7a ao estruturar os componentes. Os desenvolvedores podem planejar, antes do tempo, \u00e0s medidas e pr\u00e1ticas a serem implementadas para melhorar a seguran\u00e7a do aplicativo<\/a> antes que ele seja lan\u00e7ado para os usu\u00e1rios.<\/p>\n Por exemplo, construir um aplicativo de streaming de v\u00eddeo<\/a> que oferece tanto conte\u00fado pago quanto gratuito usando microsservi\u00e7os faz mais sentido, porque a arquitetura dos microsservi\u00e7os permite dividir seu aplicativo em componentes adaptados \u00e0s necessidades comerciais, tais como autentica\u00e7\u00e3o de usu\u00e1rio<\/a> e streaming de conte\u00fado gratuito ou pago. Caso o seu m\u00f3dulo de autentica\u00e7\u00e3o de usu\u00e1rio falhar, voc\u00ea pode facilmente configurar seu aplicativo para restringir o acesso ao m\u00f3dulo de conte\u00fado pago<\/a> at\u00e9 que a autentica\u00e7\u00e3o seja restaurado, enquanto o m\u00f3dulo de conte\u00fado gratuito permanece dispon\u00edvel para seus usu\u00e1rios.<\/p>\n Em um caso alternativo em que este mesmo aplicativo fosse projetado como um mon\u00f3lito estreitamente acoplado, levaria um servi\u00e7o de autentica\u00e7\u00e3o em baixa<\/a> ou um conte\u00fado pago sendo disponibilizado gratuitamente – resultados que voc\u00ea gostaria de evitar a todo custo.<\/p>\n Antes de falarmos sobre como a arquitetura de aplicativos web funciona, \u00e9 importante entender como funciona um site simples:<\/p>\n Se voc\u00ea fosse um pouco mais fundo, aqui est\u00e1 como um aplicativo web<\/em> lidaria com um pedido:<\/p>\n Agora que voc\u00ea tem uma ideia b\u00e1sica do que \u00e9 arquitetura de aplicativos web, vamos dar uma olhada detalhada em alguns dos tipos populares de arquitetura de aplicativos web usados em toda a internet.<\/p>\n A arquitetura de aplicativos de p\u00e1gina \u00fanica (Single-Page Application ou SPA) \u00e9 t\u00e3o simples quanto seu nome: o aplicativo inteiro \u00e9 baseada em uma \u00fanica p\u00e1gina. Uma vez que o usu\u00e1rio baixa o seu aplicativo, ele n\u00e3o precisa navegar para qualquer outra p\u00e1gina da internet. O aplicativo \u00e9 tornado din\u00e2mico o suficiente para buscar e renderizar telas que atendam aos requisitos dos usu\u00e1rios enquanto eles navegam pelo pr\u00f3prio aplicativo.<\/p>\n Os SPAs s\u00e3o \u00f3timos quando se trata de fornecer uma experi\u00eancia r\u00e1pida e perfeita para os usu\u00e1rios finais ou consumidores. Entretanto, eles n\u00e3o possuem o toque de um site tradicional e podem ser dif\u00edceis de otimizar para SEO<\/a>.<\/p>\n Alguns dos pr\u00f3s da arquitetura SPA incluem:<\/p>\n Alguns dos inconvenientes da arquitetura de SPA s\u00e3o:<\/p>\n A arquitetura Progressive Web Application (PWA) \u00e9 constru\u00edda com base na Arquitetura de P\u00e1gina \u00danica, fornecendo capacidades offline para o aplicativo web. Tecnologias como Capacitor e Ionic s\u00e3o usadas para construir PWAs que podem fornecer aos usu\u00e1rios uma experi\u00eancia uniforme<\/a> entre plataformas.<\/p>\n Semelhantes ao SPA, os PWAs s\u00e3o suaves e sem problemas. Com a capacidade adicional de serem instalados em dispositivos do usu\u00e1rio (por workers de servi\u00e7o), seus usu\u00e1rios obt\u00eam uma experi\u00eancia mais uniforme com seu aplicativo.<\/p>\n Ao mesmo tempo, pode ser dif\u00edcil otimizar tais aplicativos para SEO, e atualiza\u00e7\u00f5es em aplicativos instalados podem ser dif\u00edceis de serem empurradas.<\/p>\n H\u00e1 muitos benef\u00edcios da arquitetura do PWA, inclusive:<\/p>\n Alguns dos contras da arquitetura do PWA podem incluir:<\/p>\n Na renderiza\u00e7\u00e3o do lado do servidor (SSR), \u00e0s p\u00e1ginas da internet frontend s\u00e3o renderizadas em um servidor backend ap\u00f3s serem solicitadas pelo usu\u00e1rio. Isto ajuda a reduzir a carga no dispositivo cliente ao receber um HTML est\u00e1tico, CSS, e JS webpage.<\/p>\n Os aplicativos SSR s\u00e3o muito populares entre os blogs e sites de eCommerce. Isto porque eles tornam o gerenciamento de links e SEO bastante simples. Al\u00e9m disso, a primeira renderiza\u00e7\u00e3o para aplicativos SSR \u00e9 bastante r\u00e1pida, j\u00e1 que o cliente n\u00e3o precisa processar nenhum c\u00f3digo JS para renderizar \u00e0s telas.<\/p>\n Alguns dos pr\u00f3s da arquitetura SSR est\u00e3o listados abaixo:<\/p>\n Alguns dos inconvenientes de usar a arquitetura SSR incluem:<\/p>\n A arquitetura de aplicativos pr\u00e9-renderizadas tamb\u00e9m \u00e9 conhecida como arquitetura de gera\u00e7\u00e3o de sites est\u00e1tica. Nesta arquitetura, \u00e0s p\u00e1ginas de internet frontend do aplicativo s\u00e3o pr\u00e9-geradas e armazenadas como arquivos HTML, CSS e JS simples no servidor. Uma vez que um usu\u00e1rio solicita uma p\u00e1gina, ela \u00e9 diretamente buscada e mostrada a ele. Isto torna o aplicativo web muito r\u00e1pido, com tempos de carregamento m\u00ednimos de qualquer tipo. Entretanto, esta arquitetura aumenta o tempo de constru\u00e7\u00e3o do aplicativo, uma vez que \u00e0s p\u00e1ginas de internet s\u00e3o renderizadas durante o processo de constru\u00e7\u00e3o.<\/p>\n aplicativos web pr\u00e9-renderizadas s\u00e3o \u00f3timas para quando voc\u00ea est\u00e1 procurando gerar conte\u00fado est\u00e1tico, como blogs ou detalhes de produtos que n\u00e3o mudam com frequ\u00eancia. Voc\u00ea tamb\u00e9m pode recorrer a templates para simplificar o design da sua p\u00e1gina de internet. No entanto, \u00e9 quase imposs\u00edvel construir aplicativos web din\u00e2micos com esta arquitetura. Se voc\u00ea est\u00e1 procurando construir uma p\u00e1gina de pesquisa que leva a consulta em seu caminho (algo como Como cada rota poss\u00edvel do aplicativo \u00e9 pr\u00e9-renderizada durante o processo de constru\u00e7\u00e3o, \u00e9 imposs\u00edvel ter caminhos din\u00e2micos como acima, j\u00e1 que h\u00e1 infinitas possibilidades que n\u00e3o podem ser pr\u00e9-renderizadas durante a constru\u00e7\u00e3o (e tamb\u00e9m n\u00e3o faz sentido fazer isso).<\/p>\n Alguns dos principais benef\u00edcios da arquitetura de aplicativos pr\u00e9-renderizadas s\u00e3o:<\/p>\n Como em qualquer modelo arquitet\u00f4nico, o pr\u00e9-renderizado tem sua quota-parte de inconvenientes:<\/p>\n Aplicativos isom\u00f3rficos s\u00e3o aquelas que s\u00e3o uma mistura de aplicativos renderizadas do lado do servidor e SPAs. Isto significa que tais aplicativos s\u00e3o primeiro renderizadas no servidor como um aplicativo normal renderizada do lado do servidor. Uma vez que eles s\u00e3o recebidos pelo cliente, o aplicativo se hidrata e anexa o DOM virtual para um processamento mais r\u00e1pido e eficiente do cliente. Isto essencialmente transforma o aplicativo em um aplicativo de uma \u00fanica p\u00e1gina.<\/p>\n Isom\u00f3rfico re\u00fane o melhor dos dois mundos. Voc\u00ea obt\u00e9m um processamento super r\u00e1pido e uma interface de usu\u00e1rio no cliente, gra\u00e7as ao SPA. Voc\u00ea tamb\u00e9m obt\u00e9m renderiza\u00e7\u00e3o inicial r\u00e1pida e SEO completo e suporte a links, gra\u00e7as \u00e0 renderiza\u00e7\u00e3o do lado do servidor.<\/p>\n Aqui est\u00e3o apenas alguns dos benef\u00edcios de usar a arquitetura de aplicativo isom\u00f3rfico:<\/p>\n Alguns dos consensos da arquitetura de aplicativos isom\u00f3rficos podem ser:<\/p>\n A arquitetura orientada a servi\u00e7os (Service-Oriented Architecture ou SOA) est\u00e1 entre \u00e0s alternativas mais populares para a forma tradicional monol\u00edtica de construir aplicativos. Nesta arquitetura, os aplicativos web s\u00e3o divididas em servi\u00e7os que representam uma unidade funcional de neg\u00f3cios cada uma. Estes servi\u00e7os s\u00e3o acoplados frouxamente e interagem uns com os outros atrav\u00e9s da passagem de mensagens.<\/p>\n A arquitetura orientada a servi\u00e7os adiciona estabilidade e escalabilidade \u00e0 sua pilha de tecnologia do aplicativo. Entretanto, o tamanho dos servi\u00e7os em SOA n\u00e3o est\u00e1 claramente definido e est\u00e1 normalmente ligado a componentes comerciais, n\u00e3o a componentes t\u00e9cnicos; portanto, a manuten\u00e7\u00e3o \u00e0s vezes pode ser um problema.<\/p>\n Os principais benef\u00edcios da arquitetura orientada a servi\u00e7os incluem:<\/p>\n Aqui est\u00e1 uma lista de potenciais inconvenientes para o uso de uma arquitetura orientada a servi\u00e7os:<\/p>\n A arquitetura de microsservi\u00e7os foram projetadas para resolver os problemas com a arquitetura orientada a servi\u00e7os. Os microsservi\u00e7os s\u00e3o componentes ainda mais modulares que se encaixam para construir um aplicativo web. Entretanto, os microsservi\u00e7os se concentram em manter cada componente pequeno e com um contexto limitado. Contexto limitado significa essencialmente que cada microsservi\u00e7o tem seu c\u00f3digo e dados unidos com o m\u00ednimo de depend\u00eancias de outros microsservi\u00e7os.<\/p>\n A arquitetura de microsservi\u00e7os \u00e9 provavelmente a melhor arquitetura para construir aplicativos que visam escalar para milhares e milh\u00f5es de usu\u00e1rios algum dia. Cada componente \u00e9 flex\u00edvel, escal\u00e1vel e f\u00e1cil de manter. Entretanto, a manuten\u00e7\u00e3o do ciclo de vida do DevOps para um aplicativo baseado em microsservi\u00e7os requer esfor\u00e7os adicionais; portanto, ele pode n\u00e3o ser adequado para casos de uso menores.<\/p>\n Alguns dos pr\u00f3s da arquitetura de microsservi\u00e7os incluem:<\/p>\n Uma desvantagem da arquitetura de microsservi\u00e7os pode ser:<\/p>\n A arquitetura sem servidor \u00e9 outro candidato no mundo das arquiteturas de aplicativos web. Esta arquitetura se concentra em quebrar seu aplicativo em termos das fun\u00e7\u00f5es que ela deve realizar. Ent\u00e3o estas fun\u00e7\u00f5es s\u00e3o hospedadas em plataformas FaaS (Function-as-a-Service) como fun\u00e7\u00f5es que s\u00e3o invocadas \u00e0 medida que solicitam.<\/p>\n Ao contr\u00e1rio da maioria das outras arquiteturas desta lista, aplicativos constru\u00eddos usando a arquitetura sem servidor n\u00e3o ficam rodando o tempo todo. Eles se comportam como fun\u00e7\u00f5es 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\u00e7\u00e3o e s\u00e3o altamente escal\u00e1veis sem muito esfor\u00e7o. Entretanto, \u00e9 dif\u00edcil realizar tarefas de longa dura\u00e7\u00e3o usando tais componentes.<\/p>\n Aqui est\u00e3o os principais benef\u00edcios da arquitetura sem servidor:<\/p>\n Abaixo est\u00e3o alguns dos inconvenientes da arquitetura sem servidor:<\/p>\n Enquanto as arquiteturas de aplicativos web que voc\u00ea 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\u00f3cios.<\/p>\n A camada de apresenta\u00e7\u00e3o \u00e9 respons\u00e1vel por tudo em um aplicativo web, que \u00e9 exposto aos usu\u00e1rios finais. Primeiramente, a camada de apresenta\u00e7\u00e3o \u00e9 composta pelo cliente frontend. No entanto, ela tamb\u00e9m incorpora qualquer l\u00f3gica que voc\u00ea tenha escrito em seu backend para tornar seu frontend din\u00e2mico. Isto lhe d\u00e1 o espa\u00e7o para servir seus usu\u00e1rios com interface personalizada de acordo com seu perfil e exig\u00eancias.<\/p>\n Tr\u00eas tecnologias fundamentais s\u00e3o 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\u00e1rios interagem com ele). Al\u00e9m dessas tr\u00eas tecnologias, voc\u00ea pode usar qualquer tipo de framework<\/a> para ajudar a facilitar o seu desenvolvimento. Alguns frameworks frontend comuns incluem Laravel<\/a>, React, NextJS, Vue, GatsbyJS, etc.<\/p>\n A camada de neg\u00f3cios \u00e9 respons\u00e1vel por manter e gerenciar a l\u00f3gica de trabalho do seu aplicativo. Geralmente \u00e9 um servi\u00e7o backend que aceita solicita\u00e7\u00f5es do cliente e as processa. Ele controla o que o usu\u00e1rio pode acessar e determina como a infraestrutura \u00e9 utilizada para atender as solicita\u00e7\u00f5es dos usu\u00e1rios.<\/p>\n No caso de um aplicativo de reserva de hotel, seu aplicativo cliente serve como um portal para os usu\u00e1rios digitarem os nomes dos hot\u00e9is e outros dados relevantes. No entanto, assim que o usu\u00e1rio clica no bot\u00e3o de pesquisa, a camada empresarial recebe a solicita\u00e7\u00e3o e inicia a l\u00f3gica de procura de quartos de hotel dispon\u00edveis que atendam \u00e0s suas necessidades. O cliente ent\u00e3o 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\u00e3o dispostos da forma como foram enviados.<\/p>\n A presen\u00e7a de tal camada assegura que sua l\u00f3gica comercial n\u00e3o seja exposta ao seu cliente e aos usu\u00e1rios. O isolamento da l\u00f3gica de neg\u00f3cios ajuda imensamente em opera\u00e7\u00f5es sens\u00edveis, como o manuseio de pagamentos ou o gerenciamento de registros de sa\u00fade.<\/p>\n A camada de persist\u00eancia \u00e9 respons\u00e1vel por controlar o acesso aos seus armaz\u00e9ns de dados. Isto atua como uma camada adicional de abstra\u00e7\u00e3o entre seus datas tores e sua camada de neg\u00f3cios. Ele recebe todas as chamadas relacionadas aos dados das camadas de neg\u00f3cios e as processa fazendo conex\u00f5es seguras com o banco de dados.<\/p>\n Esta camada geralmente consiste em um servidor do banco de dados<\/a>. Voc\u00ea 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\u00e7\u00e3o remota\/gerenciada por um dos principais provedores de infraestrutura de nuvem como AWS, GCP, Microsoft Azure, etc.<\/p>\n Agora que voc\u00ea entende o que vai para uma arquitetura de aplicativos web, vamos dar uma olhada detalhada em cada um dos componentes que comp\u00f5em um aplicativo web. Vamos agrupar esta discuss\u00e3o em dois grandes cabe\u00e7alhos – componentes do lado do servidor e componentes do lado do cliente, ou componentes backend e frontend<\/a>.<\/p>\n Os componentes do lado do servidor s\u00e3o aqueles que residem no backend do seu aplicativo web. Estes n\u00e3o s\u00e3o expostos diretamente aos usu\u00e1rios e possuem a mais importante l\u00f3gica de neg\u00f3cios e recursos para o seu aplicativo web.<\/p>\n O DNS \u00e9 respons\u00e1vel por controlar como o seu aplicativo \u00e9 exposto na internet. Os registros DNS s\u00e3o usados por clientes HTTP, que tamb\u00e9m podem ser um navegador, para encontrar e enviar solicita\u00e7\u00f5es para os componentes do seu aplicativo. O DNS tamb\u00e9m \u00e9 usado por seus clientes frontend internamente para resolver a localiza\u00e7\u00e3o de seus servidores web e endpoints de API para enviar solicita\u00e7\u00f5es e processar as opera\u00e7\u00f5es dos usu\u00e1rios.<\/p>\n O balanceamento de carga \u00e9 outro componente popular da arquitetura de aplicativos web. Um balanceador de carga \u00e9 usado para distribuir solicita\u00e7\u00f5es HTTP entre v\u00e1rios servidores web id\u00eanticos. A inten\u00e7\u00e3o por tr\u00e1s de ter m\u00faltiplos servidores web \u00e9 manter uma redund\u00e2ncia que ajuda a aumentar a toler\u00e2ncia a falhas, bem como distribuir tr\u00e1fego para manter um alto desempenho.<\/p>\n Os endpoints API s\u00e3o usados para expor os servi\u00e7os backend o aplicativo frontend. Estes ajudam a facilitar a comunica\u00e7\u00e3o entre o cliente e o servidor, e \u00e0s vezes at\u00e9 mesmo entre m\u00faltiplos servidores tamb\u00e9m.<\/p>\n O armazenamento de dados \u00e9 uma parte crucial da maioria dos aplicativos modernos, pois h\u00e1 sempre alguns dados de aplicativo que precisam ser persistidos durante as sess\u00f5es do usu\u00e1rio. O armazenamento de dados \u00e9 de dois tipos:<\/p>\n O cache \u00e9 um recurso opcional frequentemente implementado em arquiteturas de aplicativos web para servir conte\u00fado mais rapidamente para os usu\u00e1rios. Uma grande parte do conte\u00fado do aplicativo \u00e9 frequentemente repetitiva por algum tempo, se n\u00e3o sempre. Ao inv\u00e9s de acess\u00e1-lo a partir de um armazenamento de dados e process\u00e1-lo antes de envi\u00e1-lo de volta para o usu\u00e1rio, ele \u00e9 frequentemente colocado em cache. Aqui est\u00e3o os dois tipos mais populares de cache usados em aplicativos web:<\/p>\n Al\u00e9m de expor uma interface aos usu\u00e1rios (frontend) e lidar com seus pedidos (backend), h\u00e1 outra categoria um pouco menos popular de componentes de aplicativos web. Os jobs s\u00e3o frequentemente servi\u00e7os de fundo que s\u00e3o destinados a completar tarefas que n\u00e3o s\u00e3o sens\u00edveis ao tempo ou s\u00edncronas.<\/p>\n Os CRON Jobs s\u00e3o aqueles realizados durante um per\u00edodo fixo de tempo repetidamente. Estes Jobs s\u00e3o programados no backend para executar rotinas de manuten\u00e7\u00e3o automaticamente em hor\u00e1rios definidos. Alguns exemplos comuns de casos de uso para estes incluem a elimina\u00e7\u00e3o de duplicatas\/ registros antigos do banco de dados, envio de e-mails de lembrete aos clientes, etc.<\/p>\n Os componentes do lado do cliente s\u00e3o aqueles sendo expostos aos seus usu\u00e1rios direta ou indiretamente.<\/p>\n H\u00e1 principalmente dois tipos de componentes nesta categoria.<\/p>\n A interface do usu\u00e1rio \u00e9 o aspecto visual do seu aplicativo. \u00c9 com ela que seus usu\u00e1rios veem e interagem a fim de acessar seus servi\u00e7os.<\/p>\n A interface frontend \u00e9 constru\u00edda em sua maioria sobre tr\u00eas tecnologias populares: HTML, CSS, e JavaScript<\/a>. A interface do usu\u00e1rio do frontend pode ser um aplicativo em si mesma com seu pr\u00f3prio ciclo de vida de desenvolvimento de software.<\/p>\n Estas interfaces de usu\u00e1rio n\u00e3o abrigam muita da sua l\u00f3gica de neg\u00f3cios, uma vez que elas s\u00e3o expostas diretamente aos seus usu\u00e1rios. Caso um usu\u00e1rio malicioso tentar fazer engenharia reversa em seu aplicativo frontend, eles podem obter informa\u00e7\u00f5es sobre como seu neg\u00f3cio funciona e realizar atividades ilegais como personifica\u00e7\u00e3o de marca<\/a> e roubo de dados.<\/p>\n Al\u00e9m disso, como a interface do usu\u00e1rio frontend \u00e9 exposta diretamente aos usu\u00e1rios, voc\u00ea vai querer otimiz\u00e1-la para um tempo m\u00ednimo de carregamento<\/a> e capacidade de resposta. \u00c0s vezes isso pode ajud\u00e1-lo a fornecer uma melhor experi\u00eancia aos seus usu\u00e1rios, aumentando assim o crescimento do seu neg\u00f3cio.<\/p>\n Algumas vezes voc\u00ea pode precisar armazenar alguma l\u00f3gica comercial em seu cliente para poder realizar opera\u00e7\u00f5es mais simples rapidamente. A l\u00f3gica do lado do cliente que normalmente reside dentro do seu aplicativo frontend pode ajudar evitando a viagem ao servidor e fornecer aos seus usu\u00e1rios uma experi\u00eancia mais r\u00e1pida.<\/p>\n Esta \u00e9 uma caracter\u00edstica opcional dos componentes do lado do cliente. Em alguns casos, a l\u00f3gica comercial do aplicativo \u00e9 armazenada inteiramente no lado do cliente (especialmente quando se constr\u00f3i sem um servidor backend tradicional<\/a>). Solu\u00e7\u00f5es modernas como o BaaS ajudam voc\u00ea a acessar opera\u00e7\u00f5es comuns como autentica\u00e7\u00e3o, armazenamento de dados, armazenamento de arquivos, etc., em movimento no seu aplicativo frontend.<\/p>\n Existem maneiras de ofuscar ou minifique\u00a0este c\u00f3digo<\/a> antes de envi\u00e1-lo aos seus usu\u00e1rios para minimizar as chances de engenharia reversa.<\/p>\n Existem m\u00faltiplos modelos de arquiteturas de aplicativos web, cada um baseado em como os servidores web se conectam aos seus armaz\u00e9ns de dados.<\/p>\n O modelo mais simples de todos \u00e9 um servidor web conectando-se a uma inst\u00e2ncia do banco de dados. Tal modelo \u00e9 f\u00e1cil de implementar e manter, e ir para produ\u00e7\u00e3o com ele tamb\u00e9m \u00e9 bastante f\u00e1cil.<\/p>\n Devido \u00e0 sua simplicidade, este modelo \u00e9 adequado para o aprendizado e para pequenos aplicativos experimentais que n\u00e3o ser\u00e3o expostas ao alto tr\u00e1fego. Desenvolvedores novatos podem facilmente configurar e mexer com estes aplicativos para aprender os fundamentos do desenvolvimento de aplicativos web<\/a>.<\/p>\n No entanto, este modelo n\u00e3o deve ser usado na produ\u00e7\u00e3o, uma vez que \u00e9 altamente duvidoso. Um problema no servidor ou no banco de dados pode resultar em tempo de inatividade e perda de neg\u00f3cios.<\/p>\n Este modelo eleva o n\u00edvel do aplicativo atrav\u00e9s da configura\u00e7\u00e3o de m\u00faltiplos servidores para redund\u00e2ncia com uma \u00fanica inst\u00e2ncia comum do banco de dados.<\/p>\n Como v\u00e1rios servidores web acessam o banco de dados simultaneamente, podem ocorrer problemas de inconsist\u00eancia. Para evitar isso, os servidores web s\u00e3o projetados para serem sem estado. Isto significa que os servidores n\u00e3o ret\u00eam dados durante as sess\u00f5es; eles simplesmente os processam e armazenam no banco de dados.<\/p>\n Os aplicativos criados usando este modelo s\u00e3o certamente mais confi\u00e1veis do que aqueles com o modelo anterior, j\u00e1 que a presen\u00e7a de m\u00faltiplos servidores web aumenta a toler\u00e2ncia a falhas do aplicativo web. Entretanto, como o banco de dados ainda \u00e9 uma inst\u00e2ncia comum, ele \u00e9 o elo mais fraco na arquitetura e pode ser uma fonte de falhas.<\/p>\n Este modelo \u00e9 um dos modelos mais comuns e tradicionais de projetar aplicativos web.<\/p>\n Neste caso, implante sua l\u00f3gica de aplicativo como m\u00faltiplas inst\u00e2ncias id\u00eanticas de servidores web agrupadas atr\u00e1s de um balanceador de carga. Seu armazenamento de dados tamb\u00e9m \u00e9 mantido em m\u00faltiplas inst\u00e2ncias do banco de dados para maior toler\u00e2ncia a falhas.<\/p>\n Voc\u00ea tamb\u00e9m pode optar por dividir seu banco de dados entre as inst\u00e2ncias dispon\u00edveis para melhorar o desempenho ou manter duplicatas de todo o armazenamento de dados para redund\u00e2ncia. Em ambos os casos, a falha em qualquer inst\u00e2ncia do seu banco de dados n\u00e3o levar\u00e1 a uma paralisa\u00e7\u00e3o completa do aplicativo.<\/p>\n Este modelo \u00e9 altamente apreciado por sua confiabilidade e escalabilidade. Entretanto, desenvolver e manter aplicativos usando este modelo \u00e9 relativamente complicado e requer desenvolvedores experientes e caros<\/a>. Como tal, este modelo s\u00f3 \u00e9 sugerido quando voc\u00ea est\u00e1 construindo em larga escala.<\/p>\n Enquanto os tr\u00eas modelos mencionados acima s\u00e3o bem adequados para aplicativos monol\u00edticas, h\u00e1 um outro modelo para aplicativos modulares.<\/p>\n O modelo de servi\u00e7os de aplicativo s\u00e3o divididos em m\u00f3dulos menores baseados na funcionalidade da empresa. Estes m\u00f3dulos podem ser t\u00e3o pequenos quanto uma fun\u00e7\u00e3o ou t\u00e3o grandes quanto um servi\u00e7o.<\/p>\n A ideia aqui \u00e9 tornar cada caracter\u00edstica de neg\u00f3cio independente e escal\u00e1vel. Cada um desses m\u00f3dulos pode se conectar ao banco de dados por si s\u00f3. Voc\u00ea pode at\u00e9 mesmo ter inst\u00e2ncias do banco de dados dedicadas para atender \u00e0s necessidades de escalabilidade do seu m\u00f3dulo.<\/p>\n Entre os aplicativos n\u00e3o-monol\u00edticas, este modelo \u00e9 bastante popular. Os mon\u00f3litos legados s\u00e3o frequentemente migrados para este modelo para usar sua escalabilidade e benef\u00edcios de modularidade. Entretanto, o gerenciamento de aplicativos constru\u00eddos sobre tal modelo muitas vezes requer desenvolvedores experientes<\/a>, especialmente experi\u00eancia em DevOps e CI\/CD.<\/p>\n Aqui est\u00e3o algumas das melhores pr\u00e1ticas que voc\u00ea pode implementar em seu projeto de aplicativos web para obter o m\u00e1ximo da sua arquitetura do aplicativo web escolhida.<\/p>\n Isto n\u00e3o pode ser estressado o suficiente: sempre vise para ter frontend responsivo<\/a>. N\u00e3o importa qu\u00e3o grande e complexo o seu aplicativo web internamente, tudo isso \u00e9 exposto aos seus usu\u00e1rios atrav\u00e9s do\u00a0frontend de p\u00e1ginas web, aplicativos e telas.<\/p>\n Caso seus usu\u00e1rios acharem estas telas pouco intuitivas ou lentas, eles n\u00e3o v\u00e3o ficar por aqui o tempo suficiente para ver e admirar a maravilha da engenharia do seu aplicativo web.<\/p>\n Portanto, projetar frontend responsivos, f\u00e1ceis de usar e leves \u00e9 muito importante.<\/p>\n Existem amplas melhores pr\u00e1ticas UI\/UX<\/a> dispon\u00edveis na web para ajud\u00e1-lo a entender o que funciona melhor para seus usu\u00e1rios. Voc\u00ea pode encontrar profissionais habilitados a fazer projetos e arquiteturas amig\u00e1veis que podem permitir que seus usu\u00e1rios tirem o m\u00e1ximo proveito de seus aplicativos.<\/p>\n Aconselhamos pensar seriamente na capacidade de resposta do seu frontend antes de lan\u00e7ar seu produto para seus usu\u00e1rios.<\/p>\n Al\u00e9m de ser f\u00e1cil de entender, o frontend tamb\u00e9m precisa ser r\u00e1pido ao carregar<\/a>.<\/p>\n De acordo com Portent<\/a>, as maiores taxas de convers\u00e3o de eCommerce ocorrem em p\u00e1ginas com tempos de carregamento entre 0-2 segundos, e de acordo com Unbounce<\/a>, cerca de 70% dos consumidores admitem que o tempo de carregamento de p\u00e1ginas \u00e9 um fator importante em sua escolha para comprar de um vendedor on-line.<\/p>\n Ao projetar aplicativos m\u00f3veis nativas, voc\u00ea normalmente n\u00e3o pode ter certeza das especifica\u00e7\u00f5es do dispositivo de seus usu\u00e1rios. Qualquer dispositivo que n\u00e3o atenda aos requisitos do seu aplicativo \u00e9 tipicamente declarado como n\u00e3o compat\u00edvel com o aplicativo.<\/p>\n No entanto, isto \u00e9 bem diferente com a web.<\/p>\n Quando se trata de aplicativos web, seus usu\u00e1rios podem estar usando qualquer coisa, desde o mais recente Apple Macbook M1 Pros at\u00e9 telefones antigos Blackberry e Nokia para visualizar seu aplicativo. Otimizar sua experi\u00eancia de frontend para uma gama t\u00e3o ampla de usu\u00e1rios pode ser dif\u00edcil \u00e0s vezes.<\/p>\n Servi\u00e7os como o LightHouse e o Google PageSpeed<\/a> v\u00eam \u00e0 mente quando se fala sobre o desempenho do frontend. Voc\u00ea deve usar tais ferramentas<\/a> para comparar seu aplicativo frontend antes de implement\u00e1-lo na produ\u00e7\u00e3o. A maioria dessas ferramentas fornece a voc\u00ea uma lista de dicas acion\u00e1veis para ajudar a melhorar o desempenho do seu aplicativo o m\u00e1ximo poss\u00edvel.<\/p>\n Os 5-10% finais do desempenho do aplicativo s\u00e3o geralmente espec\u00edficos para o seu caso de uso e s\u00f3 podem ser corrigidos por algu\u00e9m que conhece bem o seu aplicativo e suas tecnologias. Nunca custa investir no desempenho da web<\/a>!<\/p>\n Como discutido anteriormente, os PWAs s\u00e3o os projetos do futuro. Eles podem se encaixar bem na maioria dos casos de uso e fornecem a experi\u00eancia mais uniforme entre as principais plataformas.<\/p>\n Voc\u00ea deve considerar o uso de PWA para seu aplicativo com a maior frequ\u00eancia poss\u00edvel. A experi\u00eancia nativa atrav\u00e9s da web e do celular \u00e9 extremamente impactante para seus usu\u00e1rios e pode reduzir muito da sua pr\u00f3pria carga de trabalho tamb\u00e9m.<\/p>\n Os PWAs tamb\u00e9m s\u00e3o r\u00e1pidos de carregar, f\u00e1ceis de otimizar e r\u00e1pidos de construir. Optar por PWAs pode ajudar voc\u00ea a mudar muito do seu foco do desenvolvimento para os neg\u00f3cios desde cedo.<\/p>\n Uma base de c\u00f3digo limpa pode ajud\u00e1-lo a identificar e resolver a maioria dos problemas antes que cause danos. Aqui est\u00e3o algumas dicas que voc\u00ea pode seguir para garantir que sua base de c\u00f3digo n\u00e3o esteja causando mais problemas do que deveria.<\/p>\n CI\/CD significa Integra\u00e7\u00e3o Cont\u00ednua e Entrega Cont\u00ednua. Os processos CI\/CD s\u00e3o cruciais para o desenvolvimento do seu aplicativo, pois eles ajudam voc\u00ea a construir, testar e implantar seu projeto com facilidade.<\/p>\n No entanto, voc\u00ea n\u00e3o quer ter que execut\u00e1-los manualmente a cada vez. Ao inv\u00e9s disso, voc\u00ea deve configurar pipelines que acionem automaticamente com base nas atividades do seu projeto. Por exemplo, voc\u00ea poderia configurar um pipeline que executa seus testes automaticamente sempre que voc\u00ea submete seu c\u00f3digo ao seu sistema de controle de vers\u00e3o<\/a>. H\u00e1 muitos casos de uso mais complexo, como a gera\u00e7\u00e3o de artefatos entre plataformas a partir do seu reposit\u00f3rio de c\u00f3digo sempre que uma vers\u00e3o \u00e9 criada.<\/p>\n As possibilidades s\u00e3o infinitas, ent\u00e3o cabe a voc\u00ea descobrir como voc\u00ea pode tirar o m\u00e1ximo proveito de seus dutos CI\/CD.<\/p>\n A maioria dos aplicativos modernas s\u00e3o feitas de m\u00faltiplos componentes. Tome como exemplo o seguinte aplicativo:<\/p>\n As solicita\u00e7\u00f5es dos clientes s\u00e3o encaminhadas para o aplicativo atrav\u00e9s de um gateway API. Enquanto este atualmente s\u00f3 permite solicita\u00e7\u00f5es diretas ao m\u00f3dulo home do aplicativo, no futuro, ele poder\u00e1 permitir o acesso a mais componentes sem passar pelo m\u00f3dulo home.<\/p>\n Em seguida, o m\u00f3dulo home verifica um BaaS de autentica\u00e7\u00e3o externa antes de permitir o acesso. Uma vez autenticado, o cliente pode acessar as p\u00e1ginas “Atualizar Perfil” ou “Ver Perfil”. Ambas \u00e0s p\u00e1ginas interagem com uma solu\u00e7\u00e3o do banco de dados comum e gerenciada que lida com os dados do perfil.<\/p>\n Como voc\u00ea pode ver, o aplicativo parece ser uma vers\u00e3o muito b\u00e1sica e m\u00ednima de um diret\u00f3rio de pessoas on-line<\/a>. Voc\u00ea pode adicionar\/atualizar seu pr\u00f3prio perfil ou visualizar outros perfis dispon\u00edveis.<\/p>\n Aqui est\u00e1 uma r\u00e1pida lenda dos v\u00e1rios componentes da arquitetura:<\/p>\n Os componentes de cada uma das cores acima s\u00e3o vulner\u00e1veis a v\u00e1rios tipos de amea\u00e7as \u00e0 seguran\u00e7a. Aqui est\u00e3o algumas constru\u00e7\u00f5es de seguran\u00e7a que voc\u00ea pode colocar em pr\u00e1tica para minimizar sua exposi\u00e7\u00e3o:<\/p>\n Embora estas sejam apenas algumas sugest\u00f5es, elas servem para fazer notar que a seguran\u00e7a do aplicativo \u00e9 complicada, e \u00e9 sua responsabilidade garantir que voc\u00ea n\u00e3o deixe nenhuma ponta solta para os atacantes puxarem. Voc\u00ea n\u00e3o pode confiar em um componente central de seguran\u00e7a para proteger seu neg\u00f3cio; a seguran\u00e7a do aplicativo \u00e9 distribu\u00edda por toda \u00e0 sua arquitetura de aplicativo.<\/p>\n O feedback do usu\u00e1rio<\/a> \u00e9 uma ferramenta crucial para entender o qu\u00e3o bem o seu aplicativo est\u00e1 se saindo em termos de desempenho comercial e t\u00e9cnico. Voc\u00ea pode construir o aplicativo mais leve e suave do mundo, mas se ele n\u00e3o deixar seus usu\u00e1rios fazerem o que eles esperam, ent\u00e3o todos os seus esfor\u00e7os v\u00e3o por \u00e1gua abaixo.<\/p>\n H\u00e1 v\u00e1rias maneiras de coletar o feedback do usu\u00e1rio. Enquanto uma pesquisa r\u00e1pida e an\u00f4nima<\/a> \u00e9 a abordagem convencional, voc\u00ea tamb\u00e9m poderia optar por uma solu\u00e7\u00e3o mais sofisticada, como um mapa de calor da atividade de seus usu\u00e1rios.<\/p>\n![\"Diagrama](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/10\/web-app-architecture-components.jpg\")
Por que a arquitetura de aplicativos web \u00e9 importante?<\/h2>\n
F\u00e1cil adapta\u00e7\u00e3o \u00e0s necessidades da empresa<\/h3>\n
Desenvolvimento organizado<\/h3>\n
Melhor gerenciamento da base de c\u00f3digo<\/h3>\n
Seguran\u00e7a aprimorada<\/h3>\n
Como funciona a arquitetura de aplicativos web?<\/h2>\n
\n
\n
Tipos de arquitetura de aplicativos web<\/h2>\n
Arquitetura de p\u00e1gina \u00fanica<\/h3>\n
Vantagens da arquitetura SPA<\/h4>\n
\n
Contras da arquitetura SPA<\/h4>\n
\n
Arquitetura progressiva de aplicativos web<\/h3>\n
Pr\u00f3s da arquitetura PWA<\/h4>\n
\n
Contras da arquitetura PWA<\/h4>\n
\n
Arquitetura renderizada do lado do servidor<\/h3>\n
Pr\u00f3s da Arquitetura SSR<\/h4>\n
\n
Contras da arquitetura SSR<\/h4>\n
\n
Arquitetura de aplicativos pr\u00e9-renderizadas<\/h3>\n
https:\/\/myapp.com\/search\/foo+bar<\/code>), voc\u00ea est\u00e1 no lugar errado.<\/p>\nPr\u00f3s da arquitetura pr\u00e9-renderizada<\/h4>\n
\n
Contras da arquitetura pr\u00e9-renderizada<\/h4>\n
\n
Arquitetura de aplicativos isom\u00f3rficos<\/h3>\n
Pr\u00f3s da arquitetura isom\u00f3rfica<\/h4>\n
\n
Contras da arquitetura Isom\u00f3rfica<\/h4>\n
\n
Arquitetura orientada a servi\u00e7os<\/h3>\n
Pr\u00f3s da arquitetura orientada a servi\u00e7os<\/h4>\n
\n
Contras da arquitetura orientada a servi\u00e7os<\/h4>\n
\n
Arquitetura de microsservi\u00e7os<\/h3>\n
Pr\u00f3s da arquitetura de microsservi\u00e7os<\/h4>\n
\n
Contras da arquitetura de microsservi\u00e7os<\/h4>\n
\n
Arquitetura sem servidor<\/h3>\n
Pr\u00f3s da arquitetura sem servidor<\/h4>\n
\n
Contras da arquitetura sem servidor<\/h4>\n
\n
Camadas de arquitetura de aplicativos web<\/h2>\n
Camada de apresenta\u00e7\u00e3o<\/h3>\n
Camada de neg\u00f3cios<\/h3>\n
Camada de persist\u00eancia<\/h3>\n
Componentes de aplicativos web<\/h2>\n
Componentes do lado do servidor<\/h3>\n
DNS & Roteamento<\/h4>\n
Armazenamento de dados<\/h4>\n
\n
Cache<\/h4>\n
\n
Jobs e servi\u00e7os<\/h4>\n
Componentes do lado do cliente<\/h3>\n
Interface do usu\u00e1rio frontend<\/h4>\n
L\u00f3gica comercial do lado do cliente<\/h4>\n
Modelos de componentes de aplicativos web<\/h3>\n
Um servidor, um banco de dados<\/h4>\n
M\u00faltiplos servidores, um banco de dados<\/h4>\n
M\u00faltiplos servidores, m\u00faltiplos bancos de dados<\/h4>\n
Servi\u00e7os de aplicativos<\/h4>\n
Melhores pr\u00e1ticas para arquitetura de aplicativos web<\/h2>\n
1. Torne seu frontend responsivo<\/h3>\n
2. Monitore o tempo de carregamento<\/h3>\n
3. Prefira o PWA sempre que poss\u00edvel<\/h3>\n
4. Mantenha sua base de c\u00f3digo limpa e simples<\/h3>\n
\n
5. Automatize seus processos CI\/CD<\/h3>\n
6. Incorpore recursos de seguran\u00e7a<\/h3>\n
![\"Components](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/example-serverless-architecture.png\")
\n
\n
\n
\n
\n
\n
7. Colete feedback do usu\u00e1rio<\/h3>\n