JavaScript Remoto by Novatec Editora

Ben Vinegar Anton Kovalyov

Novatec

Original English language edition published by Manning Publications Co., Sound View CT.#3B, Greenwich, CT 06830 USA. Copyright © 2013 by Manning Publications. Portuguese-language edition for Brazil copyright © 2013 by Novatec Editora. All rights reserved. Edição original em inglês publicada pela Manning Publications Co., Sound View CT.#3B, Greenwich, CT 06830 USA. Copyright © 2013 pela Manning Publications. Edição em português para o Brasil copyright © 2013 pela Novatec Editora. Todos os direitos reservados. © Novatec Editora Ltda. 2013. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora. Editor: Rubens Prates Tradução: Marcos José Pinto Revisão técnica: Aurelio Jargas Revisão gramatical: Marta Almeida de Sá Editoração eletrônica: Carolina Kuwabata ISBN: 978-85-7522-372-7 Histórico de impressões: Agosto/2013

Primeira edição

Novatec Editora Ltda. Rua Luís Antônio dos Santos 110 02460-000 – São Paulo, SP – Brasil Tel.: +55 11 2959-6529 Fax: +55 11 2950-8869 E-mail: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec MP20130801

capítulo 1

Introdução ao JavaScript remoto

Conteúdo deste capítulo • O que é JavaScript remoto • Exemplos práticos de aplicativos remotos • Como implementar um widget incorporado simples • Como identificar os desafios do desenvolvimento independente O JavaScript independente é um padrão da programação JavaScript que permite a criação de aplicativos web altamente distribuíveis. Ao contrário das aplicações web convencionais, que são acessadas em um único endereço da web (http://seuaplicativo.com), esses aplicativos podem ser carregados de forma arbitrária em qualquer página, por meio de inclusões simples no JavaScript. Provavelmente você já encontrou algum JavaScript remoto. Por exemplo, scripts de publicidade, que geram e apresentam publicidade direcionada em websites de conteúdo. Os scripts de publicidade podem não ser um grande sucesso entre os usuários, mas ajudam a gerar receita e a manter os negócios de quem publica conteúdo na web. Estão visíveis em milhões de websites e, ainda assim, quase todos eles são scripts remotos, servidos a partir de servidores de publicidade separados. Os scripts de publicidade são apenas um exemplo de utilização; os desenvolvedores recorrem a scripts remotos para resolver diversos tipos de problema. Alguns os utilizam para criar produtos independentes que atendam às necessidades de quem gera conteúdo. Por exemplo, a Disqus, uma nova empresa da web, de San Francisco, Estados Unidos, onde trabalharam os bons autores deste livro, desenvolve um aplicativo remoto de comentários que proporciona aos autores de conteúdo um sistema 23

JavaScript Remoto

instantâneo de comentários. Outras empresas desenvolvem scripts remotos para ampliar seus aplicativos web tradicionais a fim de alcançar o público de outros websites. Por exemplo, o Facebook e o Twitter desenvolveram dezenas de widgets sociais que são carregados em websites de autores de conteúdo. Esses widgets ajudam as redes sociais no engajamento de seus usuários fora do ecossistema normal de seus aplicativos. Pequenas empresas também podem se beneficiar de JavaScript remoto. Vamos supor que você seja o proprietário de um aplicativo para web B2B (business-to-business, ou negócios entre empresas) que hospede formulários web para coletar informações dos clientes do seu cliente. E que seus possíveis clientes queiram muito usar seu aplicativo, mas não se sintam seguros em redirecionar seus próprios clientes a um website externo. Com JavaScript remoto você pode fazer com que seu aplicativo de formulário seja carregado diretamente nas páginas de seus clientes, resolvendo o problema do medo do redirecionamento. Nem tudo é fácil com JavaScript remoto. Desenvolver esses aplicativos está longe de ser algo trivial. Há inúmeras armadilhas e problemas de segurança que você terá de resolver antes de publicar um script remoto que se manterá inteiro em campo aberto. Felizmente este livro lhe mostrará como ser bem-sucedido, descrevendo todo o desenvolvimento de um aplicativo remoto completo. Contudo, antes de mergulharmos no âmago do JavaScript remoto, você deverá aprender o básico. Neste capítulo, vamos definir melhor o que vem a ser JavaScript remoto, analisar implementações reais de diversas empresas, analisar uma implementação simples de um aplicativo remoto e discutir os muitos desafios envolvidos no desenvolvimento de sistemas remotos. Vamos começar tentando entender melhor o que vem a ser JavaScript remoto e o que é possível criar.

1.1 Definição de JavaScript remoto Em uma troca normal de informações entre programas, há dois lados. Há o consumidor, ou a primeira parte, que estará operando o software. A segunda parte é o provedor ou o autor desse software.

Capítulo 1 ■ Introdução ao JavaScript remoto

Na web, você pode considerar como primeira parte o usuário que está operando um navegador web. Quando o usuário visita uma página na web, o navegador faz uma solicitação a um provedor de conteúdo. Esse provedor, a segunda parte, transmite o HTML da página da web, suas imagens, folhas de estilo e seus scripts, de seus servidores para o navegador web do usuário. Em uma troca particularmente simples como essa, pode haver somente duas partes. Mas hoje em dia a maioria dos provedores de websites também apresenta conteúdo de outras fontes, ou seja, de uma terceira parte. Como ilustrado na figura 1.1, a terceira parte, ou parte remota, pode fornecer diversos itens, desde conteúdo de artigos (Associated Press), hospedagem de avatares (Gravatar) até vídeos incorporados (YouTube). No sentido mais restrito, qualquer coisa apresentada a um cliente, que seja fornecida por uma organização diferente do provedor do website, é considerada como uma terceira parte, ou remota.

Figura 1.1 – Os websites atuais empregam um grande número de serviços remotos.

Ao tentar aplicar essa definição ao JavaScript, as ideias caem no limbo. Muitos desenvolvedores têm opiniões divergentes sobre o que exatamente constitui um JavaScript remoto. Alguns classificam como sendo qualquer código JavaScript que não tenha sido criado pelos autores do website.

JavaScript Remoto

Isso poderia incluir bibliotecas populares como jQuery e Backbone.js. Poderia também incluir qualquer código que você copiasse e colasse de um website de soluções de programação, como o Stack Overflow. Todo e qualquer código que você não tenha criado se enquadrará nessa definição. Outros se referem ao JavaScript remoto como código que esteja sendo servido a partir de servidores de terceiros, que não estejam sob o controle do provedor de conteúdo. O argumento é que o código servido por um provedor de conteúdo está sob seu controle: ele escolhe quando e onde o código será servido, ele tem a possibilidade de modificá-lo e é, em última instância, responsável por seu funcionamento. Isso é diferente do código fornecido por servidores de terceiros, cujo conteúdo não pode ser modificado pelo provedor e que pode até mesmo ser modificado sem aviso prévio. A relação a seguir apresenta uma página HTML de um provedor de conteúdo que carrega arquivos JavaScript locais e hospedados em servidor remoto.

Listagem 1.1 – Exemplo de página web de provedor de conteúdo que carrega um script local e um externo <!DOCTYPE html> <html> <head>

<title>Example Content Provider Website</title>

</body> </html> ❶ Arquivos

JavaScript locais hospedados nos servidores do próprio provedor de conteúdo.

❷ Arquivo

JavaScript carregado de um servidor externo (remoto).

Capítulo 1 ■ Introdução ao JavaScript remoto

Não há uma resposta correta; há argumentos para ambas as interpretações. No entanto, para os objetivos deste livro, estamos particularmente interessados na segunda definição. Quando nos referirmos a JavaScript remoto, estaremos nos referindo a código que • não foi criado pelo provedor de conteúdo; • é fornecido por servidores externos e que não são controlados pelo provedor de conteúdo; • foi escrito com a ideia de que será executado como parte do website do provedor de conteúdo.

ONDE ESTÁ O TYPE=”TEXT/JAVASCRIPT”? Você deve ter notado que as declarações com a tag <script> deste exemplo não especificam o atributo type. Para uma tag <script> sem tipo, o comportamento padrão do navegador será tratar o conteúdo como JavaScript, até mesmo nos navegadores mais antigos. Para manter os exemplos deste livro o mais resumido possível, tiramos o atributo de tipo da maioria deles. Até agora analisamos scripts remotos a partir do ponto de vista do provedor de conteúdo. Vamos mudar a perspectiva. Como desenvolvedores de JavaScript remoto, criamos scripts os quais pretendemos executar no website de um provedor de conteúdo. Para inserir nosso código no website do provedor de conteúdo, damos a ele trechos de código HTML que deverão ser inseridos em suas páginas, para que sejam carregados os arquivos JavaScript de nossos servidores (consulte a figura 1.2). Não estamos afiliados ao provedor de conteúdo, apenas carregamos scripts em suas páginas para fornecer bibliotecas úteis ou aplicativos independentes. Se você está confuso, não se preocupe. A maneira mais fácil de entender o que são scripts remotos é ver como funcionam na prática. Na próxima seção, vamos analisar alguns exemplos reais de scripts remotos disponíveis publicamente. Se você não souber o que são quando terminarmos, então nossa reputação como autores técnicos de terceira categoria terá sido assegurada. Vamos em frente!

JavaScript Remoto

Figura 1.2 – Um trecho de carregamento de script, aplicado na página do provedor de conteúdo, carrega código JavaScript remoto.

1.2 Os muitos empregos do JavaScript remoto Definimos que JavaScript remoto significa código que está sendo executado no website de outra pessoa. Isso dá ao código remoto o acesso aos elementos HTML e ao contexto de JavaScript do website. Assim você poderá manipular essa página de diversas formas, o que

Capítulo 1 ■ Introdução ao JavaScript remoto

pode incluir a criação de novos elementos no DOM (Document Object Model), inserindo folhas de estilo personalizadas e registrando eventos de navegador para capturar as ações do usuário. Na maioria dos casos, scripts remotos podem realizar quaisquer operações que você puder realizar com JavaScript no seu próprio website ou aplicativo, só que fazendo no website de outra pessoa. Armado com o poder de manipular remotamente a página web, vem a pergunta: para que serve isso? Nesta seção, vamos analisar alguns casos de uso de scripts remotos: • Widgets incorporados – pequenos aplicativos interativos incorporados na página web do provedor de conteúdo. • Análises e métricas de tráfego – para reunir informações sobre visitantes e como eles interagem com o website do provedor de conteúdo. • Wrappers de API de web services – para desenvolver aplicativos de clientes que se comunicam com web services externos. Esta não é uma lista completa, mas deve ser suficiente para dar uma ideia clara do que os JavaScripts remotos são capazes. Vamos começar por uma análise profunda do primeiro item: widgets incorporados.

1.2.1 Widgets incorporados Os widgets incorporados (ou widgets remotos) são talvez o exemplo de uso mais comum de scripts remotos. Normalmente são pequenos aplicativos interativos, apresentados e disponibilizados no website do provedor de conteúdo, mas carregam e enviam recursos de e para um conjunto separado de servidores. Os widgets podem variar bastante em complexidade, podem ser simples como uma imagem que informa a previsão do tempo em sua área geográfica ou tão complexos quanto um cliente completo de mensagens instantâneas. Os widgets permitem que os criadores de websites incorporem, com pouco esforço, aplicativos em suas páginas web. Normalmente são de fácil instalação; na maioria dos casos, tudo o que o provedor de conteúdo deve fazer é inserir um pequeno trecho de código HTML no código-fonte da página para iniciar. Como são inteiramente baseados em JavaScript, os widgets

JavaScript Remoto

não exigem que o criador do website instale e mantenha qualquer software que seja executado em seus servidores, o que significa menos manutenção. Há empresas sendo criadas para trabalhar exclusivamente no desenvolvimento e na distribuição de widgets incorporados. Há pouco mencionamos o Disqus, uma nova empresa da web sediada em San Francisco. A Disqus desenvolve um widget de comentários (Figura 1.3) que funciona como uma seção de comentários inserida em blogs, publicações online e outros websites. Seu produto funciona quase inteiramente com base em JavaScript remoto. Ele usa JavaScript para buscar os dados dos comentários no servidor, apresentar os comentários como HTML na página e capturar dados de formulário de outras pessoas que inserirem comentários. Em outras palavras, para tudo. É instalado nos websites por meio de um trecho simples de HTML, com um total de cinco linhas de código.

Figura 1.3 – Um exemplo de seção de comentários em um website de conteúdo, movido pelo widgets de comentários do Disqus.

O Disqus é um exemplo de produto que só é útil em sua forma distribuível; é preciso visitar a página de um provedor de conteúdo para utilizá-lo. Mas nem sempre os widgets são produtos independentes como este. Muitas vezes, são versões “portáteis” de aplicativos web fixos maiores e mais tradicionais.

Capítulo 1 ■ Introdução ao JavaScript remoto

Por exemplo, considere o Google Maps, possivelmente o aplicativo de mapas mais conhecido. Os usuários navegam até http://maps.google.com para ter acesso a mapas interativos de locais em todo o mundo. O Google Maps também fornece instruções de percurso por carro e transporte público, imagens de satélite e até mesmo visualizações no nível da rua por meio de fotografias obtidas nos próprios locais. Incrivelmente, toda essa mágica também vem na forma de widget. Os provedores de conteúdo podem incorporar o aplicativo de mapas em suas próprias páginas web usando alguns trechos simples de JavaScript, obtidos no website do Google Maps. Além disso, o Google oferece um conjunto de funções públicas para que os criadores de conteúdo possam modificar o conteúdo dos mapas. Vamos ver como é simples incorporar um mapa interativo em sua página web, utilizando o Google Maps (Listagem 1.2). Este exemplo de código começa apontando a biblioteca JavaScript do Maps, por meio de uma inclusão simples de script. Assim, quando o handler onload for disparado, será feita a verificação para checar se o navegador é compatível; se for, será iniciado um novo mapa, centralizado nas coordenadas indicadas1. E está pronto, e tudo isso com aproximadamente dez linhas de código – muito poderoso!

Listagem 1.2 – Inicialização do widget do Google Maps <!DOCTYPE html> <html> <head>

<title>Google Maps Example</title>

JavaScript Remoto

mapTypeId: google.maps.MapTypeId.ROADMAP };

