对于atyourservice.com.cy，我们使用服务器端渲染的页面模板，特别是覆盖se部分。并在页面加载后使用API进行交互。 由于我们的框架是MVC，所有控制器函数都复制到json输出和html输出。模板是干净的，只接收一个对象。这可以在几秒钟内转换为js模板。我们总是维护服务器端模板，并在请求时重新转换为js。

我喜欢#3，当我的网站不是100%的CRUD实现我的数据。这种情况尚未发生。

我更喜欢sinatra，只会把应用程序分成几个不同的机架应用程序与不同的目的。我会做一个API特定的机架应用程序，将涵盖我需要的API。然后可能是一个用户机架应用程序，将呈现我的网页。有时该版本会在需要时查询API，但通常它只关心html站点。

我不担心它，只要从用户端做一个持久化层查询，如果我需要它。我不太关心创建一个完全的分离，因为他们通常最终服务于不同的目的。

下面是一个使用多个机架应用程序的简单示例。我在那里添加了一个jquery的快速示例，让你看到它击中API应用程序。你可以看到sinatra和安装多个不同用途的机架应用程序是多么简单。

https://github.com/dusty/multi-rack-app-app

我的3个月项目已经进行了2个月，采用了你在这里概述的第二种方法。我们使用一个RESTful API服务器端，前端是backbone.js。js管理模板，jQuery处理AJAX和DOM操作。对于旧的浏览器和搜索蜘蛛，我们已经退回到服务器端渲染，但是我们使用的是与使用Mozilla Rhino的Handlebars前端相同的HTML模板。

我们选择这种方法有很多不同的原因，但我们非常清楚，因为它还没有在大范围内得到证明，所以它有点冒险。尽管如此，到目前为止一切都进行得很顺利。。

到目前为止，我们一直在使用一个API，但在项目的下一个阶段，我们将使用第二个API。第一个用于大量数据，第二个更像一个通过API的CMS。

让项目的这两个部分彼此完全独立是选择这个基础设施的关键考虑因素。如果您正在寻找一种架构，可以在没有任何依赖的情况下混搭不同的独立资源，那么这种方法值得一试。

恐怕我不是Ruby的人，所以我不能评论其他方法。有时候冒险一下是可以的。其他时候最好谨慎行事。你会根据项目的类型来了解自己。

祝你选对了。也热衷于看别人分享什么。

在创建gauge .es时，我们选择了#2。我负责API (ruby, sinatra等)，我的业务伙伴Steve Smith负责前端(javascript客户端)。

优点:

Move quickly in parallel. If I worked ahead of Steve, I could keep creating APIs for new features. If he worked ahead of me, he could fake out the API very easily and build the UI. API for free. Having open access to the data in your app is quickly becoming a standard feature. If you start with an API from the ground up, you get this for free. Clean separation. It is better to think of your app as an API with clients. Sure, the first and most important client may be a web one, but it sets you up for easily creating other clients (iPhone, Android).

缺点:

向后兼容性。这与API的关系比你直接的问题更大，但一旦你的API出来了，你就不能破坏它，也不能破坏所有的客户端。这并不意味着你要放慢速度，但它确实意味着你必须经常同时做两件事。添加到API或新字段是可以的，但是在没有版本控制的情况下不应该进行更改/删除。

我现在想不出什么骗局了。

结论:如果你计划发布一个API, API + JS客户端是正确的选择。

另外，我还建议在发布API之前完整地记录它。编写gage .es API的过程确实帮助了我们进行imp操作

http://get.gaug.es/documentation/api/

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(通常在浏览器中运行)给用户。这是伟大的搜索引擎优化和用户体验，因为他不会等待那么长时间的页面显示。

Ember CLI是一个很好的工具，可以帮助你组织你的代码，它在不断增长的代码库中做得很好。烬也有它自己的插件生态系统，你可以选择从各种烬插件。你可以很容易地抓取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;
  }
}

利:我喜欢API和客户端的分离。聪明的人说这是 该走的路。理论上很好。看起来很前卫，令人兴奋。

我可以说它在实践中也很好。分离REST API的另一个优点是，以后可以在其他应用程序中重用它。在理想的情况下，你不仅可以在网页上使用相同的REST API，如果你决定编写一个移动应用程序，也可以在移动应用程序上使用。

弊:没有太多先例。这方面做得好的例子不多。公共 例子(twitter.com)感觉迟钝，甚至切换 这种方法。

现在情况看起来不一样了。有很多使用REST API +许多客户端使用它的例子。

我采用了一种混合的方法，我们使用Sinatra作为基础，ActiveRecord / Postgress等来提供页面路由(细长模板)，公开web应用程序可以使用的REST API。在早期的开发中，像填充选择选项这样的事情是通过helper渲染到精简模板中完成的，但当我们接近生产时，这就变成了对REST API的AJAX调用，因为我们开始更关心页面加载速度等等。

在Slim中很容易渲染出来的东西以这种方式处理，而东西(填充表单，从jQuery接收表单POST数据。验证的submitHandler等显然都是AJAX)

测试是一个问题。现在我正试图将JSON数据传递给Rack::Test POST测试。