Neste post eu quero propor uma discussão sobre Presentation Architecture, mais especificamente sobre front-end web, com processamento client-side (no browser) e consumindo serviços (XML/JSON, SOAP, REST, WebSockets, etc,). Para que possamos perceber todo o potencial dessa abordagem, devemos entender as vantagens e as implicações (trade-offs) de cada uma de suas três características básicas: - Web; - Processamento client-side (browser); - Consumo de serviços. Vamos lá!

1. Service Oriented Front-End Architecture
por Cristiano Gomes
Neste post eu quero propor uma discussão sobre Presentation Architecture,
mais especificamente sobre front-end web, com processamento client-side (no
browser) e consumindo serviços (XML/JSON, SOAP, REST, WebSockets,
etc,).
Para que possamos perceber todo o potencial dessa abordagem, devemos
entender as vantagens e as implicações (trade-offs) de cada uma de suas três
características básicas:
§ Web;
§ Processamento client-side (browser);
§ Consumo de serviços.
Vamos lá!
Web: As principais tecnologias web - HTML, CSS e JavaScript, são, de modo
geral, padronizadas e independentes de fornecedor. De tal sorte que a mesma
página construída com tais tecnologias pode ser visualizada da mesma
maneira em diferentes browsers e diferentes sistemas operacionais (incluindo
o mundo mobile/tablets). A curva de aprendizado para estas tecnologias é tão
curta ou menor do que a curva de aprendizado para linguagens de
programação populares como C# ou Java, que tipicamente possuem diversos
módulos e frameworks. Na minha opinião, uma vantagem importante (talvez
a principal) para nós, provedores de soluções para diferentes clientes, é que a
mesma base de conhecimento pode ser empregada em diferentes cenários e
clientes (o mesmo não é possível com ferramentas de fornecedores, que
mudam de versão para versão, por vezes exigindo considerável capacitação
adicional). É notável a existência de limitações para aplicações web, com
relação ao uso/consumo de recursos locais (na máquina cliente). É verdade
que tais restrições podem ser contornadas de diferentes maneiras, porém,
utilizando outras tecnologias para tanto.
Processamento client-side (browser): Realizar o processamento
necessário para apresentar conteúdo ao usuário e tratar suas entradas e
eventos, até então era uma tarefa para o servidor de aplicações. Escalar uma
infraestrutura de servidores de aplicações é uma tarefa que poucos clientes
conseguem realizar de modo apropriado. São inúmeros os casos de problemas

2. de desempenho causados por mal dimensionamento ou má configuração da
infraestrutura responsável por aplicações web. Além do processamento, tais
aplicações consomem grande volume de memória para armazenar objetos na
sessão do usuário. Distribuir esse processamento e carga de objetos entre os
clientes da aplicação desonera consideravelmente a infraestrutura. Ou seja,
todo o MVC fica na camada cliente (no browser).
Consumo de serviços: As vantagens de expor funcionalidades em forma de
serviços estão relacionadas a princípios básicos da construção de softwares,
como o encapsulamento e desacoplamento. O tema serviços é bastante amplo,
por isso, me limitarei aos aspectos relacionados à exposição de
funcionalidades para alimentar aplicações web. Talvez em um outro post
possamos falar especificamente sobre SOA, API e afins. Sob este aspecto, os
serviços cumprem um papel simples, provendo dados e funcionalidades à
camada de apresentação, representando os pontos de acesso aos diferentes
processos, sistemas, funcionalidades e dados.
A percepção que tenho é de que a união destas três características nos permite
entregar aplicações que não dependem da plataforma tecnológica, distribuem
a carga de processamento e preservam recursos nos servidores, rapidamente
conferem ao usuário um ar de renovação tecnológica e atendem a diversos
canais/dispositivos . Eu explico.
Aplicações que não dependem da plataforma tecnológica, uma vez que as
principais plataformas do mercado, como Java e .NET, estão aptas à
construção e entrega de serviços, sejam eles pertencentes a uma
arquitetura orientada a serviços tradicional ou mesmo serviços construídos
de forma tática, para atender requisitos funcionais específicos e ad-hoc.
Distribuem a carga de processamento e preservam recursos nos servidores
porque, diferente de tecnologias como JSP, JSF, PHP ou ASP.NET, o
conteúdo estático e dinâmico não é preparado no lado servidor, mas sim no
cliente (browser). Utilizando JavaScript através de frameworks ou código
customizado, todo o conteúdo dinâmico é recuperado, tratado e apresentado
através da camada cliente – o browser.
Rapidamente conferem ao usuário um ar de renovação tecnológica, pois o
desenvolvimento web traz resultados visuais impactantes quando aliado a
disciplinas como identidade visual, usabilidade e experiência do usuário.

3. Atendem a diversos canais/dispositivos ao desenvolvermos aplicações
utilizando as tecnologias mencionadas previamente (HTML, CSS e JavaScript)
e utilizando o conceito de Responsive Design, ou Design Responsivo, que
prevê a adaptação do formato e do conteúdo de uma página às dimensões do
dispositivo cliente, podendo ser um desktop, um tablet ou um smartphone.