从历史上看，我们工程团队的代码已经被分割成浏览器层（使用HTML ， CSS和JavaScript ）和应用层（使用Java ） 。试想一下，一个HTML的开发人员要求一个Java开发人员将“A”和“B”页面连接在一起，但是这就是我们。该模型通过引入全栈工程师,落后那些能够创造一个好的用户界面，然后生成应用程序去支持它。称他们为独角兽，但是这就是我们想要的，在PayPal中，主要阻滞剂是我们在浏览器和服务器之间建立的人工边界。

Node.js 使用javascript，通过建立浏览器和服务端的应用程序帮助我们解决了这个问题。它统一了我们团队，让我们在技术堆栈上了解和应对我们用户的任何需求。

早期使用Node.js

和其他一样，我们把Node.js 作为一个原型的平台。同其他一样，它表现了很好的性能，我们决定在产品上使用它。
最开始的时候，我们使用express作为路由，nconf来作为配置，grunt来建立工作流。我们特别喜欢express框架的普及，却发现它并没有在多个开发团队很好地扩展。express是非强制性的，并允许您在任何方式合适地去设置一个服务器。它非常灵活，但不利于在大型团队中保持一致。随着时间的推移，我们看到的模式脱颖而出，更多的人拿起node.js的转身进入Kraken.js ，它不是一个框架本身，而是基于express的一个层，允许它扩展到更大的组织。我们希望我们的工程师专注于打造自己的应用程序，而不是仅仅着眼于建立自己的环境。
到现在为止，我们在内部使用kraken.js 已经有几个月了（不久，我们将会开源），我们的工程师团队期望将它变成一个实时的公司内部的node.js应用程序。

促使Node.js 到产品上

我们首先在产品上尝试node.js不是一个小的应用程序，它是我们的账目总览页面，这个页面具有很大的流量。我们打算去使用，但是我们也得降低风险，

于是我们同时建立了一个java应用程序。我们知道如何去部署和度量java应用程序，因此如果在node.js 程序出了任何问题，我们能够迅速的切换到java上来。它提供对一些数据的设置。

部署

我们在1月份就开始了，它花费了我们几个月的时间去研究node.js必要的基础东西。比如sessions, centralized logging, keystores。在这段时间内我们有5名工程师在使用java工作。在2个月的java开发后，2名工程师开始使用node.js 并行开发 app。在7月初的时候，他们相互沟通了一下，他们的应用程序具有相同功能。node.js的应用程序，是以一个更小的团队在2个月后开始，但是很快就追上了。有几个细节脱颖而出后，我们运行测试案例，两个应用程序通过相同的功能测试。node.js 是：

1）更少的人去建立，几乎是2倍甚至更快的速度
2）少了33% 的代码
3）建立40%甚至更少的文件

这个提供了一个令人鼓舞的消息表明javascript可以更快的工作。我们都同意并且做了一个决定：将java应用程序搁置了。但是问题是java工程师在项目上，开始的时候对转向node.js并且很高兴的在我们的工作流中提交代码，提高我们双倍的生产力不太自信。

性能

性能是一个高兴而有争议性的话题，在我们的案例中，我们一个团队有2套功能相同的应用程序：一个使用java 基于Spring而另一个基于kraken.js 使用 express, dust.js 和其他的开源代码。这个应用程序包含了3套路由，并且每一套路由2个或者5个请求，数据是通过Dust去渲染页面的。