map = new google.maps.Map(document.getElementById('map_canvas'), mapOptions);

} </script> </head>

</body> </html>

Acabamos de ver dois exemplos de widgets incorporados. Porém na verdade qualquer ideia de aplicativo é válida para a incorporação em uma página de conteúdo. Em nossas próprias viagens, já vimos uma grande variedade de widgets: gerenciadores de conteúdo, widgets de apresentação de vídeos, widgets que permitem bate-papo em tempo real com uma pessoa do atendimento ao cliente, e assim por diante. Se você puder sonhar com um widget, será possível incorporá-lo.

1.2.2 Análise e métrica de tráfego Os JavaScript remotos não são usados exclusivamente na criação de widgets incorporados. Há outras aplicações que não envolvem, necessariamente, elementos gráficos e interativos na página web. Muitas vezes são scripts silenciosos que processam informações na página do criador de conteúdo, sem que o usuário jamais saiba que existem. Os casos mais comuns desse tipo de script estão na área de análise e métrica de tráfego. Um dos recursos mais poderosos do JavaScript é permitir que os desenvolvedores capturem e respondam a eventos gerados pelo usuário, quando ocorrem sobre uma página web. Por exemplo, é possível criar um código em JavaScript que responda aos movimentos e cliques do mouse do visitante de um website. Os scripts remotos não são exceção: eles também podem observar eventos do navegador e capturar dados, tais como o tempo de permanência de um visitante em uma página, qual conteúdo ele visualizou e para onde vai em seguida. Há dezenas de eventos de navegadores em que o seu código JavaScript é capaz de se ligar, a partir do qual podem-se derivar centenas de ideias diferentes.

