051.2 Lição 1

Ao usar sistemas online, é muito provável que em algum momento você tenha dado de cara com uma mensagem como a que vemos em Exemplo de tela mostrada enquanto uma solicitação está sendo processada.

Vamos dar um passo para trás e analisar o contexto em que essa mensagem apareceu. Digamos que você esteja tentando acessar sua conta bancária por meio do site do seu banco. Para acessar o site em seu laptop, você usa um tipo de software (ou seja, aplicativo) chamado navegador web, como o Google Chrome ou o Firefox. Nesse caso, o navegador do seu computador envia uma solicitação para outro computador que hospeda o site. Este tipo específico de computador é chamado de servidor. Os servidores são especialmente projetados para funcionar 24 horas por dia, 7 dias por semana, atendendo sempre a novas solicitações vindas de todas as partes do mundo.

Portanto, um servidor é um computador, exatamente como aquele que você usa para trabalhar, jogar games e realizar tarefas de programação. Porém, há uma diferença importante: um servidor normalmente direciona todos os seus recursos para o aplicativo de software executado nele. Neste exemplo, o software é um aplicativo web, um programa de computador executado no servidor.

Em Exemplo de tela mostrada enquanto uma solicitação está sendo processada, o servidor recebeu uma solicitação de um navegador e o aplicativo em execução no servidor está processando a operação resultante. Essa operação pode ser a consulta a um banco de dados para encontrar as informações de um usuário ou a comunicação com outro servidor para verificar um desconto especial no próximo empréstimo do usuário.

Neste exemplo, o navegador em sua máquina seria chamado de aplicativo cliente ou, simplesmente, cliente. O cliente interage com o servidor remoto.

A comunicação de rede entre cliente e servidor pode ocorrer dentro de uma rede corporativa ou através da rede mundial que chamamos de internet. Uma característica comum da interação cliente-servidor é que um servidor pode estabelecer múltiplos contatos com muitos clientes. Pense no exemplo anterior: o site de um banco hospedado em um servidor pode atender a milhares de solicitações por minuto de vários locais, cada uma de um usuário diferente tentando acessar sua conta bancária pessoal.

Nem todos os cenários são estruturados como um navegador interagindo com um servidor que faz quase todo o processamento. Em alguns casos, o cliente pode ser a instância principal de processamento; esse conceito é chamado de fat client (ou thick client) — em português, “cliente gordo”. Esse tipo de cliente armazena e processa a maioria das tarefas em vez de depender dos recursos do servidor. Já em nosso exemplo do banco o navegador é um thin client (“cliente magro”), que depende do servidor para computar e retornar informações através da rede.

Um exemplo de fat client é um aplicativo de games para desktop: a maior parte do armazenamento e processamento de dados é feito localmente, usando a GPU, RAM, CPU e espaço em disco do computador para processar as informações. Esse tipo de aplicativo raramente depende de um servidor externo, especialmente se o jogo estiver sendo executado offline.

Ambas as abordagens têm prós e contras: para um thick client, a instabilidade da rede é um problema menor do que para um um thin client que depende de um servidor remoto, mas as atualizações de software podem ser mais difíceis de realizar, além de o fat client exigir mais recursos do computador. Um thin client implica em custos mais baixos, o que pode ser uma grande vantagem. Para qualquer tipo de cliente, fornecer dados pessoais a um aplicativo de terceiros pode ser um problema.

Um aplicativo web é um software que é executado em um servidor, processa as interações do usuário e é contatado por clientes fat ou thin através de uma rede de computadores. Nem todos os sites são considerados aplicativos web: as páginas web estáticas simples, sem interatividade, não são consideradas aplicativos web, já que o servidor não executa um aplicativo para processar as ações solicitadas pelo cliente.

Muitos aplicativos web podem ser divididos em dois grupos: o aplicativo de página única (SPA) e o aplicativo de páginas múltiplas (MPA). Um SPA possui apenas uma página web na qual ocorre toda a troca e carregamento de dados sem a necessidade de redirecionar o usuário para outra página web dentro do aplicativo. Um MPA, por sua vez, inclui múltiplas páginas web. Uma alteração de dados pode atualizar a mesma página web que originou a ação ou redirecionar o usuário para outra página web.

Consideremos o exemplo anterior, em que um usuário deseja verificar as transações mais recentes de sua conta no site do banco. Imagine que uma transação seja realizada após o carregamento da página web. Caso o aplicativo web do banco seja um SPA, a nova transação será exibida automaticamente na mesma página web, sem redirecionar o usuário para uma nova página. Se o usuário quiser verificar seus empréstimos, as novas informações também serão exibidas na mesma página, evitando a necessidade de redirecionar o usuário. Dessa forma, a navegação é simplificada.

