rest - 使用 Play 2.1 作为后端构建 AngularJS 客户端代码的好方法

Question

我拥有一个 Play 2.1 应用程序。

最初，我使用 Play 2.1 中的默认模板机制，直到我.. 学习了 AngularJS。

现在，我显然希望我的客户端成为一个 AngularJS 应用程序。

但是，在网上冲浪时，我发现没有明确的方法可以实现:

让 Play 表现得像一个简单的 RESTful 应用程序(删除 view 文件夹)并制作一个完全不同的项目来构建 View (由 grunt.js 初始化的 AngularJS 应用程序)。
优点:可能不那么困惑，前端和后端团队可以轻松地分开工作。
缺点:AngularJS 应用程序需要另一个 HTTP 服务器。

尝试将 AngularJS 应用程序与传统 Play 的工作流程完全集成。
缺点:使用像 AngularJS 这样相当复杂的框架，会导致模板管理困惑，例如:scala.html(用于 Play)/tpl.html(用于 Angular)... => 凌乱。

在 play 项目中创建一个自定义文件夹，但与 Play 脚手架创建的初始文件夹不同。我们叫它myangularview代替传统 view例如。然后，将 grunt.js 生成的静态内容发布到 Play 的 public文件夹，以便可以通过 Play 的路由从浏览器访问。
优点:组件之间的 SRP 仍然相当受尊重，不需要像 1 中那样为客户端使用另一个轻量级的 HTTP 服务器。

我指出了我自己对优点和缺点的看法。

实现 Play 与 Angular 结合的好方法是什么？

Answer 1

是的，我正在回答我自己的问题:)

我遇到了这种做事方式:
http://jeff.konowit.ch/posts/yeoman-rails-angular/

铁轨？？无论框架如何，需求都完全相同。

它提倡 API(后端)和前端(在这种情况下对后端服务器进行 AJAX 调用)之间的真正分离。

因此，我学到的是:

在开发阶段，开发人员将使用两台服务器:两个不同端口上的 localhost。

在生产阶段，前端元素将被包含在整个后端(本文将处理一种 public 文件夹，旨在提供静态内容:HTML、 Angular 模板(例如)、CSS 等......优势？=> 处理一个独特的服务服务器的 API 展示以及 UI 的静态 Assets 。

有了这个组织，一些像 Yeoman 这样的工具将能够为开发人员带来一些非常棒的方便的东西，例如: livereload 特征。 :):)

当然，在开发阶段，我们最终会得到两个不同的域(例如 localhost:3000 和 localhost:9000)，导致传统 ajax 请求出现问题。然后，正如文章指出的那样，代理可能真的很有用。

我真的觉得这整个练习非常优雅和愉快。