Entendendo Aplicações Web Realtime

Sem mágicas, sem complicações: WebSockets, Polling e Long Polling


PS.: Esse artigo já existia, mas foi traduzido para o português. Sim, cansei de escrever em inglês… por enquanto.

O que é realtime?

Bom, vamos começar pelo começo, certo? Quanto tempo você acha que a imagem de um belo quadro leva até chegar ao seu cérebro, para que ele possa processar a imagem e, obter a brilhante presunção, de que aquilo é um quadro? É óbvio que você não pára pra pensar nisso toda vez que enxerga alguma coisa, mas vamos tentar fazer esse exercício agora:

Feche os olhos, conte até 10 e os abra. O que você vê? Quanto tempo demorou até que você percebesse o que estava vendo? Foi "instantâneo", não é mesmo? Foi verdadeiramente realtime!! #sóquenão :(

Nosso cérebro está atrasado em relação ao verdadeiro realtime em 80 milissegundos, ou ms (que é como vou chamar os milissegundos daqui por diante no post). Já parou pra pensar nisso? Tudo o que vemos, já aconteceu e nós estamos sempre presenciando o passado.

Realtime é fake! :O

Nada vivo, morto ou construído (nesse planeta, pelo menos) executa uma ação ou reação absolutamente instantânea. Tudo tem um tempo para acontecer, mesmo que isso dure milimicronano segundos (obviamente inventei essa medida… xD).

O toque, a visão, a audição, etc. Tudo leva um tempo para acontecer e raramente notamos isso. As vezes lembramos disso com fogos de artifício, trovões, etc. Aí você se pergunta:

Mas cara, se você tá me dizendo que não existe realtime, o que é esse realtime que a galera tanto fala?

O que é realtime, afinal?

O realtime de que tanto falam é apenas uma sensação. Temos a (errônea) impressão de que foi instantâneo, mas nem foi cara… Só pareceu que foi, é sério. =/ Mas isso não é tão ruim quanto parece, pois, ao invés de trabalhar para fazer as coisas serem instantâneas, nós temos agora que trabalhar duro para fazer as coisas parecerem instantâneas. Temos que dar a melhor sensação de realtime para quem estiver no fim da linha do nosso trabalho.

Isso é mais fácil do que você imagina, nós já fazemos isso no WhatsApp, por exemplo e até no bom e velho telefone mesmo, quando estamos tentando passar alguma informação que estamos presenciando no nosso lado da linha. Então se você estiver pensando em desenvolver uma aplicação realtime, se prepare pra entender como funciona a comunicação e como ela te ajuda a proporcionar uma experiência com a melhor sensação de realtime possível.

A leitura vai ficar um pouco mais técnica a partir daqui, ok?

Realtime na web

Sempre que falamos sobre desenvolver uma aplicação realtime, que pode ser um chat, notificações push ou qualquer coisa que você imagine, nós estamos falando de entregar informação da maneira mais rápida e eficiente possível para nossos clientes.

Para desenvolver tais aplicações, precisamos escolher técnicas e ferramentas, e dentre muitas opções atuais do mercado, eu escolhi falar mais especificamente sobre duas: WebSockets e Long Polling.

Websockets

Para entender o que é, precisamos primeiro ver (ou rever) alguns conceitos básicos da comunicação. Uma comunicação duplex só pode ser realizada entre um transmissor e um receptor. Além disso, eles precisam criar um protocolo para estabelecer e regularizar essa comunicação entre eles, e existem dois tipos de protocolos em um sistema duplex: Half-Duplex e Full-Duplex.

Mas cara! Pera aí! O que é duplex???

Duplex

Duplex é um sistema de comunicação que, para existir, precisa de pelo menos um transmissor e pelo menos um receptor. Nós usamos esse cara pra praticamente tudo relacionado a comunicação na nossa vida.

Explicado? Qualquer coisa joga no Google que você vai achar um monte de coisa mais específica, eu vou tentar pegar mais leve aqui, ok? Agora vamos aos protocolos de um sistema Duplex.

Half-Duplex