Capítulo 1 ■ Introdução ao JavaScript remoto

Scripts passivos A Crazy Egg, outra nova empresa da web, é um exemplo de organização que utiliza scripts remotos dessa forma. Seu produto de análise gera visualizações da atividade do usuário em sua página da web (Figura 1.4). Para obter tais informações, a Crazy Egg fornece um script aos provedores de conteúdo, capaz de capturar os eventos de mouse e de rolamento dos visitantes da página da web. Essas informações são enviadas de volta aos servidores da Crazy Egg, tudo no mesmo script. As visualizações geradas pela Crazy Egg ajudam os provedores de conteúdo na identificação das partes de seus websites que estão sendo acessadas com mais frequência e quais estão sendo ignoradas. Os provedores de conteúdo utilizam essas informações para melhorar o design das páginas e otimizar o conteúdo.

Figura 1.4 – O mapa de áreas quentes da Crazy Egg destaca as áreas de maior tráfego dos websites de conteúdo.

O script remoto da Crazy Egg é considerado um script passivo; ele grava dados estatísticos sem qualquer interação de quem publica o conteúdo. O provedor de conteúdo é responsável somente pela inclusão do script na página. O restante ocorre automaticamente.

Scripts ativos Nem todos os scripts de análise funcionam de maneira passiva. A Mixpanel é uma empresa de análise de tráfego cujo produto rastreia ações do usuário definidas pelo provedor de conteúdo, para gerar dados estatísticos

JavaScript Remoto

