O PayPal decidiu usar JavaScript de ponta-a-ponta, do browser até o servidor de backend para aplicações web, descontinuando o código legado escrito em JSP/Java.
Jeff Harrell, diretor de engenharia do PayPal, explicou em alguns posts no seu blog (Set My UI Free Part 1: Dust JavaScript Templating, Open Source and More, Node.js at PayPal), o motivo por trás dessa decisão e algumas das conclusões que resultaram da mudança de seu desenvolvimento web de JSP/Java para uma solução totalmente JavaScript/Node.js.
Segundo Harrell, os sites do PayPal acumularam um grande número de dívidas técnicas, e a ideia era ter "uma pilha tecnológica livre delas de modo a possibilitar uma maior agilidade e inovação em seus produtos". Inicialmente, existia uma grande cisma entre os engenheiros de frontend, que trabalhavam com tecnologias web e os engenheiros de backend, que trabalhavam com Java. Quando alguém de UX queria desenhar algumas páginas, era necessário pedir para os desenvolvedores Java fazer configurações no backend. Isso não se encaixava com o modelo adotado de Lean UX:
Na época, nossas aplicações de interface de usuário eram baseadas em uma solução Java e JSP proprietária rígida, fortemente acoplada de difícil manutenção e aprendizado. Nossas equipes além de não considerarem essa situação aderente ao nosso modelo de desenvolvimento Lean UX, também não conseguiam mover-se rapidamente internamente de forma que passaram a construir seus protótipos em uma linguagem de script, testá-los com os usuários, e depois portar o código para a nossa pilha de produção.
Havia o desejo de uma "solução de template desacoplada da tecnologia utilizada no lado servidor e que permitisse a evolução das interfaces de usuário, independentemente da linguagem da aplicação", isso deveria funcionar em múltiplos ambientes.
A decisão foi utilizar o Dust.js - um framework apoiado pelo LinkedIn - somado ao Bootstrap do Twitter e Bower, um gerenciador web de pacotes. As partes adicionadas posteriormente foram LESS, RequireJS, Backbone.js, Grunt e Mocha.
Algumas das páginas do PayPal foram redesenhadas, mas ainda mantiveram um pouco da pilha legada:
… temos como legado códigos C++/XSL e Java/JSP, e não queríamos deixar essas interfaces de usuário para trás, à medida que seguíamos adiante. Templates JavaScript são ideais para isso. Sobre a pilha C++, construímos uma biblioteca que utilizou V8 para fazer uso de renderizadores Dust nativamente - o resultado em termos de velocidade foi excelente. No lado Java, integramos o Dust usando um Spring ViewResolver acoplado ao Rhine para renderizar a camada de visualização.
Naquela época, também passaram a utilizar o Node.js para prototipar novas páginas, concluindo que era "extremamente proficiente" e decidiram experimentar isso em produção. Para isso, construíram o Kraken.js, uma "camada" sobre o Express, que por sua vez é um framework web baseado em Node.js. (PayPal recentemente tornou o Kraken.js como código-aberto). A primeira aplicação a ser feita em Node.js foi a página de visão geral da conta, que era uma das páginas mais acessadas do PayPal, segundo Harrell. Mas graças ao temor de que o app não escalasse bem, decidiram criar uma aplicação Java equivalente como segurança para o caso da aplicação Node.js não funcionar. A seguir, estão algumas conclusões referentes ao esforço de desenvolvimento dispendido para ambas aplicações:
|
Java/Spring |
JavaScript/Node.js |
Configuração inicial |
0 |
2 meses |
Desenvolvimento |
aprox. 5 meses |
aprox. 3 meses |
Engenheiros |
5 |
2 |
Linhas de código |
não especificado |
66% não especificado |
A equipe JavaScript precisou de dois meses para a configuração inicial da infraestrutura, mas criou - com menos pessoas - uma aplicação com a mesma funcionalidade e em menos tempo. Executando a suíte de testes em hardware de produção, concluiu que o aplicativo Node.js estava com desempenho melhor que o anterior em Java, servindo:
o dobro de requisições por segundo em relação à aplicação Java. Isso é ainda mais interessante, devido aos nossos resultados inicias de performance estarem utilizando apenas um núcleo para a aplicação Node.js, contra cinco da aplicação Java. Temos expectativa que essa essa diferença possa ser ainda maior.
e resultando
um decréscimo de 35% no tempo médio de resposta para a mesma página. Isso resultou em páginas sendo servidas 200ms mais rápido - algo que os usuários certamente perceberão.
Como resultado, o PayPal começou a utilizar em produção a aplicação Node.js beta, tendo decidido que "daqui em diante todas as nossas aplicações web para o cliente serão feitas em Node.js," enquanto algumas das existentes estão sendo portadas para Node.js.
Um dos benefícios de utilizar JavaScript do browser até o servidor é, de acordo com Harrell, a eliminação da separação do desenvolvimento front e backend, por ter uma única equipe "que nos permite entender e reagir às necessidades dos nossos usuários em qualquer nível da pilha tecnológica."