部署脱钩前+后端

Question

我已经写了使用两个完全解耦的组件的Web应用程序的应用程序：

1. 是基于离地构架，是 类型的请求的API：/api/*任何客户。
2. 解耦基于AngularJS建成使用grunt build

现在前端，到API但我想这两个单位的前端会谈将要部署一个代理之后，像nginx可以代理传入的请求到相应的组件。例如，我想所有的/web/*请求都会从包含所有客户端源代码（js/html/etc）的web目录和所有/api/*请求代理到我的Play框架服务器（我们需要传递到服务器的路径以确保正确路径返回）以返回所有与API相关的数据。例如，像GET domain.com/api/users这样的请求应在内部代理为GET 127.0.0.1:9000/api/users。

我已经在网上看到了一些关于这方面的讨论，我仍然希望通过你们运行它，看看哪种方法是这种部署的最佳方法。最终，我想要一个面向服务的体系结构，我希望能够更灵活地解耦事物。

Answer 1

我已经构建并部署了Play Framework + AngularJS应用程序，发现nginx是一个很好的方法。

随着您的应用程序体系结构的发展，Nginx还为您提供了一条增长途径来处理更多服务。例如，您可以为/api/user/*添加专用服务，同时保留所有其他/api/*路线的标准服务。

在某些时候，你可能需要去商业产品，但为了我现在和可预见的将来的需要，nginx是惊人的。

我nginx的配置的相关部分是：

server { 
    listen  80; 

    # Without this, Play serves the assets from within it's bundled jar. That's 
    # fine and works but seems unnecessary when nginx can serve the files directly. 
    location /assets { 
     alias /app/live/my-play-app-here/active/public; 
    } 

    location/{ 
     proxy_pass   http://localhost:9000; 
     proxy_set_header  X-Real-IP $remote_addr; 
    } 
} 

这里的关键部分是/assets URI空间。你的可能会有所不同，因为你完全独立地打包你的AngularJS应用程序。我的角度应用程序位于Play应用程序的/app/assets/javascripts文件夹内。这有利有弊（我很喜欢你的想法，保持它完全分开）。我对/assets块所做的工作允许nginx直接提供静态内容，因为当nginx做得很好时，Play似乎很愚蠢。

这不是在您的情况，但对别人有戏中的一切，对上述服务静态资产战略工作，部署过程需要解压从存档的public目录由play dist做，像这样有关这（从我的bash部署脚本摘录）：

unzip lib/$SERVICE_BASE_NAME.$SERVICE_BASE_NAME-$VERSION.jar "public/*" 

为您的特定情况下，像下面可能是一个良好的开端：

server { 
    listen  80; 

    location /api { 
     proxy_pass   http://localhost:9000; 
     proxy_set_header  X-Real-IP $remote_addr; 
    } 

    location/{ 
     alias /app/live/my-angularjs-app-here/active/public; 
    } 
}