sobre os visitantes de websites ou usuários de aplicativos. Em vez de estatísticas genéricas da web, como visualizações ou visitantes de páginas, a Mixpanel faz com que os provedores de conteúdo definam os eventos mais importantes do aplicativo que desejam acompanhar. Alguns exemplos desses eventos podem ser “o usuário clicou no botão de inscrição”, ou “o usuário assistiu a um vídeo”. Os criadores de conteúdo escrevem trechos simples de código JavaScript (Listagem 1.3) para identificar quando a ação ocorre e, em seguida, chamam um método de rastreamento fornecido pelos scripts remotos da Mixpanel para registrar o evento com seu serviço. A Mixpanel então monta esses dados em uma estatística de afunilamento interessante para ajudar a responder perguntas como “que sequência de passos os usuários seguem antes de fazer a atualização de um produto?”.

Listagem 1.3 – Rastreamento do cadastro de usuários com a API JavaScript da Mixpanel <button id="signup">Sign up!</button> <script src="http://api.mixpanel.com/site_media/js/api/mixpanel.js"> </script> <script> var mpmetrics = new MixpanelLib(PUBLISHER_API_TOKEN); ❶ jQuery(function() { ❷

jQuery('#signup').click(function() {

mpmetrics.track("signup button clicked");

}); ❸ }); </script> ❶ Inicia

a biblioteca da Mixpanel.

❷ Anexa

um handler do evento de clique ao botão de inscrição por meio de jQuery.

❸

Envia a ocorrência do evento por meio de uma função da biblioteca Mixpanel.

Ao contrário do serviço da Crazy Egg, o serviço da Mixpanel exige algum trabalho de desenvolvimento no lado do provedor de conteúdo para definir e disparar os eventos. A vantagem é que o provedor de conteúdo pode coletar dados de forma personalizada, cercando as ações do usuário e respondendo perguntas sobre a atividade do usuário.

Capítulo 1 ■ Introdução ao JavaScript remoto

Há outra coisa interessante relacionada ao uso dos scripts remotos pela Mixpanel. Atualmente a Mixpanel fornece um conjunto de funções no lado do cliente que se comunicam com sua API de web services – um conjunto de pontos de entrada (endpoints) HTTP que fazem o rastreamento e informam sobre os eventos. Este é um exemplo prático de uso que pode ser ampliado e transformado em uma grande variedade de serviços diferentes. Vamos aprender mais sobre isso.

1.2.3 Wrappers de API de web services Caso você não esteja familiarizado, as APIs de web services são pontas de entrada (endpoints) de servidores HTTP que habilitam o acesso programático a um web service. Ao contrário de aplicativos de servidores que retornam HTML para ser consumido por um navegador web, esses pontos de entrada aceitam e respondem com dados estruturados, normalmente nos formatos JSON ou XML, que serão consumidos por um programa de computador. Esse programa pode ser um aplicativo de desktop ou um aplicativo sendo executado em um servidor da web ou, ainda, um código JavaScript cliente hospedado em uma página web, porém sendo executado no navegador de um usuário. Estamos mais interessados no último caso de uso, código JavaScript executado no navegador. Os provedores de APIs de web services podem oferecer aos desenvolvedores que se utilizam dessa plataforma, geralmente chamados de integradores, scripts remotos que simplificam o acesso, no lado do cliente, a suas APIs. Gostamos de chamar esses scripts de wrappers de API de web services, já que são efetivamente bibliotecas JavaScript que “envolvem” (wrap) os recursos de uma API de web service.

Exemplo: A API de grafos (Graph) do Facebook Por que isso é útil? Vamos analisar um exemplo. Suponha que exista uma desenvolvedora independente de web chamada Jill que esteja cansada do trabalho como freelancer e esteja procurando um emprego com carteira assinada. Jill resolveu que, para se tornar mais atraente para seus possíveis empregadores, ela precisa ter um currículo online com aparência fantástica, hospedado em seu website. Esse currículo será, em

JavaScript Remoto

grande parte, estático, relacionando suas habilidades e sua experiência de trabalho anterior, e mencionará até mesmo seu gosto por navegar de caiaque sob a luz do luar. Jill decidiu que, para demonstrar suas habilidades no desenvolvimento para web, deverá haver também um elemento dinâmico em seu currículo. E ela tem uma ideia perfeita. E se os visitantes do currículo online de Jill, possíveis empregadores, pudessem ver se têm amigos ou conhecidos em comum com Jill (Figura 1.5)? Isso não somente seria uma demonstração inteligente das habilidades de Jill, como também ter um amigo em comum poderia ser uma ótima maneira de dar a ela uma boa vantagem.

Figura 1.5 – Na parte inferior do currículo de Jill, o visitante pode ver os amigos em comum.

Para implementar seu currículo dinâmico, Jill utiliza a API de grafos do Facebook. Trata-se de uma API de web service do Facebook que permite que aplicativos da web tenham acesso ou modifiquem dados do usuário no Facebook (com a sua permissão, é claro). O Facebook também conta com uma biblioteca JavaScript que fornece funções de comunicação com a API. Utilizando essa biblioteca, Jill poderá escrever um código cliente capaz de localizar e apresentar amigos em comum entre ela e um visitante do seu currículo. A figura 1.6 ilustra a sequência de eventos que ocorrem entre o navegador e os dois servidores. A listagem 1.4 apresenta o código para implementar esse recurso no currículo. Para simplificar, este exemplo usa jQuery, uma biblioteca em JavaScript, para simplificar as operações DOM. Para saber mais, acesse http://jquery.com.

Capítulo 1 ■ Introdução ao JavaScript remoto

Figura 1.6 – Incorporação de conteúdo do Facebook em um website com JavaScript no cliente.

Listagem 1.4 – Utilização da API de grafos do Facebook para buscar e apresentar uma lista de amigos em comum <!DOCTYPE html> <html>

JavaScript Remoto

<a href="#" id="show-connections">Show mutual friends</a>

</ul>

FB.init({ appId: 'FACEBOOK_APP_ID' }); ❷

