在我最近的工作中，我遵循了 REST 服务器 + JavaScript 重客户端的原则。
REST 服务器使用 node.js + Express + MongoDB（非常好的写作性能）+ Mongoose ODM（适用于建模数据，包括验证）+ CoffeeScript（现在我会选择 ES2015），对我来说效果很好。相对于其他可能的服务器端技术，Node.js 可能还比较年轻，但它使我能够编写集成付款的稳定 API。
我使用 Ember.js 作为 JavaScript 框架，大部分应用程序逻辑在浏览器中执行。我使用 SASS（具体而言是 SCSS）进行 CSS 预处理。
Ember是一个成熟的框架，由强大的社区支持。它是一个非常强大的框架，最近着重于性能方面的工作，比如
全新的Glimmer渲染引擎（受到React的启发）。
Ember核心团队正在开发
FastBoot，它可以让您在服务器端（具体来说是node.js）执行JavaScript Ember逻辑，并将应用程序的预渲染HTML（通常在浏览器中运行）发送给用户。这非常有利于SEO和用户体验，因为用户不需要等待太长时间才能显示页面。
Ember CLI 是一个很棒的工具，可以帮助您组织代码，并且随着代码库的增长而良好地扩展。Ember也拥有自己的插件生态系统，您可以从多种
Ember插件 中进行选择。您可以轻松地获取Bootstrap（在我的情况下）或Foundation，并将其添加到您的应用程序中。
为了不通过Express服务所有内容，我选择使用nginx来提供图片和JavaScript-heavy客户端。在我的情况下，使用nginx代理非常有帮助：
upstream app_appName.com {
# replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
server 0.0.0.0:1000;
keepalive 8;
}
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
client_max_body_size 32M;
access_log /var/log/nginx/appName.access.log;
error_log /var/log/nginx/appName.error.log;
server_name appName.com appName;
location / {
# frontend assets path
root /var/www/html;
index index.html;
# to handle Ember routing
try_files $uri $uri/ /index.html?/$request_uri;
}
location /i/ {
alias /var/i/img/;
}
location /api/v1/ {
proxy_pass http:
proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
优点：我喜欢API和客户端的分离。聪明人说这是正确的方法。在理论上非常好。看起来很前沿和令人兴奋。
我可以说，在实践中也非常好。将REST API分离的另一个优点是，您以后可以将其重用于其他应用程序。在完美的世界中，您应该能够不仅为网页使用相同的REST API，而且如果您决定编写移动应用程序，还应该能够使用它。
缺点：先例不多。没有多少成功的例子。公共示例（twitter.com）感觉迟钝，甚至正在转向其他方法。
现在情况看起来不同了。有许多示例使用REST API + 许多客户端来消费它。
