Real-Time com XMLHttpRequest

cookiemonster_xmlhttprequest

O XMLHttpRequest ou XHR, mudou tudo. Graças a essa API, o client-side pode transferir dados via Javascript. Ele inseriu o “D” na frente do HTML e nos permitiu obter assincronismo em nossas aplicações web. Antes dele, uma página precisava ser recarregada para enviar ou receber dados do servidor. Apesar de estar presente nos browsers desde o Internet Explorer 5, o XHR ainda é essencial para desenvolvermos aplicações web ricas e pode também ser usado – apesar de existir, hoje, tecnologias como websocket - para aplicações de tempo real.

XHR nos fornece uma maneira eficiente de sincronizar atualizações entre cliente e servidor. Quando necessário, uma requisição XHR envia dados para o servidor. O problema é o inverso.

Notificações em tempo real

O HTTP não fornece nenhuma maneira de o servidor iniciar uma nova conexão com o cliente. Para receber notificações, o cliente deve fazer polling, ou seja, fazer requisições periódicas ao servidor para pegar atualizações. Uma outra forma seria utilizar streaming, mas o suporte a streaming do XHR é limitado.

Dependendo da aplicação, podemos conviver com um delay de segundos, por exemplo. Mas algumas aplicações podem ter um overhead na casa dos milisegundos. A melhor forma de transportar dados irá depender.

Polling é muito simples de implementar. Piece of cake. Mas é frequentemente ineficiente. O intervalo de tempo de cada requisição é crítico. Imagine seu navegador fazendo requisições periódicas em frações de segundo para o servidor. Agora imagine milhões de navegadores fazendo a mesma coisa. Um cenário de terror pra qualquer sysadmin. Vamos olhar a função abaixo:


function checkUpdates(url){
  var xhr = new XMLHttpRequest();
  xhr.open('GET', url);
  xhr.onload = function(){ /* processa atualizações vindas do servidor */ };
  xhr.send();
}

setInterval(checkUpdates('/updates'), 2000);

Nesse exemplo, ocorre a checagem por atualizações a cada 2 segundos.

Cada requisição é comumente chamada de ajax. Ele nada mais é que uma requisição HTTP padrão. Muitas dessas requisições serão desnecessárias, pois não virão atualizações na resposta. Dependendo do caso, essas requisições desnecessárias podem ter um custo alto. Podem sobrecarregar a rede e o servidor, além de acabar com a bateria de dispositivos móveis. Uma requisição HTTP 1.x tem aproximadamente 800 bytes sem cookies. Imagine milhares de clientes trafegando 800 bytes a cada 2 segundos. E agora? Websocket? Ainda não. E se existisse uma maneira de eliminar essas requisições desnecessárias? Pior que existe ó.

Long-Polling

Long-polling, a.k.a COMET, a.k.a HTTP push, a.k.a Ajax reverso. Esta técnica nos permite manter a mesma conexão até que a atualização esteja disponível.

HTTP poll vs Long-polling

HTTP poll vs Long-polling

A conexão fica aberta até a atualização estar disponível. Uma vez que a resposta é entregue ao cliente, a conexão é fechada e outra requisição long-polling é enviada ao servidor, aguardando a próxima mensagem.


function checkUpdates(url){
  var xhr = new XMLHttpRequest();
  xhr.open('GET', url);
  xhr.onload = function(){
    ...
    checkUpdates('/updates');
  };

  xhr.send();
}

checkUpdates('/updates');

Pode testar. A bagaça realmente funciona. Mas e aí? Long-polling é sempre eficiente? Não. Só será eficiente quando o intervalo de tempo de atualizações no servidor for mais ou menos constante. Caso contrário, pode gerar mais requisições ao servidor do que o polling com setInterval.

Em alguns casos, long-polling resolve. A primeira versão do chat do facebook utilizava essa técnica. No entanto, hoje existem formas mais eficientes como websocket e server-sent events. Mais eficientes e bem mais trabalhosos.

Até a próxima.

Utilizando Material Design em Android

Material Design

Fala, galera da Comunidade! Neste post, irei mostrar um pouco sobre como desenvolver uma UI em Android, já aplicando o novo conceito de design da Google: Material Design. Se você é iniciante e gostaria de saber como começar a desenvolver para Android, leia o post Iniciando com Android: Introdução ao Android Studio que está bem legal!

