Evolução da Web: do CGI aos Websockets (e como isso ajudará você a monitorar melhor sua infraestrutura em nuvem)

Nos últimos anos, websockets tornaram-se mais ou menos um componente padrão em todas as aplicações web modernas, mas por que isso acontece e como chegamos aqui? Mais importante ainda, como os websockets podem ajudar você a monitorar sua infraestrutura de nuvem de forma mais eficaz?

Devido à natureza técnica deste tópico, é possível aprofundar-se muito nos detalhes. Mas tentarei manter as coisas em um nível relativamente alto e focar nos benefícios para os usuários da nossa infraestrutura de nuvem.

A maneira antiga de fazer as coisas

Nos primórdios da web, tudo era estático. Se você precisasse interagir com um servidor (além de renderizar uma página estática), teria que executar algum tipo de script CGI. Um exemplo típico disso era algo como a inscrição em uma lista de e-mails. Você inseria seu endereço de e-mail e pressionava ‘enviar’, e então via uma página separada que processava os dados. Isso, por sua vez, era um script que recebia a entrada e a processava no servidor.

Nos anos 90, as linguagens de script no lado do servidor evoluíram significativamente. A tecnologia evoluiu da execução de tarefas simples para a construção de páginas totalmente dinâmicas. Linguagens de programação como PHP, e tecnologias de servidor mais avançadas, como mod_perl, permitiram uma programação web muito mais sofisticada. Embora essas tecnologias fossem significativas, elas ainda evoluíam em torno do conceito de geração de página ao carregar. Uma vez carregada, era necessário recarregar a página inteira para atualizar o conteúdo.

À medida que a web evoluiu, entramos na AJAX/Web 2.0-era dos anos ’00, as páginas web tornaram-se muito mais dinâmicas e responsivas. Não era mais necessário recarregar a página para atualizar o conteúdo na tela. Tudo o que você precisava fazer era disparar algumas ações de JavaScript. Muitas páginas AJAX ainda eram alimentadas por PHP, mas com a introdução do JavaScript no lado do cliente, puderam se tornar mais dinâmicas.

Introdução ao AJAX

Com a introdução do AJAX, tornou-se cada vez mais importante a comunicação contínua entre o servidor e o cliente. De repente, você podia ter uma quantidade significativa de chamadas de API geradas por um único usuário em uma determinada página. Fazemos isso de forma ‘pull’, o que significa que o cliente solicitava atualizações do servidor em um determinado intervalo (ou com base em alguma ação).

Ao entrarmos nos anos ’10, era comum que as páginas web fossem completamente divididas entre o front-end (HTML/JavaScript/CSS) e o back-end (Ruby on Rails, Django etc.), que geralmente eram hospedados em servidores diferentes. A forma como o front-end se comunicava com o back-end era por meio de uma API. O front-end era mais ou menos estático. Com essa tendência, fazer chamadas de API para o servidor tornou-se um gargalo significativo. Se você precisasse buscar dez coisas diferentes no servidor, isso geralmente significava que precisava fazer dez chamadas de API diferentes, com cada chamada carregando uma sobrecarga e latência significativas.

A maneira moderna

Para resolver esse problema de latência e sobrecarga, os websockets foram introduzidos como parte do HTML5 e implementados em todos os navegadores modernos. Ao contrário da abordagem tradicional de ‘pull’ (ou seja, o cliente solicitando alterações ao servidor), um websocket é, como o nome indica, um socket, onde o servidor pode enviar (‘push’) alterações para o cliente. Portanto, se não houver alterações, não há necessidade de comunicação. Além disso, como o cliente pode se comunicar diretamente com o servidor sem a sobrecarga adicional de abrir e fechar conexões, a aplicação se torna muito mais responsiva.

É exatamente assim que a nossa própria web application é construída. A aplicação real é uma página estática que abre uma conexão websocket com a API. Uma vez que este socket está aberto, a aplicação web pode receber notificações do servidor com as alterações. Ainda enviamos comandos para a API RESTful, mas enviamos as notificações do servidor para o cliente usando o websocket.

Não apenas para páginas web

Embora o caso mais óbvio para receber atualizações usando um websocket seja através de um navegador, existem outros casos também. Talvez você esteja escrevendo uma ferramenta que monitora alterações na sua arquitetura e dispara ações com base nisso. Nesse caso, você pode acelerar significativamente sua aplicação utilizando nosso websocket.

Na nossa biblioteca Python, pycloudsigma, temos suporte integrado para websockets. Temos até um simples exemplo de como você pode utilizar isso para monitorar atividades de websocket com apenas algumas linhas de código. Aqui está uma demonstração rápida do monitor_websocket_activity.py monitorando as ações disparadas pela entrada do usuário no web-app.
Para mais informações sobre nossos serviços, confira nossos Recursos.