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

我决定对Infiniforms采用选项2的体系结构，因为它提供了一种将UI与业务逻辑分离的好方法。

这样做的一个优点是API服务器可以独立于web服务器进行扩展。如果你有多个客户端，那么网站就不需要像web服务器那样扩展，因为一些客户端是基于手机/平板电脑或桌面的。

这种方法还为您向用户开放API提供了良好的基础，特别是当您使用自己的API为您的网站提供所有功能时。

这里已经有一些很好的答案了——我肯定会推荐第2条或第3条——分离在概念上很好，在实践中也很好。

很难预测API上的负载和流量模式等事情，而我们看到的那些独立为API提供服务的客户更容易进行配置和扩展。如果你必须在人类的网络访问模式中做到这一点，那就不那么容易了。此外，你的API使用可能会比你的web客户端增长得更快，然后你就可以看到你的努力方向了。

在#2 #3之间，这真的取决于你的目标-我同意#2可能是web应用程序的未来-但也许你想要一些更直接的东西，如果那个频道只是众多频道中的一个!

我个人更倾向于选择(3)作为解决方案。我的前雇主(家喻户晓的名字)几乎所有的网站都在使用它。这意味着你可以找一些了解Javascript、浏览器特性等的前端开发人员来编写你的前端代码。他们只需要知道“curl xyz，你会得到一些json”，然后他们就开始了。

同时，你的重量级后端人员可以编写Json提供程序。这些人根本不需要考虑表示，而是担心零散的后端、超时、优雅的错误处理、数据库连接池、线程和扩展等。

选项3为您提供了一个良好、可靠的三层架构。这意味着你从前端输出的东西是SEO友好的，可以用于旧的或新的浏览器(以及那些关闭了JS的浏览器)，如果你愿意，仍然可以是Javascript客户端模板(所以你可以用静态HTML处理旧的浏览器/googlebot，但将JS构建的动态体验发送给使用最新Chrome浏览器或其他浏览器的人)。

在我看到的所有情况下，选项3都是一些PHP的自定义实现，不能在项目之间特别转换，更不用说开源领域了。我猜最近PHP可能已经被Ruby/Rails取代了，但同样的事情仍然是正确的。

FWIW， $current_employer可以在几个重要的地方使用选项3。我正在寻找一个好的Ruby框架来构建一些东西。我确信我可以把一大堆宝石粘在一起，但我更喜欢一个广泛提供模板、“卷曲”、可选身份验证、可选memcache/nosql连接缓存解决方案的单一产品。这里我找不到任何有条理的东西:-(

同构渲染和渐进增强。这也是你选择第三个选项的原因。

同构呈现意味着使用与在客户端代码中使用的相同模板来生成服务器端标记。选择具有良好的服务器端和客户端实现的模板语言。为您的用户创建完全烘烤的html并将其发送到线上。也要使用缓存。

渐进式增强意味着一旦下载了所有资源，就可以开始执行客户端执行、呈现和事件监听，并确定客户端功能。为了可访问性和向后兼容性，尽可能使用无功能客户端脚本的功能。

是的，当然要为这个应用程序功能编写一个独立的json api。但不要太过分，为静态html文档那样工作得很好的东西编写json api。

我目前正致力于将一个巨大的CMS从选项1转换为选项3，并且进展顺利。我们选择在服务器端呈现标记，因为SEO对我们来说很重要，我们希望网站在移动电话上表现良好。

我使用node.js作为客户端的后端和一些模块来帮助我。我在这个过程中有点早期，但基础已经设置好了，这是一个检查数据确保它全部呈现正确的问题。这是我正在使用的:

Express for the app's foundation. (https://github.com/visionmedia/express) Request to fetch the data. (https://github.com/mikeal/request) Underscore templates that get rendered server side. I reuse these on the client. (https://github.com/documentcloud/underscore) UTML wraps underscore's templates to make them work with Express. (https://github.com/mikefrey/utml) Upfront collects templates and let's you chose which get sent to the client. (https://github.com/mrDarcyMurphy/upfront) Express Expose passes the fetched data, some modules, and templates to the front-end. (https://github.com/visionmedia/express-expose) Backbone creates models and views on the front-end after swallowing the data that got passed along. (https://github.com/documentcloud/backbone)

这是堆栈的核心。我发现其他一些有用的模块:

法立科(https / / github.com/trek/fleck) 时刻(https / / github.com/timrwood/moment) 手写笔(https / / github.com/LearnBoost/stylus) 整合(https / / github.com/fat/smoosh) 虽然我正在寻找grunt (https//github.com/cowboy/grunt) 控制台跟踪(//github.com/LearnBoost/console-trace)。

不，我没有使用coffeescript。

这个选择对我来说非常有效。后端模型是不存在的，因为我们从API获得的数据结构良好，并且我将其逐字传递给前端。唯一的例外是我们的布局模型，我添加了一个属性，使渲染更智能和更轻。我没有使用任何花哨的模型库，只是一个函数，在初始化时添加我需要的东西并返回自己。

(抱歉奇怪的链接，我太n00b堆栈溢出让我张贴那么多)