Vídeo: Arquitetura cliente-servidor (Novembro 2024)
Uma das coisas que achei interessante no mundo do desenvolvimento nos últimos meses é como os aplicativos modernos estão voltando a colocar mais inteligência no cliente, em vez de no servidor. O modelo cliente-servidor não é novidade: é a maneira como os aplicativos tradicionais são criados há anos, com aplicativos rich client conversando com aplicativos do lado do servidor. Mas na era da Web, e até da Web 2.0, o foco passou para aplicativos da Web nos quais a maior parte da inteligência estava no servidor da Web (normalmente em servidores de aplicativos baseados em Java) e o cliente era apenas uma simples página da Web em um navegador em que, toda vez que você clica, carrega uma nova página.
Recentemente, porém, o amadurecimento de HTML5, CSS e, principalmente, JavaScript, está levando os desenvolvedores a colocar inteligência e processamento reais na própria página da Web. Em particular, vimos o surgimento de uma variedade de estruturas baseadas em JavaScript do cliente, que facilitam a criação de front-ends inteligentes que são executados completamente em um navegador da Web moderno. Os navegadores envolvidos são tipicamente aqueles baseados no mecanismo Webkit, incluindo Chrome e Safari, mas a maioria dos aplicativos parece funcionar bem nas versões atuais do Firefox e do Internet Explorer. Você acaba com uma página da Web mais complexa que muda dinamicamente, puxando dados do servidor conforme necessário.
Três estruturas MVC, em particular, parecem estar recebendo a maior atenção: Backbone.js, Ember.js e Angular.js. (MVC significa model-view-controller - é essencialmente a arquitetura por trás da computação de cliente da Web. O "js" significa JavaScript.) Essencialmente, tudo isso é fruto da abordagem AJAX (Asynchronous JavaScript and XML) popular na última década ou então, mas ficando muito mais maduro e quase padronizado. A idéia é colocar mais do estado e da inteligência no navegador e fazer com que o navegador se conecte às APIs REST do lado do servidor.
A espinha dorsal é talvez a mais básica e mínima dessas estruturas; é usado em várias extensões por muitos sites populares. O Ember surgiu de uma estrutura chamada Sproutcore, que a Apple apoiava, e é uma estrutura muito mais abrangente, projetada para permitir que você execute aplicativos no estilo de desktop. É frequentemente usado com o Bootstrap - um conjunto de modelos para HTML e CSS criados originalmente pelos funcionários do Twitter. Angular é a alternativa do Google que parece estar algures no meio - algumas pessoas pensam que é um pouco mais flexível ou pelo menos "menos opinativo" que o Ember, mas mais abrangente que o Backbone. (Observe que o Google está pressionando os desenvolvedores a usar o Angular para melhorar a qualidade da codificação, mas internamente na verdade usa um conjunto de estruturas proprietário diferente.) Até a Microsoft adicionou ganchos no Visual Studio para essas estruturas.
Sendo esta a Web, existem dezenas de alternativas. Um dos mais interessantes que ouvi falar ultimamente é o Meteor, projetado para funcionar com JavaScript nos lados do cliente e do servidor. Mas isso ainda é muito cedo e ainda não conheço usuários reais. Enquanto isso, mais desenvolvedores estão jogando com o Node.js, geralmente usado para implementações de JavaScript no servidor.
A vantagem de tais estruturas parece clara. Aplicativos ricos para clientes web são mais poderosos que aplicativos thin clients, onde tudo é executado no servidor, eles podem fornecer uma interface de usuário melhor e oferecer a possibilidade de informações offline. Usando essas estruturas, você pode criar aplicativos ricos para o cliente da Web muito mais rápido do que você construindo tudo do zero e tirar proveito das comunidades que se desenvolvem em torno de cada uma delas.
Talvez o mais importante seja o fato de que você pode criar aplicativos móveis dimensionáveis para diferentes dispositivos sem precisar criar aplicativos nativos específicos. Ainda há um bom argumento para aplicativos nativos, que podem abordar mais diretamente os recursos específicos de cada plataforma. No entanto, muitos desenvolvedores descobriram que essas estruturas podem acelerar drasticamente o desenvolvimento de plataforma cruzada, principalmente quando usadas em conjunto com o PhoneGap, uma estrutura móvel de código aberto comprada pela Adobe e de código aberto no projeto Apache Cordova.
O celular, é claro, traz suas próprias limitações, incluindo a velocidade dos processadores e, talvez mais importante, a velocidade - e às vezes falta de - conectividade. Um motivo pelo qual as pessoas gostam de aplicativos em páginas da Web é que geralmente você pode baixar a funcionalidade básica por Wi-Fi ou uma conexão rápida e apenas obter os dados necessários, e não todo o design. Pacotes como o PhoneGap resolvem esse problema colocando o JavaScript em um aplicativo baixado.
No entanto, existem outros problemas com essas estruturas. Por definição, fazer mais computação no lado do cliente aumenta a complexidade em comparação com um aplicativo simples apenas para servidor e, de fato, algumas das desvantagens do antigo modelo cliente-servidor retornam. Os desenvolvedores precisam gerenciar o estado dos dois lados. O código em dois lugares significa que você precisa se concentrar na segurança nos dois lugares. Como uma equipe de desenvolvimento geralmente tem algumas pessoas trabalhando no cliente e outras no servidor, você tem problemas adicionais de comunicação. Por outro lado, alguns dos problemas mais antigos do cliente-servidor não voltam e você mantém os benefícios do software da Web. Este é um mundo muito mais orientado a padrões e orientado à comunidade, para que você não seja tão dependente de um único ambiente proprietário. Ao dividir as partes do cliente e do servidor, você também pode ter uma implementação mais limpa e simples do lado do servidor, que apenas processa e não a interface do usuário, e pode exigir menos recursos como resultado. No entanto, você ainda tem a vantagem de poder atualizar todos os clientes de uma vez, pois normalmente o navegador carrega o código do servidor quando o aplicativo é chamado.
Estamos vendo claramente uma mudança em direção a clientes mais inteligentes da Web - não em todos os casos, mas em muitos aplicativos novos. É muito mais difícil pegar aplicativos antigos e movê-los para esse modelo, mas também estamos vendo alguns deles. Não é bem o modelo antigo de cliente-servidor, mas está ficando muito mais próximo.