No caso de um MPA, quando o usuário solicita a página de empréstimos, o servidor precisa redirecionar o usuário para um novo local, ou seja, outra página web.

Um exemplo famoso de aplicativo web SPA é o Google Mail (Gmail). Ele não redireciona o usuário para uma página completamente diferente quando, por exemplo, o usuário deseja exibir a pasta de spam; o aplicativo simplesmente atualiza a parte específica da tela que mostra todas as mensagens de spam, permanecendo na mesma página web.

Um aplicativo MPA famoso, por sua vez, é a Amazon.com, a gigante do comércio eletrônico, em que cada item está localizado em uma página web distinta.

Uma vantagem de um MPA sobre um SPA é que a análise de dados (web analytics) é muito mais fácil de coletar e medir. Isso é essencial para ajudar os desenvolvedores a otimizar os resultados de pesquisa na Internet.

Normalmente, um aplicativo web é dividido em duas partes distintas: frontend e backend. O frontend é a camada de visualização, na qual o usuário interage com um navegador por meio dos elementos da página, clicando, selecionando ou digitando. É aqui que os dados do servidor são recebidos, formatados e exibidos ao usuário por meio do navegador.

O backend costuma ser a maior parte de um aplicativo web. Ele compreende a lógica de negócios, handlers de comunicação, a maior parte do processamento de dados e o armazenamento de dados. O armazenamento de dados emprega um sistema separado de gerenciamento de banco de dados conectado ao backend.

O frontend e o backend se comunicam entre si. As solicitações de dados são encaminhadas pelo frontend para o backend e os dados retornados pelo backend são recebidos, formatados e exibidos pelo frontend para o usuário.

Em nosso exemplo simples de busca da última transação na conta bancária de um usuário, a ação é interpretada pelo frontend do aplicativo, que está sendo executado no navegador do computador do usuário. Essa solicitação é então enviada pela internet para o backend do aplicativo, que valida se o usuário tem permissão para realizar a ação, encontra os dados e retorna a lista de transações para o frontend carregado no navegador. O navegador então formata e exibe os dados ao usuário.

Nenhum software é útil se não conseguir se comunicar com os componentes internos e externos. Então, como o cliente pode se comunicar com o aplicativo web? Como o frontend pode enviar dados para o backend?

Os aplicativos de software se comunicam entre si por meio de uma interface de programação de aplicativos (API), executada por meio de protocolos básicos de comunicação pela Internet. Protocolos são padrões e regras desenvolvidos para garantir que dois ou mais aplicativos troquem comandos e dados.

O principal benefício de uma API é separar as diferentes partes do aplicativo, permitindo ao mesmo tempo que cooperem no processamento de dados. As APIs também centralizam o fluxo de dados em canais predefinidos, funcionando como uma passagem que garante que todos utilizem o mesmo caminho para ir e vir. Nos aplicativos web, as APIs são essenciais, pois possibilitam a interação do usuário, a entrega de informações processadas, as solicitações de armazenamento de dados e muitas outras tarefas. Uma API pode ser utilizada pelo cliente para solicitar ações que serão executadas no servidor, por exemplo.

Voltemos ao exemplo do aplicativo bancário na web. Para entrar em uma conta por meio de um aplicativo web, o usuário geralmente digita dados como nome de usuário e senha em determinados campos de texto e clica no botão “Login”. O navegador captura essas informações e chama uma API de backend. O aplicativo web em execução no servidor remoto recebe os dados, valida o usuário, verifica o direito de acesso e, finalmente, envia uma resposta de volta ao navegador. Para que o usuário se comunique com o servidor, é obrigatório que tanto o cliente quanto o servidor enviem e recebam dados. Isso é possibilitado pelas APIs.

Observe que o aplicativo web do banco não expõe outras informações confidenciais; ele mostra ao usuário apenas os campos permitidos e necessários para a interação desejada. O resto fica oculto.

A comunicação entre APIs pode ser baseada em designs e protocolos muito diferentes. O protocolo de transferência de hipertexto (HTTP) é, de longe, o protocolo usado com mais frequência em aplicativos web. Hipertexto é um texto com links para outros textos, o conceito subjacente aos links nas páginas HTML. Os hiperlinks formam, portanto, a base para a construção de páginas web e sua exibição nos navegadores.

O HTTP foi projetado para aplicativos cliente-servidor, em que os recursos são solicitados de um servidor e retornados ao cliente pela rede usando uma estrutura predefinida especificada pelo protocolo HTTP.

Para um aplicativo web estruturado, os engenheiros de software projetam o aplicativo com partes ou módulos separados. Essa separação permite definir claramente as tarefas e responsabilidades, levando a um desenvolvimento mais rápido e uma manutenção mais simples.