Também chamado de Semi-Duplex, esse protocolo permite que a informação da comunicação trafegue de forma unidirecional, ou seja, só pode existir um transmissor e um receptor por vez. Tem um velho e conhecido ditado que exemplifica isso muito bem: “Quando um burro fala, o outro abaixa a orelha”.

Full-Duplex

Esse protocolo fornece uma comunicação bidirecional entre o transmissor e o receptor. Isso significa que o transmissor e o receptor ficam trocando de papel um com o outro a todo momento. Imagine uma feira, o recreio de uma pré-escola e a praça de alimentação de um shopping. Todos esses lugares acontecendo junto, no mesmo tempo e ocupando o mesmo espaço. É isso.

Agora que a gente (re)lembrou os conceitos de uma comunicação, podemos definir WebSockets como uma comunicação Full-Duplex. Em outras palavras, podemos dizer que o WebSockets abre uma conexão entre o cliente e o servidor, tornando possível a troca bidirecional de informações.

O WebSockets é uma API do HTML5 e sua especificação ainda está em desenvolvimento pelo W3C, mas a maioria dos browsers modernos já oferecem suporte e você já pode encontrar centenas de aplicações, plugins e frameworks que usam essa tecnologia.

Se sua aplicação não precisa dar suporte para navegadores antigos, o WebSockets parece ser a sua melhor opção.

Mas se você precisa dar suporte a navegadores antigos, aí os problemas começam a ficar um pouco mais cabeludos para resolver. Para isso, você vai precisar desenvolver um sistema super inteligente de fallback, ou acreditar na mágica de fallback de frameworks de terceiros.

Mas cara… pera! Se eu não posso usar o WebSockets pra fazer meus apps, #comofaz?

Existe uma técnica pra isso, que não é uma API, é uma técnica mesmo, uma maneira de realizar que não depende de browser modernos nem nada disso. Você só vai precisar escolher ferramentas que possam ser utilizadas no servidor ou como um servidor que disponibilizem esse tipo de interação. Essa técnica se chama Polling.

Polling

O conceito por trás da técnica de Polling consiste em manter o cliente atualizado por meio de requisições periódicas ao servidor. Aqui na Mentis, nós tínhamos um produto que foi incialmente desenvolvido dessa maneira. Todas as notificações e chats dos usuários ficavam atualizando de x em x segundos, fazendo com que a experiência do usuário não fosse a das melhores. Mesmo se a gente fizesse com que esses x segundos se tornassem 1 segundo, ainda teríamos que somar esse segundo ao tempo de tráfego das informações na internet, condições de conexão e uma porção de outros fatores externos a nós que resultariam em um número de atraso nada interessante pro cliente final. Além do que, fazer chamadas de 1 em 1 segundo pro servidor iria onerar bastante a banda do usuário final, se ele estivesse em uam conexão 3G, poderia acabar com o tráfego dele.

E agora? Quem irá nos defender?

Euuu!!!! O Long Polling (Colorado)

Long Polling é uma extensão da técnica de Polling e ela funciona mais ou menos como pescar: você joga sua isca na água e decide ficar esperando por uns 3 minutos até puxar sua vara, venha peixe ou não. Mas se vier um peixe e morder sua isca em 3 segundos, você puxa sua vara imediatamente. No nosso caso, o peixe são as novas informações, a água é o servidor, o pescador é nossa aplicação e a vara é a requisição. Funciona MESMO dessa forma:

  1. A aplicação abre uma conexão com o servidor;
  2. O servidor recebe e segura essa conexão e a segura por x segundos;
  3. Passaram-se os x segundos e nada aconteceu? Devolve a conexão sem nada;
  4. Algo aconteceu nesses x segundos? Devolve o que aconteceu pra aplicação.

Simples, não é?

Conclusão

Acho que Long Polling é a melhor maneira de desenvolver aplicações realtime hoje. Apesar de que escolher um servidor que possa ser assíncrono e se comunicar com um banco que tenha certas inteligências possa ser uma tarefa árdua, ainda é menos penoso e fornece um aprendizado mais interessante do que simplesmente adicionar uma url de um framework de terceiros e cruzar os dedos pra ver se funciona.

Valeu, é isso aí! ;)