$('#show-connections').click(function() { FB.login(function(response) { ❸ var userID; var url; if (response.authResponse) { ❹ userID = response.authResponse.userID;

url = '/' + userID + '/mutualfriends/jill?fields=name,picture';

FB.api(url, showMutualFriends); } }); });

function showMutualFriends(response) { ❺

var out = '';

var friends = response.data;

friends.forEach(function (friend) { out += '<li>';

out += '<img src="' + friend.picture + '"/>';

out += friend.name + '</li>';

}); $('#mutual-friends').html(out); } </script> </html> ❶ Carrega ❷

o jQuery e o SDK de JavaScript do Facebook.

Inicia o SDK de JavaScript do Facebook. Antes será preciso registrar seu aplicativo em http://developers.facebook.com e obter um ID de aplicativo.

Capítulo 1 ■ Introdução ao JavaScript remoto ❸

FB.login abre uma nova janela do Facebook solicitando ao visitante do website que faça login e dê ao aplicativo a permissão para acessar os dados do visitante.

❹ Se

o login for bem-sucedido, solicita os amigos em comum no Facebook por meio do ponto de entrada /mutualfriends/ da API de Grafos. Quando a resposta estiver pronta, executa a função de retorno showMutualFriends.

❺ Percorre

a lista de amigos e os apresenta na página.

Jill conseguiu incorporar alguns recursos poderosos em seu currículo, tudo isso utilizando um pequeno código JavaScript no lado do cliente. Com esse trabalho impressionante, ela não deverá ter dificuldades para conseguir um ótimo emprego na área de software.

Benefícios do acesso à API no lado do cliente Vale a pena ressaltar que todo esse exemplo poderia ter sido feito sem qualquer JavaScript no cliente. Em vez disso, Jill poderia ter escrito um aplicativo de servidor para consultar os dados da API de grafos do Facebook e, em seguida, apresentar o resultado como HTML na resposta ao navegador. Nesse caso, o navegador baixaria o HTML do servidor de Jill e apresentaria o resultado ao usuário, sem executar qualquer código JavaScript. No entanto é provavelmente melhor deixar que o visitante do website execute essa tarefa no navegador, por algumas razões: • Código executado no navegador é código que não será executado nos servidores do integrador, o que pode levar à economia de largura de banda e processamento. • É mais rápido, pois a implementação em servidor terá que aguardar pela resposta da API do Facebook para poder apresentar qualquer conteúdo. • Alguns websites são totalmente estáticos, então o JavaScript no cliente será a única maneira de ter acesso a uma API de web service.

JavaScript Remoto

UMA API PARA CADA CASO O exemplo que acabamos de descrever pode ser considerado um caso de uso de nicho, mas é apenas uma aplicação possível. O Facebook é apenas um provedor de API de web service, mas a verdade é que há milhares de APIs bem conhecidas, todas elas oferecendo acesso a diversos tipos de dados e recursos. Além de aplicativos de redes sociais como Facebook, Twitter e LinkedIn, há plataformas de publicação como Blogger e WordPress, ou aplicativos de pesquisa como Google e Bing, todos oferecendo graus variados de acesso a seus dados por meio de APIs. Muitos web services, pequenos ou grandes, oferecem APIs. Porém nem todos chegaram ao requinte de oferecer uma biblioteca JavaScript para acesso a partir do cliente. Isso é importante porque o JavaScript no navegador é a maior plataforma de desenvolvimento: é suportada em todos os websites, em todos os navegadores. Se você ou sua empresa desenvolve ou mantém uma API de web service, e deseja ter acesso ao maior número possível de integradores, você deve realmente oferecer aos desenvolvedores um wrapper de API no lado do cliente, assunto que vamos descrever com detalhes mais adiante, neste livro.

1.3 Desenvolvimento de um widget básico Analisamos algumas utilizações populares de JavaScript remoto. Você viu como pode ser usado no desenvolvimento de widgets, na coleta de dados para análise de tráfego e como wrapper no cliente para acesso a APIs de web services. Possivelmente tudo isso lhe deu uma ideia do que será possível quando você for projetar seu próprio aplicativo remoto. Agora que você viu alguns exemplos reais, chegou a hora de você desenvolver alguma coisa. Vamos começar com algo bastante simples: um widget básico incorporado. Por um momento, faça de conta que você gerencia um website que fornece informações climáticas atualizadas a cada minuto. Normalmente, os usuários visitam diretamente o seu site para obter as últimas notícias sobre a previsão do tempo. Contudo, para atingir um público mais abrangente,

Capítulo 1 ■ Introdução ao JavaScript remoto

você resolveu dar um passo à frente e oferecer aos usuários o acesso a seus dados fora do seu website. Você fará isso por meio de uma versão do seu serviço em widget incorporado, como ilustrado na figura 1.7.

Figura 1.7 – Como o widget do tempo aparecerá na página de conteúdo.

Você divulgará esse widget entre os provedores de conteúdo interessados em oferecer a seus leitores informações locais sobre o tempo, com a fácil instalação de um script remoto. Felizmente, você já encontrou um provedor de conteúdo interessado, que resolveu fazer um test-drive com seu widget. Para que possam começar, você deverá oferecer um trecho de código HTML que carregará o widget de previsão do tempo em suas páginas. O interessado vai copiar e colar o trecho de código no código-fonte HTML, no local em que desejar que o widget seja apresentado. O widget propriamente dito é bastante simples: é uma tag <script> apontando para um arquivo JavaScript remoto hospedado em seus servidores no weathernearby.com: <script src="http://weathernearby.com/widget.js?zip=94105"> </script>

Observe que a URL desse elemento de script contém um único parâmetro, zip. É assim que você identificará o local para o qual deverá enviar as informações climáticas. Agora, quando o navegador carregar a página do provedor de conteúdo, encontrará essa tag <script> e solicitará o arquivo widget.js dos seus servidores em weathernearby.com. Quando o widget.js for baixado e executado, apresentará o widget do tempo diretamente na página de conteúdo. Esse é o objetivo, pelo menos.