Vejamos, por exemplo, um aplicativo com dois módulos internos: um que implementa a lógica de negócios e outro que conta com a integração de um terceiro. Esse terceiro é uma empresa externa que fornece sua API para algum propósito específico -– digamos, previsão do tempo. Se o servidor meteorológico estiver inativo, será impossível obter a previsão do tempo e, se esses dados forem essenciais para o resultado final processado, o usuário poderá passar por um perrengue temporário, a menos que haja uma fonte alternativa para os dados.

Agora imagine que esse provedor terceirizado é substituído e o novo tem uma forma diferente de lidar com a mesma API. Graças à separação dos módulos, os desenvolvedores de apenas um módulo só precisam mantê-lo atualizado; a lógica de negócios no outro módulo não precisa ser alterada, ou exigirá apenas atualizações mínimas.

A necessidade de estruturas de processos claras também influencia o design das APIs a fim de torná-las mais fáceis de usar. O conceito de transferência de estado representacional (REST) é um estilo arquitetônico com um conjunto de diretrizes para projetar e implementar o acesso aos dados em um aplicativo.

Existem seis princípios REST. Para simplificar, explicaremos os três mais relevantes para esta lição:

As APIs que seguem os princípios REST são chamadas RESTful e, na web moderna, o design REST é seguido por muitos aplicativos web. Embora uma API RESTful não precise implementar esses princípios usando o protocolo HTTP, ele é quase universalmente usado no modelo REST devido à sua robustez, simplicidade e onipresença no ambiente da World Wide Web.

Existem dezenas de estilos e padrões arquitetônicos que tentam organizar as estruturas dos aplicativos web. Como quase tudo no mundo da informática, não existe um "vencedor", apenas um conjunto de prós e contras para cada modelo. Um paradigma importante é a chamada arquitetura de microsserviços, que foi criada como uma alternativa à antiga arquitetura monolítica.

A arquitetura de microsserviços é um modelo de software composto por vários serviços interdependentes que, juntos, formam o aplicativo final. Esta arquitetura visa descentralizar a base de código: múltiplas camadas de software são divididas em vários aplicativos menores para simplificar a manutenção (Arquitetura de microsserviços).

Em contraste, uma arquitetura monolítica contém todos os serviços e recursos do aplicativo em um só sistema (Arquitetura monolítica).

As imagens mostram que o modelo de microsserviço é descentralizado e o aplicativo depende de diversos serviços, cada um com seu próprio banco de dados, base de código e até recursos de servidor. Como o nome indica, cada microsserviço é menor que seu equivalente monolítico, o qual assume a responsabilidade por todos os serviços.

O aplicativo monolítico encapsula todos os seus recursos em uma única unidade. Toda a lógica de negócios, dados e base de código são centralizados em um enorme bloco, razão pela qual é chamado de “monólito”.

Os usuários dificilmente percebem se um aplicativo web está sendo executado como um modelo monolítico ou de microsserviço; a escolha por um ou outro deve ser invisível. Nosso aplicativo bancário, por exemplo, poderia ser um monólito no qual toda a lógica de negócios relativa a pagamentos, transações, empréstimos etc. estivesse localizada na mesma base de código executada em um ou mais servidores. Por outro lado, se ele utilizasse um sistema de microsserviço, provavelmente teria um microsserviço dedicado ao processamento de pagamentos e outro apenas para emissão de empréstimos. Este último chamaria outro microsserviço para analisar a probabilidade de o solicitante deixar de pagar. O aplicativo poderia ter milhares de serviços menores.

A abordagem monolítica requer mais sobrecarga de manutenção conforme o aplicativo cresce, especialmente se houver várias equipes trabalhando na mesma base de código. Com os recursos de software centralizados, é altamente provável que uma equipe acabe mexendo em algo que interrompa uma parte do aplicativo de outra equipe. Isso pode gerar uma verdadeira dor de cabeça no caso de aplicativos maiores, principalmente quando há um grande número de equipes.

Os microsserviços são muito mais flexíveis nesse aspecto, pois cada serviço é gerenciado por apenas uma equipe (e, é claro, uma equipe pode gerenciar mais de um serviço). As alterações de código são feitas facilmente e os recursos concorrentes não chegam a ser um problema. Como os serviços estão interligados, qualquer ponto de falha pode ter um impacto negativo em todo o aplicativo. Além disso, como existem diversas instâncias de banco de dados, servidores e APIs externas comunicando-se entre si, a resiliência de todo o aplicativo só poderá ser tão boa quanto o seu microsserviço mais fraco.

Uma vantagem da abordagem monolítica é ter uma fonte de dados centralizada, o que facilita evitar a duplicação de dados. A abordagem também reduz o consumo de recursos da nuvem, porque um servidor maior precisa de menos recursos computacionais do que diversos servidores descentralizados. Um aplicativo de microsserviço com aproximadamente o mesmo tamanho impõe uma carga maior à nuvem.