REST server + JavaScript-heavy client 是我最近工作中遵循的原则。
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 繁重的客户端。在我的情况下，使用 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://app_appName.com;
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;
}
}
Pro：我喜欢 API 和客户端的分离。聪明的人说这是要走的路。理论上很棒。看起来很前沿和令人兴奋。
我可以说它在实践中也很棒。分离 REST API 的另一个优点是您可以稍后将其重新用于其他应用程序。在完美的世界中，您应该能够将相同的 REST API 不仅用于网页，还可以用于移动应用程序（如果您决定编写一个）。
缺点：没有太多先例。这方面做得好的例子并不多。公共示例 (twitter.com) 感觉迟缓，甚至正在放弃这种方法。
现在情况看起来不同了。有很多做 REST API 的例子 + 许多客户使用它。