JavaScript Remoto

Para fazer isso, o widget deverá ter acesso aos dados climáticos da empresa. Esses dados poderiam ser publicados diretamente dentro do arquivo de script, mas, tendo em vista que há aproximadamente 43 mil códigos de endereçamento nos Estados Unidos, trata-se de uma quantidade excessiva de dados para servir em uma única solicitação. A menos que o usuário esteja acessando da Suécia ou da Coreia do Sul, onde conexões de 100 Mbps são normais, é claro que o widget vai precisar fazer solicitações separadamente para obter os dados do tempo. Isso se consegue, normalmente, por meio de AJAX, mas, para manter a simplicidade, vamos usar um método diferente: geração de script em servidor.

1.3.1 Geração de JavaScript em servidor Em vez de servir um arquivo JavaScript estático que contém o código do seu widget, você criará um aplicativo de servidor que vai gerar um arquivo JavaScript para cada solicitação (Figura 1.8). Como o seu servidor tem acesso ao banco de dados climáticos, poderá injetar os dados climáticos solicitados no arquivo JavaScript gerado. Isso significa que o arquivo JavaScript conterá todo o código e todas as informações necessárias para apresentar o widget do tempo na página de conteúdo, sem ter de fazer quaisquer solicitações adicionais. Esse aplicativo de servidor poderia ser escrito em qualquer linguagem de programação ou em qualquer plataforma capaz de executar em ambiente de servidor, como Ruby, PHP, Java, ASP.NET e até mesmo JavaScript de servidor. São todas boas opções, mas vamos descrever um exemplo criado em Python, uma linguagem de script bastante conhecida. Este exemplo utiliza também o Flask, um microframework em Python para a construção de pequenos aplicativos para a web. Se você não estiver familiarizado com Python, não se preocupe, pois o código é fácil de entender. Se você quiser testar o código da listagem 1.5 por conta própria, consulte o código-fonte que acompanha o livro, que também contém instruções de instalação do Python (2.x) e do Flask.

Capítulo 1 ■ Introdução ao JavaScript remoto

Figura 1.8 – Um aplicativo de servidor gerando dinamicamente o código do widget Weather Nearby (widget.js).

POR QUE PYTHON? Os poucos e pequenos exemplos de servidor apresentados neste livro foram escritos em Python. A razão para termos escolhido essa linguagem de programação é completamente tendenciosa: é o que usamos diariamente na Disqus e estamos muito familiarizados com ela. Se você não souber programar em Python, tudo bem. Este é essencialmente um livro sobre JavaScript, e os exemplos de servidor poderiam ser reescritos em qualquer linguagem.

Listagem 1.5 – Implementação em servidor do widget.js, escrito em Python e Flask – server.py # server.py from flask import Flask, make_response, request ❶ from myapp import get_weather_data app = Flask(__name__) ❷ @app.route('/widget.js') ❸ def weather_widget():

JavaScript Remoto

zip = request.args.get('zip') ❹

data = get_weather_data(zip)

out = ''' ❺

document.write( '<div>' +

<p>%s</p>' +

<img src="%s"/> ' +

<p><strong>%s &deg;F</strong> &mdash; %s</p>' +

'</div>' );

''' % (data['location'], data['image'], data['temp'], data['desc'])

response = make_response(out)

response.headers['Content-Type'] = 'application/javascript' ❻

return response ❶

Um aplicativo Flask completo. Começa pela importação de algumas bibliotecas auxiliares, inclusive a Flask, e tem uma função utilitária para consultar o banco de dados da previsão do tempo.

❷ Inicia

o aplicativo Flask.

❸ Define

uma rota única: '/widget.js'. Quando o servidor for iniciado, o Flask ouvirá todas as solicitações a '/widget.js' e responderá executando essa função.

❹ Extrai

o parâmetro zip da query string da solicitação e consulta o banco de dados de previsão do tempo para obter os dados correspondentes.

❺

Monta uma string multilinhas de código JavaScript que apresentará o conteúdo do widget na página do provedor de conteúdo. Usará a função document.write do JavaScript, que escreverá uma string de texto (neste caso, em HTML) diretamente na página.

❻ Cria

um objeto de resposta HTTP para retornar a string ao navegador. Define o header Content-Type da resposta como application/ javascript, de modo que seja interpretado pelo navegador como código JavaScript.

Quando esse ponto de entrada do servidor estiver em execução, uma solicitação <script> a http://weathernearby.com/widget.js?zip=94105 deverá retornar

Capítulo 1 ■ Introdução ao JavaScript remoto

o código JavaScript apresentado abaixo. Este código apresentará o widget que você viu no início dessa seção (Figura 1.7). Observe também que o fato de esse código estar sendo servido a partir de um aplicativo Python é completamente transparente para o navegador que estiver fazendo a solicitação. document.write(

'<div>' +

' <p>San Francisco, CA</p>' +

' <img src="http://weathernearby.com/img/partly-cloudy.png"/>' +

' <p><strong>87 &deg;F</strong> &mdash; Partly Cloudy</p>' +

'</div>' );

Agora, quando dissemos anteriormente que esse seria um widget básico, não estávamos brincando. Esse código produz um widget de tempo completamente sem estilo que não oferece absolutamente qualquer interação com o usuário. É horrível e provavelmente colocou sua empresa de previsões climáticas em maus lençóis. Porém funciona e ilustra a interação entre websites de provedores de conteúdo e código remoto. Algumas das técnicas ilustradas aqui, como o uso de document.write e Python em servidor, não são as únicas maneiras de se gerarem widgets. E, por motivos que explicaremos mais tarde, são até mal vistas. Em capítulos futuros vamos explorar soluções alternativas e melhores e abordar recursos mais complexos, como folhas de estilo, comunicação com servidores via AJAX e sessões de usuário.

