BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

PayPal muda de Java para JavaScript

por Abel Avram , traduzido por Tulius Lima em 26 Dez 2013 |

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."

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

O.O by Eder Jorge

poutz

Concorrência by Raul Leite

Creio que implementarão somente em páginas onde há mais leitura no banco de dados (assim como fizeram com "a página de visão geral da conta"), do que escrita. Não me parece ser uma boa, usar Node.js em locais onde há concorrência entre threads.

Re: Concorrência by Cleiton França

Concordo com você Raul, onde há concorrência de threads node é um saco, vai ser preciso muitos callbacks e vários estratagemas para não perder informações cruciais das operações, ou, nessa áreas eles continuaram com java, ficando como um modulo independente, ou ainda, vão realizar as operações financeiras, por chamadas rest OS CONTROLLERS em node e por trás java servindo, de qualquer forma, node deve servir apenas os resultados. Ou não....

pro vs contra by Daniel Della Savia

Quanto custa recrutar e manter uma equipe especialista em javascript? E em java? E a curva de desenvolvimento? Qual o tempo gasto? Há vantagens, mas também há desvantagens.

Somente UI foi refeita! by Daniel Della Savia

Faltou ressaltar que foi somente a parte de interface de usuário que foi refeita (acessos, extratos de pagamentos, etc). Quero ver fazerem o core, transações, segurança, etc... em javascript também!

Maturidade by Alexandre Janoni

Creio que existem vantagens de se usar o javascript e Node.js, porém acho que as ainda pode apresentar problemas e dificuldades que o Java já superou. Na minha visão o melhor cenário é um mix entre as tecnologias.

Re: Somente UI foi refeita! by Carlos ABS

Java fanboy detected!

Re: Somente UI foi refeita! by Rafael Machado

Eu trabalho com Javascript e estive em um evento no Paypal onde conversei com os devs de lá e eles mesmo me disseram que não substituiram todo o backend por NodeJS e sim só a parte de interface mesmo, o core continuará sendo Java por um bom tempo brother.

cada qual no seu devido lugar by Leonardo Cidral

nada pode ser absolutamente bom para tudo, o bacana é saber tirar o maior proveito de cada tecnologia onde ela melhor desempenha...

Re: Somente UI foi refeita! by Márcio Rosa

O novo site do walmart.com é feito dessa forma!

Re: pro vs contra by Everaldo Lima

Eu nem sabia que estavam pagando para alguêm programar em .js
nodejs vai dominar o mundo...

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

11 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT