031.2 Lição 1
Certificação: |
Web Development Essentials |
---|---|
Versão: |
1.0 |
Tópico: |
031 Desenvolvimento de software e tecnologias web |
Objetivo: |
031.2 Arquitetura de aplicativos web |
Lição: |
1 de 1 |
Introdução
A palavra aplicativo tem um amplo significado no jargão tecnológico. Quando o aplicativo é um programa tradicional, executado localmente e auto-suficiente em sua finalidade, tanto a interface operacional do aplicativo quanto os componentes de processamento de dados são integrados em um único “pacote”. Um aplicativo web é diferente porque adota o modelo cliente/servidor e sua parte cliente é baseada em HTML, que é obtido do servidor e, em geral, processado por um navegador.
Clientes e servidores
No modelo cliente/servidor, parte do trabalho é feito localmente no lado do cliente e parte do trabalho é feito remotamente, no lado do servidor. As tarefas realizadas por cada parte variam de acordo com a finalidade do aplicativo, mas em geral cabe ao cliente fornecer uma interface para o usuário e exibir o conteúdo de forma atraente. Cabe ao servidor executar a parte operacional do aplicativo, processando e respondendo às solicitações feitas pelo cliente. Em um aplicativo de compras, por exemplo, o aplicativo cliente apresenta uma interface para o usuário escolher e pagar pelos produtos, mas a fonte de dados e os registros da transação são mantidos no servidor remoto, acessado pela rede. Os aplicativos web realizam essa comunicação pela internet, geralmente por meio do Protocolo de Transferência de Hipertexto (HTTP).
Depois de carregado pelo navegador, o lado do cliente do aplicativo inicia a interação com o servidor sempre que necessário ou conveniente. Os servidores de aplicativos web oferecem uma interface de programação de aplicativos (API) que define as solicitações disponíveis e como devem ser feitas. Assim, o cliente constrói uma solicitação no formato definido pela API e a envia ao servidor, que verifica os pré-requisitos da solicitação e envia de volta a resposta apropriada.
Enquanto o cliente, na forma de um aplicativo móvel ou navegador de desktop, é um programa independente em relação à interface do usuário e às instruções para se comunicar com o servidor, o navegador deve obter a página HTML e os componentes associados — como imagens, CSS e JavaScript — que definem a interface e as instruções para comunicação com o servidor.
As linguagens de programação e as plataformas usadas por cliente e servidor são independentes, mas empregam um protocolo de comunicação mutuamente compreensível. A parte do servidor é quase sempre realizada por um programa sem interface gráfica, rodando em ambientes de computação de alta disponibilidade, de forma a estar sempre pronto para responder às solicitações. Já a parte do cliente é executada em qualquer dispositivo capaz de renderizar uma interface HTML, como os smartphones.
Além de ser imprescindível para determinadas finalidades, a adoção do modelo cliente/servidor permite que um aplicativo otimize diversos aspectos de desenvolvimento e manutenção, já que cada parte pode ser projetada para sua função específica. Um aplicativo que exibe mapas e rotas, por exemplo, não precisa ter todos os mapas armazenados localmente. São necessários apenas os mapas relativos à localização que interessa ao usuário e, portanto, somente esses mapas são solicitados ao servidor central.
Os desenvolvedores têm controle direto sobre o servidor; assim, eles também podem modificar o cliente fornecido por ele. Isso permite que os desenvolvedores aprimorem o aplicativo, em maior ou menor grau, sem que o usuário precise formalmente instalar novas versões.
O lado do cliente
Um aplicativo web deve ser executado da mesma maneira em todos os navegadores mais populares, desde que o navegador esteja atualizado. Alguns navegadores podem ser incompatíveis com as inovações recentes, mas apenas os aplicativos experimentais usam recursos ainda não amplamente adotados.
Os problemas de incompatibilidade eram mais comuns no passado, quando cada navegador tinha seu próprio motor de renderização e havia menos cooperação na formulação e adoção de padrões. O motor (ou mecanismo) de renderização é o principal componente do navegador, pois é responsável por transformar o HTML e outros componentes associados nos elementos visuais e interativos da interface. Alguns navegadores, sobretudo o Internet Explorer, necessitavam de um tratamento especial no código para não quebrar o funcionamento esperado das páginas.
Hoje, as diferenças entre os navegadores principais são mínimas e as incompatibilidades, raras. Na verdade, os navegadores Chrome e Edge usam o mesmo mecanismo de renderização (chamado Blink). O navegador Safari e outros oferecidos na iOS App Store usam o mecanismo WebKit. O Firefox usa um mecanismo chamado Gecko. Esses três mecanismos são responsáveis por praticamente todos os navegadores usados hoje. Embora desenvolvidos separadamente, os três motores são projetos de código aberto e há cooperação entre seus desenvolvedores, o que facilita a compatibilidade, a manutenção e a adoção de padrões.
Como os desenvolvedores de navegadores se esforçaram muito para preservar a compatibilidade, o servidor normalmente não está vinculado a um único tipo de cliente. Em princípio, um servidor HTTP pode se comunicar com qualquer cliente que também seja capaz de se comunicar via HTTP. Em um aplicativo de mapa, por exemplo, o cliente pode ser um aplicativo móvel ou um navegador que carrega a interface HTML do servidor.
Variedades de clientes web
Existem aplicativos móveis e de desktop cuja interface é renderizada a partir de HTML e, como os navegadores, podem usar JavaScript como linguagem de programação. Porém, ao contrário do cliente carregado no navegador, o HTML e os componentes necessários para o funcionamento de um cliente nativo estão presentes localmente desde a instalação do aplicativo. Na verdade, um aplicativo que funciona dessa maneira é praticamente idêntico a uma página HTML (é provável que ambos sejam renderizados pelo mesmo mecanismo). Existem também os aplicativos web progressivos (Progressive Web Apps ou PWA), um mecanismo que permite empacotar clientes de aplicativos web para uso offline — limitado a funções que não requerem comunicação imediata com o servidor. Em relação às capabilidades do aplicativo, não há diferença entre rodá-lo no navegador ou empacotado em um PWA; porém, neste último, o desenvolvedor tem mais controle sobre o que é armazenado localmente.
Renderizar interfaces HTML é uma atividade tão recorrente que o mecanismo é geralmente um componente de software separado, presente no sistema operacional. Sua presença independente permite que diferentes aplicativos o incorporem sem precisar incluí-lo no pacote do aplicativo. Esse modelo também delega a manutenção do motor de renderização ao sistema operacional, facilitando as atualizações. É muito importante manter esse componente crucial sempre atualizado para evitar possíveis falhas.
Independentemente do método de fornecimento, os aplicativos escritos em HTML são executados em uma camada de abstração criada pelo mecanismo, que funciona como um ambiente de execução isolado. Em particular, no caso de um cliente que roda no navegador, o aplicativo tem à sua disposição apenas os recursos oferecidos pelo navegador. Recursos básicos, como a interação com elementos de página e solicitação de arquivos por HTTP, estão sempre disponíveis. Os recursos que podem conter informações confidenciais, como o acesso a arquivos locais, a localização geográfica, câmera e microfone, requerem uma autorização explícita do usuário antes que o aplicativo possa usá-los.
As linguagens de um cliente web
O elemento central de um cliente de aplicativo web executado no servidor é o documento HTML. Além de apresentar de forma estruturada os elementos da interface exibidos pelo navegador, o documento HTML contém os endereços de todos os arquivos necessários para a apresentação e funcionamento corretos do cliente.
O HTML sozinho não tem muita versatilidade para construir interfaces mais elaboradas, nem recursos de programação de finalidade geral. Por esse motivo, um documento HTML que deve funcionar como um aplicativo cliente vem sempre acompanhado por um ou mais conjuntos de CSS e JavaScript.
O CSS pode ser fornecido como um arquivo separado ou diretamente no próprio arquivo HTML. O principal objetivo do CSS é refinar a aparência e o layout dos elementos da interface HTML. Embora isso não seja estritamente necessário, as interfaces mais sofisticadas geralmente requerem modificações nas propriedades CSS dos elementos para atender às suas necessidades.
O JavaScript é um componente praticamente indispensável. Os procedimentos escritos em JavaScript respondem a eventos no navegador. Esses eventos podem ser causados pelo usuário ou ser não-interativos. Sem o JavaScript, um documento HTML fica praticamente limitado a texto e imagens. O uso do JavaScript em documentos HTML permite estender a interatividade muito além de hiperlinks e formulários, transformando a página exibida pelo navegador em uma interface de aplicativo convencional.
O JavaScript é uma linguagem de programação de propósito geral, mas seu principal uso é em aplicativos web. Os recursos do ambiente de execução do navegador são acessíveis por meio de palavras-chave em JavaScript, utilizadas em um script para realizar a operação desejada. O termo document
, por exemplo, é usado no código JavaScript para se referir ao documento HTML associado a ele. No contexto da linguagem JavaScript, document
é um objeto global com propriedades e métodos que podem ser usados para obter informações de qualquer elemento no documento HTML. Além disso, podemos usar o objeto document
para modificar seus elementos e associá-los a ações personalizadas escritas em JavaScript.
Um aplicativo cliente baseado em tecnologias web é multiplataforma, pois pode ser executado em qualquer dispositivo que possua um navegador compatível.
Porém, o fato de estarem confinados ao navegador impõe limitações aos aplicativos web em comparação com os aplicativos nativos. A intermediação realizada pelo navegador permite uma programação de alto nível e aumenta a segurança, mas também aumenta as exigências de processamento e o consumo de memória.
Os desenvolvedores estão continuamente aprimorando os navegadores para fornecer mais recursos e melhorar o desempenho dos aplicativos em JavaScript, mas existem aspectos intrínsecos à execução de scripts como o JavaScript que os deixam em desvantagem na comparação com programas nativos para o mesmo hardware.
Um recurso que melhora bastante o desempenho dos aplicativos JavaScript em execução no navegador é o WebAssembly. O WebAssembly é um tipo de JavaScript compilado que produz código-fonte escrito em uma linguagem mais eficiente de nível inferior, como a linguagem C. O WebAssembly pode acelerar principalmente as atividades de uso intensivo do processador, pois evita grande parte da tradução realizada pelo navegador ao executar um programa escrito em JavaScript convencional.
Independentemente dos detalhes de implementação do aplicativo, todos os códigos HTML, CSS, JavaScript e arquivos multimídia devem primeiro ser obtidos do servidor. O navegador obtém esses arquivos como se fosse uma página da internet, ou seja, por meio de um endereço acessado pelo navegador.
Uma página web que atua como uma interface para um aplicativo web é como um documento HTML simples, mas com comportamentos adicionais. Nas páginas convencionais, o usuário é direcionado para outra página ao clicar em um link. Os aplicativos web podem apresentar sua interface e responder aos eventos do usuário sem carregar novas páginas na janela do navegador. A modificação desse comportamento padrão das páginas HTML é feita por meio da programação em JavaScript.
Um cliente de webmail, por exemplo, exibe as mensagens e alterna entre as pastas sem sair da página. Isso é possível porque o cliente usa JavaScript para reagir às ações do usuário e fazer solicitações apropriadas ao servidor. Se o usuário clicar no assunto de uma mensagem na caixa de entrada, um código JavaScript associado a esse evento solicitará o conteúdo dessa mensagem ao servidor (usando a chamada API correspondente). Assim que o cliente recebe a resposta, o navegador exibe a mensagem na parte apropriada da mesma página. Clientes de webmail diferentes podem adotar estratégias diferentes, mas todos empregam o mesmo princípio.
Portanto, além de fornecer ao navegador os arquivos que compõem o cliente, o servidor também deve ser capaz de atender a solicitações como a do cliente de webmail quando solicita o conteúdo de uma determinada mensagem. Cada requisição que o cliente pode fazer está vinculada a um procedimento predefinido de resposta no servidor, cuja API pode definir diferentes métodos para identificar o procedimento ao qual a requisição se refere. Os métodos mais comuns são:
-
Endereços, através de um Uniform Resource Locator (URL)
-
Campos no cabeçalho HTTP
-
Métodos GET/POST
-
WebSockets
Um método pode ser mais adequado do que outro, dependendo da finalidade da solicitação e de outros critérios levados em consideração pelo desenvolvedor. Em geral, os aplicativos web usam uma combinação de métodos, cada um em uma circunstância específica.
O paradigma Representational State Transfer (REST) é amplamente utilizado para a comunicação nos aplicativos web, pois se baseia nos métodos básicos disponíveis em HTTP. O cabeçalho de uma solicitação HTTP começa com uma palavra-chave que define a operação básica a ser realizada: GET
, POST
, PUT
, DELETE
, etc., acompanhada por uma URL correspondente na qual a ação será aplicada. Se o aplicativo requer operações mais específicas, com uma descrição mais detalhada da operação solicitada, o protocolo GraphQL pode ser uma escolha mais adequada.
Os aplicativos desenvolvidos no modelo cliente/servidor estão sujeitos a instabilidades de comunicação. Por isso, o aplicativo cliente deve sempre adotar estratégias eficientes de transferência de dados para favorecer sua consistência e não prejudicar a experiência do usuário.
O lado do servidor
Apesar de ser o ator principal em um aplicativo web, o servidor é o lado passivo da comunicação, respondendo apenas às solicitações feitas pelo cliente. No jargão da web, servidor pode se referir à máquina que recebe as solicitações, ao programa que trata especificamente as solicitações HTTP ou ao script destinatário que produz uma resposta à solicitação. Esta última definição é a mais relevante no contexto da arquitetura de aplicativos web, mas todas estão intimamente relacionadas. Embora pertençam apenas parcialmente ao escopo do desenvolvedor do servidor de aplicativos, a máquina, o sistema operacional e o servidor HTTP não podem ser ignorados, pois são fundamentais para a execução do servidor de aplicativos e freqüentemente se cruzam.
Controlando os caminhos de solicitações
Os servidores HTTP, como o Apache e o NGINX, costumam precisar de alterações específicas de configuração para atender às necessidades do aplicativo. Por padrão, os servidores HTTP tradicionais associam diretamente o caminho indicado na solicitação a um arquivo no sistema de arquivos local. Se o servidor HTTP de um website mantiver seus arquivos HTML no diretório /srv/www
, por exemplo, uma solicitação com o caminho /en/about.html
receberá o conteúdo do arquivo /srv/www/en/about.html
como resposta, se o arquivo existir. Os sites mais sofisticados, e os aplicativos web em especial, exigem tratamentos personalizados para diferentes tipos de solicitações. Nesse cenário, parte da implementação do aplicativo consiste em modificar as configurações do servidor HTTP para atender aos requisitos do aplicativo.
Como alternativa, existem frameworks (estruturas) que permitem integrar o gerenciamento das solicitações HTTP e a implementação do código do aplicativo em um só lugar, permitindo que o desenvolvedor se concentre mais na finalidade do aplicativo do que nos detalhes da plataforma. No Node.js Express, por exemplo, todo o mapeamento de solicitações e a programação correspondente são implementados usando JavaScript. Como a programação dos clientes geralmente é feita em JavaScript, muitos desenvolvedores consideram uma boa ideia, do ponto de vista da manutenção do código, usar a mesma linguagem para o cliente e o servidor. Outras linguagens comumente usadas para implementar o lado do servidor, seja em frameworks ou em servidores HTTP tradicionais, são PHP, Python, Ruby, Java e C#.
Sistemas de gerenciamento de banco de dados
Fica a critério da equipe de desenvolvimento a forma como os dados recebidos ou solicitados pelo cliente são armazenados no servidor, mas existem diretrizes gerais que se aplicam à maioria dos casos. É conveniente manter o conteúdo estático — imagens, código JavaScript e CSS que não mudam no curto prazo — em arquivos convencionais, seja no próprio sistema de arquivos do servidor ou distribuídos em uma rede de fornecimento de conteúdo (CDN). Outros tipos de conteúdo, como mensagens de email em um aplicativo de webmail, detalhes do produto em um aplicativo de compras e logs de transações, são armazenados de forma mais conveniente em um sistema de gerenciamento de banco de dados (DBMS).
O tipo mais tradicional de sistema de gerenciamento de banco de dados é o banco de dados relacional. Nele, o criador do aplicativo define tabelas de dados e o formato de entrada aceito por cada tabela. O conjunto de tabelas do banco de dados contém todos os dados dinâmicos consumidos e produzidos pelo aplicativo. Um aplicativo de compras, por exemplo, pode ter uma tabela com os detalhes de cada produto da loja e uma tabela que registra os itens comprados por um usuário. A tabela de itens comprados contém referências às entradas na tabela de produtos, criando relações entre as tabelas. Essa abordagem ajuda a otimizar o armazenamento e o acesso aos dados, além de permitir consultas em tabelas combinadas utilizando a linguagem adotada pelo sistema de gerenciamento do banco de dados. A linguagem de banco de dados relacional mais popular é a Structured Query Language (SQL, pronuncia-se “sequel”), adotada pelos bancos de dados de código aberto SQLite, MySQL, MariaDB e PostgreSQL.
Uma alternativa aos bancos de dados relacionais é uma forma de banco de dados que não requer uma estrutura rígida para os dados. Esses bancos de dados são chamados de bancos de dados não-relacionais ou simplesmente NoSQL. Embora possam incorporar alguns recursos semelhantes aos encontrados nos bancos de dados relacionais, o foco está em permitir maior flexibilidade no armazenamento e acesso aos dados armazenados, entregando a tarefa de processamento desses dados para o próprio aplicativo. MongoDB, CouchDB e Redis são sistemas comuns de gerenciamento de bancos de dados não-relacionais.
Manutenção de conteúdo
Qualquer que seja o modelo de banco de dados adotado, os aplicativos precisam adicionar dados e provavelmente atualizá-los ao longo da vida útil dos aplicativos. Em alguns aplicativos, como o webmail, os próprios usuários fornecem dados ao banco de dados ao usar o cliente para enviar e receber mensagens. Em outros casos, como em um aplicativo de compras, é importante permitir que os mantenedores do aplicativo modifiquem o banco de dados sem ter de recorrer à programação. Muitas empresas, portanto, adotam algum tipo de sistema de gerenciamento de conteúdo (CMS), que permite que usuários não-técnicos administrem o aplicativo. Portanto, para a maioria dos aplicativos web, é necessário implementar pelo menos dois tipos de clientes: o cliente não-privilegiado, empregado por usuários comuns, e o cliente privilegiado, empregado por usuários especiais para manter e atualizar as informações apresentadas pelo aplicativo.
Exercícios Guiados
-
Qual linguagem de programação é usada junto com o HTML para criar clientes de aplicativos web?
-
Como a obtenção de um aplicativo web difere daquela de um aplicativo nativo?
-
Como um aplicativo web difere de um aplicativo nativo no acesso ao hardware local?
-
Cite uma característica de um cliente de aplicativo web que o diferencia de uma página web comum.
Exercícios Exploratórios
-
Qual recurso os navegadores modernos oferecem para mitigar o baixo desempenho dos clientes de aplicativos web que usam muita CPU?
-
Se um aplicativo web usa o paradigma REST para a comunicação cliente/servidor, qual método HTTP deve ser usado quando o cliente solicita que o servidor apague um recurso específico?
-
Cite cinco linguagens de script de servidor suportadas pelo servidor Apache HTTP.
-
Por que os bancos de dados não relacionais são considerados mais fáceis de manter e atualizar do que os bancos de dados relacionais?
Resumo
Esta lição trata dos conceitos e padrões em tecnologia e arquitetura de desenvolvimento web. O princípio é simples: o navegador executa o aplicativo cliente, que se comunica com o aplicativo principal que está em execução no servidor. Embora simples em princípio, os aplicativos web precisam combinar diversas tecnologias para adotar o princípio da computação de cliente e servidor pela web. A lição abrange os seguintes conceitos:
-
A função dos navegadores e servidores web.
-
Tecnologias e padrões comuns de desenvolvimento para a web.
-
Como os clientes web podem se comunicar com o servidor.
-
Tipos de servidores web e bancos de dados de servidores.
Respostas aos Exercícios Guiados
-
Qual linguagem de programação é usada junto com o HTML para criar clientes de aplicativos web?
JavaScript
-
Como a obtenção de um aplicativo web difere daquela de um aplicativo nativo?
Um aplicativo web não está instalado. Em vez disso, partes dele são executadas no servidor e a interface do cliente é executada em um navegador web comum.
-
Como um aplicativo web difere de um aplicativo nativo no acesso ao hardware local?
Todos os acessos aos recursos locais, como armazenamento, câmeras ou microfones, são mediados pelo navegador e requerem autorização explícita do usuário para funcionar.
-
Cite uma característica de um cliente de aplicativo web que o diferencia de uma página web comum.
A interação com as páginas web tradicionais restringe-se basicamente a hiperlinks e envio de formulários, ao passo que os clientes de aplicativos web estão mais próximos de uma interface de aplicativo convencional.
Respostas aos Exercícios Exploratórios
-
Qual recurso os navegadores modernos oferecem para mitigar o baixo desempenho dos clientes de aplicativos web que usam muita CPU?
Os desenvolvedores podem usar o WebAssembly para implementar as partes do aplicativo cliente que exigem um uso intensivo da CPU. O código do WebAssembly costuma ter melhor desempenho do que o JavaScript tradicional, pois requer menos tradução de instruções.
-
Se um aplicativo web usa o paradigma REST para a comunicação cliente/servidor, qual método HTTP deve ser usado quando o cliente solicita que o servidor apague um recurso específico?
REST relies on standard HTTP methods, so it should use the standard
DELETE
method in this case. -
Cite cinco linguagens de script de servidor suportadas pelo servidor Apache HTTP.
PHP, Go, Perl, Python e Ruby.
-
Por que os bancos de dados não relacionais são considerados mais fáceis de manter e atualizar do que os bancos de dados relacionais?
Ao contrário dos bancos de dados relacionais, os bancos de dados não relacionais não requerem que os dados se adaptem a estruturas predefinidas rígidas, sendo assim mais fácil implementar mudanças nas estruturas de dados sem afetar os dados existentes.