部署应用程序的分离的前端 + 后端 [英] Deploying a decoupled front + backend of an application

问题描述

我使用两个完全分离的组件编写了一个 Web 应用程序:

I've written a web app using two completely decoupled components:

1. 一种基于 Place Framework 的 API，为以下请求提供服务输入:/api/* 到任何客户端.
2. 一个基于AngularJS的解耦前端，使用grunt build
构建

1. An API that is based off the Place Framework and serves requests of type: /api/* to any client.
2. A decoupled front end based on AngularJS built using grunt build

现在，前端与 API 对话，但我希望这两个单元都部署在代理后面，例如可以代理传入请求的 nginx到相应的组件.例如，我希望所有 /web/* 请求都从包含所有客户端源(js/html/etc.)和所有 /api/* 请求代理到我的 Play 框架服务器(我们需要将路径传递到服务器以确保返回正确的路径)以返回所有 API 相关数据.例如，像 GET domain.com/api/users 这样的请求应该在内部代理到 GET 127.0.0.1:9000/api/users.

Now, the front end talks to the API but I'd like both of these units to be deployed behind a proxy, something like nginx that can proxy incoming requests to the respective component. For example, I'd like all the /web/* requests to be served off a web directory containing all the client side source (js/html/etc.) and all the /api/* requests to be proxied to my Play framework server (we will need to pass on the path to the server to make sure the right paths are served back) to return all the API related data. For example, a request like GET domain.com/api/users should be internally proxied to GET 127.0.0.1:9000/api/users.

我在网上看到了一些关于这个的讨论，我仍然想通过你们来看看哪种是这种部署的最佳方法.

I've seen some discussions online about this and I'd still like to run it through you guys to see which is the best approach for this kind of deployment.

最终，我想要一个面向服务的架构，并且我想要进一步分离事物的灵活性.

Eventually, I'd like a service oriented architecture and I'd like the flexibility to decouple things even further.

推荐答案

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

I have built and deployed Play Framework + AngularJS apps and found nginx to be a great approach.

Nginx 还为您提供了一条增长路径，可以随着应用架构的增长处理更多服务.例如，您可以为 /api/user/* 添加专用服务，同时为所有其他 /api/* 路由保留标准服务.

Nginx also gives you a growth path to handle more services as your app architecture grows. For example, you might add a dedicated service for /api/user/* while keeping the standard service for all other /api/* routes.

在某些时候，您可能需要使用商业产品，但就我现在和可预见的未来的需求而言，nginx 非常棒.

At some point you might need to go to a commercial product but for my needs for now and the foreseeable future, nginx is amazing.

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

The relevant part of my nginx config is:

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 应用程序.我的 angular 应用程序位于 Play 应用程序的 /app/assets/javascripts 文件夹中.这样做有利有弊(我非常喜欢您将其完全分开的想法).我对 /assets 块所做的事情允许 nginx 直接提供静态内容，因为当 nginx 做得很好时，Play 提供它似乎很愚蠢.

The key part here is the /assets URI-space. Yours will probably be different because you package your AngularJS app completely independently. My angular app is within the Play app's /app/assets/javascripts folder. There are pros and cons to this (I quite like your idea of keeping it completely separate). What I've done with the /assets block is allowed nginx to serve the static content directly, as it seems pretty silly for Play to serve that when nginx does a fine job.

它与您的场景不太相关，但对于在 Play 中拥有所有内容的其他人来说，要使上述服务静态资产策略起作用，部署过程需要从存档中解压 public 目录由 play dist 制作，类似这样(摘自我的 bash 部署脚本):

It's not so relevant in your scenario but for others that have everything within Play, for the above serving-static-assets strategy to work, the deployment process needs to unpack the public directory from the archive made by play dist, something like this (an excerpt from my bash deployment script):

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

对于您的特定场景，以下内容可能是一个好的开始:

For your particular scenario, something like the below is probably a good start:

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;
    }
}

这篇关于部署应用程序的分离的前端 + 后端的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！