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

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

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

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

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

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

我目前正致力于将一个巨大的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堆栈溢出让我张贴那么多)

问得好。+ 1。当然，这对我将来是一个有用的参考。此外，@Aaron和其他人也为讨论提供了价值。 和Ruby一样，这个问题同样适用于其他编程环境。

我使用了前两个选项。第一个用于许多应用程序，第二个用于我的开源项目Cowoop

选项1 这无疑是最受欢迎的一个。但我发现实现是非常http的。每个API的初始代码都用于处理请求对象。所以API代码不仅仅是纯粹的ruby/python/其他语言代码。

Option 2 I always loved this. This option also implies that HTML is not runtime generated on server. This is how option 2 is different from option 3. But are build as static html using a build script. When loaded on client side these HTML would call API server as JS API client. Separation of concerns is great advantage. And very much to your liking (and mine) backend experts implement backend APIs, test them easily like usual language code without worrying about framework/ http request code. This really is not as difficult as it sounds on frontend side. Do API calls and resulting data (mostly json) is available to your client side template or MVC. Less server side processing. It means you may go for commodity hardware/ less expensive server. Easier to test layers independently, easier to generate API docs. It does have some downsides. Many developers find this over engineered and hard to understand. So chances are that architecture may get criticized. i18n/l10n is hard. Since HTML is essentially generated build time are static, one needs multiple builds per supported language (which isn't necessarily a bad thing). But even with that you may have corner cases around l10n/i18n and need to be careful.

Option 3 Backend coding in this case must be same as second option. Most points for option 2 are applicable here as well. Web pages are rendered runtime using server side templates. This makes i18n/l10n much easier with more established/accepted techniques. May be one less http call for some essential context needed for page rendering like user, language, currency etc. So server side processing is increased with rendering but possibly compensated by less http calls to API server. Now that pages are server rendered on server, frontend is now more tied with programming environment. This might not be even a consideration for many applications.

Twitter的情况下

据我所知，Twitter可能会在服务器上进行初始页面渲染，但对于页面更新，它仍然有一些API调用和客户端模板来操作DOM。所以在这种情况下，你需要维护两个模板，这增加了一些开销和复杂性。不是每个人都能负担得起这个选项，不像Twitter。

我们的项目Stack

我碰巧使用Python。我使用JsonRPC 2.0代替REST。我建议使用REST，尽管出于各种原因我喜欢JsonRPC的想法。我使用下面的库。考虑选项2/3的人可能会觉得有用。

一个快速的web微框架- Flask 前端服务器:Nginx 客户端MVC: Knockout.js 其他相关工具/库: Jquery js代表货币 Webshim:跨浏览器填充 director:客户端路由 生成HTML

我的结论和建议

选项3 !

总之，我已经成功地使用了选项2，但现在为了简单起见，我倾向于选项3。使用构建脚本生成静态HTML页面，并使用专门提供静态页面的超高速服务器提供这些页面是非常诱人的(选项2)。

在创建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/

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

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

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

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

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

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

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