A web está evoluindo. Depois de alguns anos de iteração, a especificação do WebSockets foi finalmente aprovada (RFC 6455) e no final de 2011 tanto o Chrome quanto o Firefox já eram compatíveis com o SPDY. Esses acréscimos são muito mais do que apenas a “evolução do AJAX”, uma vez que agora temos comunicação em tempo real de verdade no navegador: processamento de streaming, controle de fluxo, enquadramento e melhoria significativa no desempenho e na latência. Agora, só precisamos trazer a “espinha dorsal” que ficou para trás – nossos frontends web, servidores de aplicativos e tudo mais, para o século atual para que possamos tirar vantagem dessas novas capacidades.

Estamos otimizados para a “web de ontem”

A arquitetura backend moderna deve permitir que você termine a conexão o mais próximo possível do usuário, para minimizar a latência – é o seu balanceamento de carga ou servidor web ocupando as portas 80 e 443 (SSL). De lá, a requisição é roteada na rede interna, do frontend para o serviço no backend, que irá gerar a resposta. Infelizmente, o estado atual do roteamento de nossa “espinha dorsal” não está apenas desatualizado, mas muitas vezes é também o fator restritivo para nossa adoção a esses protocolos de tempo real.

WebSockets e SPDY são ambos protocolos multiplexados e otimizados para carregar múltiplas camadas de streaming de dados sobre o mesmo pipe TCP. Infelizmente, as escolhas populares, tais como Apache ou Nginx, possuem nenhum entendimento desse fato e, na melhor das hipóteses, degradam o fluxo para “proxies TCP” nada inteligentes. E pior, já que eles não entendem disso, multiplexação, controle de fluxo e manipulação de prioridade são igualmente “jogadas pela janela”. Tanto o WebSockets quanto o SPDY comunicam-se por mensagens formatadas (framed messages), em vez de fluxos TCP, que precisam ser parseados novamente a cada estágio.

Ponha tudo isso junto e você irá perceber rapidamente por que a espinha dorsal de seu próprio stack web, e mesmo de plataformas populares como a do Heroku ou Google App Engine, são incapazes de oferecer suporte para WebSockets ou SPDY: nossos serviços são apoiados por servidores e softwares que foram projetados para a web do passado.

Arquitetura para uma web de tempo real

O HTTP não irá desaparecer no curto prazo, e nós teremos que suportar tanto os velhos como os novos protocolos por um bom tempo. Uma tentativa nesse sentido foi o proxy SPDY > HTTP, que converte fluxos multiplexados em uma série de requisições HTTP à moda antiga. Funciona e permite que reutilizemos nossa velha infraestrutura, mas vai exatamente na contramão do que precisamos fazer!

Em vez de convertermos um fluxo multiplexado e otimizado em uma série de envios de HTTP interno, deveríamos exigir uma infraestrutura HTTP > SPDY que permitiria que andássemos para frente a avançássemos em relação às velhas arquiteturas. Em 2012, deveríamos ter exigido que a nossa infraestrutura interna oferecesse o seguinte:

• Streaming de resposta e de requisição deveriam ser padrão
• Conexões aos servidores de backend deveriam ser persistentes
• Comunicação com os servidores de backend deveria ser orientada a mensagens
• Comunicação entre backends e clientes deveria ser bidirecional

Torne o SPDY padrão e abrace topologias dinâmicas

O primeiro passo em direção a esses objetivos é reconhecer que traduzir SPDY para HTTP é um caminho conveniente para o curto prazo, mas é exatamente o caminho errado a se tomar no longo prazo. O SPDY oferece multiplexação, controle de fluxo, compressão otimizada e enquadramento. Devemos abraçar essas tecnologias e torná-las padrão em nosso backend. Uma vez que tivermos um protocolo orientado a mensagens e multiplexado em nosso backend, poderemos finalmente parar de parsear novamente o fluxo TCP em cada servidor. Escrever um parser HTTP hoje em dia não é uma solução interessante, muito menos divertida.

Finalmente, essa arquitetura não deve necessitar de um time exclusivo de operações, ou de uma plataforma de software específica, para ser mantido. Aplicativos web modernos raramente são processados em apenas um host e necessitam de administração e (re)configuração dinâmica. Serviços como Heroku, CloudFoundry e Google App Engine criaram suas próprias estruturas de roteamento para lidar com esses problemas. Em vez disso, precisamos projetar arquiteturas nas quais o frontend e o backend são separados por padrão e necessitam de manutenção e intervenção mínimas.

Adote uma camada de sessão moderna

Construir tipologias de redes dinâmicas não é para os “fracos de coração”, especialmente quando acrescentamos as necessidades específicas para a comunicação orientada a mensagens, fluxos multiplexados e toda sorte de questões relacionadas a restrições de desempenho. Felizmente, bibliotecas como ØMQ oferecem tudo isso é mais um pouco embrulhado em uma API simples e intuitiva. Permita que o frontend parseie e emita os frames SPDY, então roteie-os internamente como mensagens ØMQ para um número de inscritos qualquer.

O Mongrel2 foi um dos primeiros servidores web a explorar esse tipo de arquitetura com o ØMQ, o que permitiu a ele contornar todo o problema de configuração do backend, assim como permitir uma quantidade interessante de padrões de topologias de trabalho. Ainda há espaço para evolução, mas esse é um passo muito necessário na direção correta. Como um exemplo concreto, vamos considerar um fluxo de trabalho com o SPDY e o ØMQ como exemplo:

1. Uma requisição HTTP (ou SPDY) chega até o frontend
2. O frontend parseia a requisição e gera os frames SPDY SYN_STREAM, HEADERS e DATA
3. As mensagens são entregues a um socket ØMQ PUSH (através do Mongrel2)
4. Os inscritos no backend usam um socket PULL para processar o fluxo SPDY
5. Os inscritos no backend enviam o fluxo de resposta de volta para o frontend

A comunicação é feita por um canal persistente com semântica orientada a mensagens; o frontend e o backend são completamente isolados um do outro e nós podemos finalmente parar de ficar abrindo “TCP Holes” para que o TCP suporte aplicações web modernas.

HTTP 2.0

Os novos protocolos estão aí, mas a arquitetura de suporte necessita de uma severa atualização: o SSL está se tornando padrão, streaming não é mais uma opção e conexões persistentes por tempo prolongado chegaram para ficar. O SPDY está ganhando corpo e não tenho dúvidas de que num futuro não muito distante ele será um protocolo aprovado pela IETF (Internet Engineering Task Force). De forma semelhante, o ØMQ não é a única alternativa para roteamento interno, mas vem igualmente ganhando adeptos.

Parser veloz de HTTP e roteamento simplesmente não são o suficiente para dar suporte para as situações de uso da web de hoje. Da mesma forma, TCP hole punching  em nossa infraestrutura já não é uma solução viável a longo prazo – neste ano, devemos querer mais. Sim, eu estou me referindo a vocês: Varnish, Nginx, Apache e companhia limitada.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.igvita.com/2012/01/18/building-a-modern-web-stack-for-the-realtime-web/