Minha Estrutura Web Ideal

Inicialmente pensei em intitular como "Estrutura Web Perfeita", mas acho que perfeição é um termo muito utópico para este contexto. Este é um assunto longo. Existem milhares de tutoriais na internet, e conseguir informação hoje, é como beber água de um hidrante. Tentarei modularizar o assunto, falando de uma estrutura macro aqui, e posteriormente entrando em detalhes de cada módulo.

Após quase 20 anos de desenvolvimento, eu já trabalhei com sistemas estruturados das mais diversas maneiras, e já criei meus próprios sistemas(muitos). O legal disto é você ter a experiência falando a seu favor, e na maioria das vezes o que eu percebo é que o mercado não usa o que é o melhor, mas o que está mais rentável ( para quem ? ).

Muitas vezes um fornecedor de um produto convence um cliente que o produto é bom (mesmo que não seja) e o cliente compra o produto, paga caro, e exige que isto seja usado, mesmo não sendo a melhor (ou sequer uma boa) opção.

Desenvolvedores são criados/educados nestes cenários, e passam pelo treinamento destes fornecedores, que fazer uma espécie de "lavagem cerebral", ensinando centenas de "padrões" e "boas práticas".

Em minha opinião, o melhor seria um sistema totalmente desacoplado, onde não importa qual a tecnologia dos outros módulos. Quem trabalha com terminais de linha de comando, sabe que funciona muito bem a transparência tecnológica neste contexto. Não importa qual tecnologia utilizada, eu tenho um protocolo para chamar um comando e uma resposta padrão. Eu tenho stdin, stdout e stderr sempre... Eu tenho código de retorno para me informar do sucesso ou não do comando... Pipes, etc.

Pesquisando para este artigo, encontrei uma boa referência deste conceito: https://staticapps.org/articles/why-build-static-apps/

Seria algo como:

• webapp - Modulo Web Estático, renderizado do lado do cliente(browser) com o uso de javascript/css, com o único controle do lado do servidor sendo o acesso de recursos restritos a autenticação válida. Todo acesso a informações para geração dinâmica de conteúdo, deveria ser requerido via requisições Ajax(XHR) REST ao módulo webapp-api. Pode ser considerado 3 tipos de comunicação: REST, WebSockets e "Push Notifications". Nenhuma outra interface além da webapp-api deve ser chamada.
• webapp-api - Modulo Rest para prover dados ao módulo webapp. Usando principalmente comunicações REST(JSON) permitindo um desacoplamento total e independência de plataforma usada no servidor, também pode prover Push Notifications e WebSockets. Sempre stateless (independente de sessão), recebendo token de autenticação sempre que necessário, usando SSL. Este módulo deverá ter acesso a um outro componente centralizador de informações se sessão session-api para permitir escalabilidade, e ao componente de acesso aos dados, data-module.
• session-api - Tratar sessão é um problema complicado em escalabilidade, recomendo tópicos em mensageria (MQ), por exemplo o Apache ActiveMQ: (http://activemq.apache.org/). Desta forma, você poderá ter redundância em seu controle de sessão, garantindo uma melhor escalabilidade.
• data-module - Para escalabilidade, aqui costuma ser o maior gargalo, normalmente não queremos overhead no gerenciamento de dados. Mas mesmo aqui, penso que mensageria deveria ser considerada como uma opção válida da mesma forma que no componente session-api. Tenho experiência onde a camada de dados foi substituída com sucesso por mensageria, antendendo picos de transações superiores a 800tps. Isto já é muito, mas além disto, esta estrutura facilita ações para ampliar este poder de processamento distribuído.

Esta separação permite substituir qualquer camada por mocks para criação e execução testes unitários, de performance, escalabilidade, penetração, segurança, ou qualquer outro tipo de teste imaginável em cada camada. Também modulariza o sistema de maneira que times separados possam trabalhar de maneira independente, com o menor impacto e conflito possível, apenas dependendo de um bom alinhamento do contrato de cada interface. Outra vantagem seria a possibilidade de reuso da API para outras interfaces, como por exemplo aplicação mobile, utilitários de linha de comando, ou integração com ferramentas de terceiros.

webapp

O browser deve receber um conteúdo estruturalmente estático, que será dinamicamente gerado pelo javascript, baseado em informações providas pelo servidor. Sim, eu sei que em dispositivos móveis antigos, o melhor pode ser entregar o conteúdo pré-renderizado, gerado dinamicamente no servidor, mas falarei minha sugestão sobre isto mais tarde.

Independente de ser conteúdo estático no servidor, continua existindo a necessidade de restringir acesso a alguns recursos, e isto requer uma interface de servidor, como um servlet, um CGI(sim o bom e velho CGI), um AuthenticationFilter ou qualquer outra interface que garanta que o usuário só acesse o conteúdo quando estiver em um contexto autenticado e atualmente válido. Isto, infelizmente, impede que seja usado um simples servidor web estático.

Todos sabemos que o javascript é poderoso o suficiente para renderizar qualquer coisa no cliente, e se no passado o processamento no lado do cliente era um problema, não é mais verdade atualmente. Bem em alguns dispositivos móveis ainda pode ser, mas em pouco tempo não será mais.

Normalmente, se você está tendo problemas de performance na renderização ou manipulação de objetos, você tem algo que precisa ser refatorado.

O front-end, deve ser tratado de forma componentizada, permitindo, via javascript, a reutilização de códigos. O W3C já possui drafts para componentização, mas atualmente a forma mais efetiva continua sendo no formato de plugins, muito utilizado pelo jQuery. Não digo usar o jQuery em si, mas o conceito é ótimo.

Sempre que me perguntam minha opinião sobre geração de html dinâmico do lado do servidor, como jstl, struts, ou algo do tipo, minha resposta é: lixo tecnológico. Durante a evolução tecnológica, surgem vertentes para todos os lados, mas muitas são desnecessárias e são continuadas e/ou defendidas, porque os envolvidos com estas vertentes não querem admitir que escolheram o caminho errado e já investiram muitos recursos com o aprendizado e aplicação delas. No fim, são tecnologias defendidas com interesses secundários que não a melhor qualidade da aplicação. Acho importante ressaltar que eu já trabalhei com estas tecnologias muito e por muitos anos.

webapp-api, session-api, data-module

Acho mesmo que preciso separar estes tópicos em outros posts.

Existem tantas coisas novas no mundo do desenvolvimento de software, mas a verdade que muitos desprezam é que existem coisas que não precisam ser melhoradas. Assim como no mundo real, existem coisas que não precisam ser melhoradas. Não disse que não podem ser melhoradas, disse que não precisam.

Existe uma infinidade de sub tópicos a serem tratados em cada um destes módulos, se eu for levantar aqui não terminarei este artigo.

Como sempre, comentários são bem vindos.