Material Design: O Design Unificado da Google

Antigamente, existiam várias “caras” para os produtos da Google, inclusive para tipos de dispositivos diferentes, como web, tablets e smartphones. Ficava complicado manter uma mesma experiencia de usuário, pois cada produto tinha a sua maneira de design. Com o tempo, a Google percebeu isso e reuniu todos designers para que de certa forma pudesse contornar esse problema.

Continuar lendo

O #tasafoemacao voltou!!

tasafo_em_acao_chuck_norris1

O campeão voltou! Em Abril, teremos um Tá Safo em Ação no auditório da FIEPA. Neste encontro teremos palestras com temas diversos, entre gestão, mobile e web, com palestrantes com grande experiência em suas respectivas áreas:

  • Como aumentar a produtividade e a qualidade através da convenção REST em aplicativos web ou mobile com Felipe Iketani
  • SOA – Princípios de Arquiteturas Orientadas a Serviços com Cássio Noronha
  • Elaboração de um Product Backlog Efetivo com Fábio Aguiar
  •  Android Wear: estendendo sua app para relógios inteligentes com Bryan Ollivie e Ramon Rabello

O evento irá ocorrer no dia 08 de Abril, com início às 19:00 horas.

O auditório da FIEPA fica na FIEPA, lógico, na Travessa Quintino Bocaiúva 1588.

Página do evento: http://palestrascoletivas.com.br/events/ta-safo-em-acao-2015

 

Até lá!

A importância da Programação Orientada a Objetos – Parte I

Atualmente, é comum pessoas terem ideias inovadoras. Porém, esses insights não servem para nada se eles permanecerem somente no campo cerebral. Para começar a ver o valor de determinada percepção intelectual é necessário criar o produto que permita concretizar a ideia. Com a evolução dos computadores ao redor do mundo e a franca expansão destas máquinas, um dos caminhos para “materializar” a ideia é desenvolver software.

O algoritmo – uma sequência de passos finitos com o objetivo de solucionar um problema para desenvolver software – não é único e também não é trivial. É necessário entender de diversos conceitos que permeiam o estudo da computação. Dentre eles, destacam-se: Análise de Requisitos, Diagramas UML, Programação Orientada a Objetos (POO), Padrões de Projeto (Design Patterns), Design de Interface do Usuário (UI) e Experiência do Usuário (UX); e Testes Automatizados. Além disso tudo, é preciso realizar leitura de muito material (maioria em inglês) e atualizar-se quase que permanentemente.

Nesta primeira parte sobre a importância de POO, iremos falar exclusivamente dos principais conceitos deste paradigma de programação. Continuar lendo

O que desenvolvedores back-end deveriam aprender sobre front-end

Há alguns anos a ideia que se tinha de desenvolvedores front-end, era daqueles caras descolados que sabiam recortar um layout em alguma ferramenta de edição de imagens, aplicar em folhas de estilos utilizando tableless (não comentarei sobre a era das tables), construir formulários elegantes, arredondar bordas e algumas animações/transições em javascript. Além de tentar fazer tudo isso funcionar na maior quantidade de versões de navegadores e sistemas operacionais diferentes. Aliás, o próprio termo “desenvolvedor front-end” é recente, antes eram chamados bizarramente de “webdesigners”. O fato é: as skills desse cara aumentaram à medida que as tecnologias de front-end evoluíram.

É claro que ainda há diferentes competências quando se fala em desenvolvimento front-end, um lado mais voltado à arte, define cores, tipografia, fontes, imagens, espaçamento, etc. O outro, mais próximo de você – desenvolvedor back-end codeiro, mete a mão no código, geralmente javascript, para construir plug-ins, controllers, serviços, diretivas, testes e muitas outras coisas que todo desenvolvedor back-end faz no seu dia-a-dia. E é nesse ponto que eu queria chegar, nas tecnologias de front-end que desenvolvedores back-end deveriam, no mínimo, saber que existem. Note, não vou esmiuçar cada uma delas, apenas comentar sobre sua importância para o mundo. Vamos lá.

Continuar lendo