1.3.2 Distribuição de widgets como iframes Se você já tem bastante experiência com desenvolvimento para a web, deve estar pensando: “não seria mais fácil distribuir esses widgets como um iframe?”. À primeira vista pode parecer que sim, mas há diferenças não tão óbvias que fazem dos scripts remotos a melhor opção de implementação. Para entender o porquê, primeiro vamos ver como recriar o widget do exemplo anterior utilizando iframes. Caso você não saiba o que é isso, iframes são elementos de bloco do HTML cuja função é incorporar conteúdo externo servido a partir de

JavaScript Remoto

um URL. Você poderia recriar facilmente o exemplo do widget do tempo utilizando apenas um elemento iframe, desta maneira: <iframe style="border:none;height:200;width:150" src="http://weathernearby.com/widget.html?zip=94105"/>

Repare que o atributo src mudou, não está mais apontando um arquivo JavaScript; em vez disso, está buscando um documento HTML. Neste caso, o ponto de entrada do servidor retornará um documento HTML completo, contendo o código de marcação do widget, eliminando completamente a necessidade do JavaScript. Repare também que as dimensões do widget são definidas como parte do atributo style do iframe. Os elementos do iframe não se ajustam ao tamanho do conteúdo e é preciso definir dimensões explícitas. A utilização de um iframe como esse deve produzir os mesmos resultados do exemplo com JavaScript. Então, por que usar JavaScript no lugar de iframes, até mesmo para um exemplo tão simples quanto esse? Há diversas razões, a maioria delas é relacionada a um atributo específico dos iframes: esse conteúdo externo carregado dentro de um iframe não pode ser acessado pela página pai (a página de conteúdo) e vice-versa. • Flexibilidade – Se algum dia você quiser alterar as dimensões do widget, terá problemas. Como as dimensões do iframe são fixas no elemento iframe da página de conteúdo, e esses atributos não podem ser modificados a partir do conteúdo carregado no iframe, não há como redimensionar o widget dinamicamente. • Estética – A aparência e o funcionamento do widget terão de ser completamente independentes dos estilos da página pai. O widget não poderá herdar estilos básicos, como a família, o tipo e a cor da fonte. • Interação – O widget precisará ler ou modificar o DOM do provedor de conteúdo? E se esse provedor precisar interagir com o conteúdo do widget? Múltiplas instâncias do widget poderão interagir entre si? Nada disso é possível com iframes estáticos. • Informação – O usuário viu mesmo o widget? Quanto tempo passou na página até vê-lo? Para obter este e outros tipos de informações estatísticas é preciso ter JavaScript sendo executado na página de conteúdo.

Capítulo 1 ■ Introdução ao JavaScript remoto

Esses são apenas alguns poucos exemplos, mas você provavelmente já está percebendo a tendência. Os iframes podem ser o mecanismo mais simples para distribuir o exemplo do widget do tempo, mas ao fazer isso você perderá muitos dos recursos atraentes oferecidos pela adoção do JavaScript remoto. Contudo, não deixe que isso influencie negativamente sua opinião sobre os iframes. Eles são um recurso valioso na caixa de ferramentas do desenvolvedor de JavaScript remoto e vamos usá-lo com bastante frequência em diversas tarefas apresentadas neste livro.

1.4 Desafios do desenvolvimento de sistemas remotos Você viu como a utilização do JavaScript remoto é uma maneira poderosa de criar aplicativos altamente distribuíveis. Escrever scripts que serão executados nos websites de outras pessoas envolve um conjunto único de desafios, diferentes da programação comum com JavaScript. Descrevendo de maneira mais específica, seu código será executado em um ambiente DOM sobre o qual você não terá controle, em um outro domínio. Isso significa que você terá de lidar com uma grande quantidade de problemas complexos e inesperados, como um contexto de página desconhecido, um ambiente JavaScript compartilhado com outros scripts locais e remotos e até mesmo restrições impostas pelo navegador. Vamos analisar rapidamente o que cada um desses problemas envolve.

1.4.1 Contexto desconhecido Quando um provedor de conteúdo inclui seu script remoto em sua página web, muitas vezes você sabe pouco sobre o contexto em que o script está sendo inserido. Seu script poderá ser inserido em páginas dos mais variados tipos de documento (doctype), layouts de DOM e regras de CSS, e deverá funcionar bem em todos eles. É preciso considerar que um provedor de conteúdo pode inserir seu script no início da página, na tag <head>, ou pode inseri-lo no fim da tag <body>. Os provedores de conteúdo podem carregar seu aplicativo dentro de um iframe ou em uma página em que a tag <head> esteja ausente; no HTML5, as seções HEAD são opcionais e nem todos os navegadores geram internamente essa seção de forma automática. Se o seu script for baseado

JavaScript Remoto

em suposições sobre esses elementos básicos ao consultar ou anexar ao DOM, poderá acabar tendo problemas. Se você desenvolver um widget incorporado, a apresentação dos estilos corretos também será uma preocupação. Seu widget será aplicado sobre uma página com cor de fundo clara ou escura? Você quer que seu widget herde estilos e combine bem com o design da página de conteúdo ou prefere que seu widget seja apresentado de maneira idêntica em todos os contextos? O que acontecerá se o HTML da página de conteúdo contiver erros de formatação, fazendo com que a página seja apresentada de maneira alternativa (quirks mode)? A solução desses problemas exige mais do que CSS bem escrito. Vamos analisar soluções para essas questões nos próximos capítulos.

1.4.2 Ambiente compartilhado Para cada ambiente da web há somente um namespace de variáveis globais, compartilhado por todos os códigos que estiverem sendo executados na página. Você não somente deve ter o cuidado de não poluir o namespace com suas próprias variáveis globais, como também deve reconhecer que outros scripts, possivelmente outros aplicativos remotos como o seu, têm a capacidade de modificar objetos e protótipos padrão dos quais você poderá depender. Tome como exemplo o objeto global JSON. Nos navegadores modernos, trata-se de um objeto nativo capaz de processar e converter (stringify) JSON (JavaScript Object Notation) com velocidade impressionante. Infelizmente, pode ser facilmente modificado por qualquer pessoa. Se o seu aplicativo depender do funcionamento correto desse objeto, e esse objeto for alterado de uma maneira incompatível por outro trecho de código, seu aplicativo poderá produzir resultados incorretos ou simplesmente não funcionar. O exemplo de código abaixo demonstra a facilidade com que se pode modificar o objeto global JSON, por meio de uma simples atribuição de variável: JSON.stringify = function() { };

/* implementação personalizada de stringify */

Capítulo 1 ■ Introdução ao JavaScript remoto

Você pode estar se perguntando “por que alguém faria isso?”. Normalmente os desenvolvedores web carregam seus próprios métodos JSON de modo a obter compatibilidade com navegadores antigos que não oferecem métodos de forma nativa. A má notícia é que algumas dessas bibliotecas são incompatíveis de maneiras sutis. Por exemplo, as versões mais antigas da famosa biblioteca Prototype oferecem métodos JSON que produzem resultados diferentes dos métodos nativos, ao trabalharem com valores indefinidos: // Prototype.js JSON.stringify([1, 2, undefined]) => "[1, 2]" // Nativo JSON.stringify([1, 2, undefined]) => "[1, 2, null]"

O objeto JSON é apenas um exemplo de um objeto nativo de navegador que pode ser alterado por um código concorrente no cliente; há centenas de outros. Ao longo do material deste livro, vamos analisar soluções para restaurar ou simplesmente evitar esses objetos. Da mesma forma, o DOM é outro namespace global de aplicativo com que você deverá se preocupar. Existe somente uma árvore de DOM para uma página que é compartilhada com todos os aplicativos que estiverem sendo executados na página. Isso significa que é necessário ter cuidado especial ao interagir com ela. Quaisquer novos elementos que você inserir no DOM terão que coexistir em paz com os elementos já existentes e não deverão interferir com outros scripts que estiverem consultando o DOM. Da mesma maneira, suas consultas ao DOM poderão, inadvertidamente, selecionar elementos que não lhe pertencem se não for definida corretamente a abrangência da consulta. O contrário também é válido; outros aplicativos podem consultar seus elementos acidentalmente, caso você não tenha tido o cuidado de escolher IDs e nomes de classes exclusivos. Como seu código se encontrará no mesmo ambiente de execução de outros scripts, a segurança também será algo crítico. Você não somente deve proteger seu aplicativo do uso impróprio por outras pessoas, como também deve considerar os outros scripts que estiverem sendo executados na página e até mesmo o provedor de conteúdo como possíveis ameaças.

JavaScript Remoto

Por exemplo, se você criar um widget ou script que se ligará a um serviço maior e popular, como o website de uma rede social, os provedores de conteúdo poderão querer tentar simular interações de usuário com suas próprias páginas.

1.4.3 Restrições de navegadores Se contextos desconhecidos de documentos, namespaces globais múltiplos e problemas adicionais de segurança já são suficientemente ruins, ainda há o fato de que os navegadores proíbem ativamente certas ações que, muitas vezes, afetam diretamente os scripts remotos. Por exemplo, o AJAX tornou-se uma ferramenta básica dos desenvolvedores web para buscar e enviar dados sem a necessidade de atualizar a página. No entanto a política de mesma origem dos navegadores impede que o XmlHttpRequest trabalhe com domínios que não sejam aquele em que você se encontra (Figura 1.9). Se você criar um script remoto que precisar obter de ou enviar dados para um aplicativo que estiver sendo executado no seu próprio domínio, você terá de encontrar outras maneiras de fazer isso. Da mesma forma, normalmente os navegadores aplicam restrições sobre a possibilidade de os aplicativos definirem ou mesmo lerem cookies de terceiros. Sem eles, seus usuários não poderão “fazer login” no seu aplicativo ou memorizar ações de solicitações anteriores. Dependendo da complexidade do seu aplicativo, não poder definir ou ler cookies de terceiros poderá ser um grande problema.

Figura 1.9 – Solicitação AJAX entre domínios do localhost ao google.com no Google Chrome.

Infelizmente, essa lista de desafios é apenas a ponta do iceberg. O desenvolvimento de JavaScript remoto está lotado de armadilhas porque, afinal, o navegador web não foi projetado com aplicativos incorporados e código remoto em mente. Os navegadores estão melhorando e estão sendo introduzidos novos recursos que reduzem um pouco da carga do

Capítulo 1 ■ Introdução ao JavaScript remoto

desenvolvimento de scripts remotos, porém ainda é uma batalha difícil, e a criação de compatibilidade com navegadores antigos é obrigatória em qualquer tipo de aplicativo distribuído. Mas não se preocupe. Você já tomou a decisão certa ao comprar este livro, que aborda os problemas enfrentados pelo seu código JavaScript remoto. Como um bônus adicional, vamos até mesmo lhe dizer como resolvê-los.

1.5 Resumo O desenvolvimento de JavaScript remoto é uma maneira poderosa de criar aplicativos incorporados e altamente distribuíveis para a web. Esses aplicativos podem apresentar as mais variadas formas e diversos tamanhos, mas analisamos três casos específicos de utilização: como widgets interativos, como scripts passivos que coletam dados e como bibliotecas de desenvolvedor que se comunicam com APIs remotas na web. Entretanto, se considerarmos o desenvolvimento normal de aplicativos locais, os scripts remotos enfrentam desafios adicionais. Eles exigem que você execute seu código em ambientes de navegador desconhecidos, compartilhados e possivelmente hostis. Vimos apenas uma pequena parte do que significa desenvolver scripts remotos. No próximo capítulo, vamos começar pela criação completa de um widget incorporado. Este é um dos casos de utilização mais comuns de JavaScript remoto e serve como um excelente ponto de partida para aprender sobre os conceitos e desafios de sistemas remotos.