关于使用NodeJS UI服务器分离前端和后端的担忧 [英] Concerns about separating front-end and back-end with a NodeJS UI server

问题描述

在过去的几个月中，我们一直在寻找以下问题的解决方案:前端开发人员在没有后端开发人员帮助的情况下无法轻松修改网站的外观.

During the last months, we at work have been looking for a solution to the following problem: front-end developers can't easily modify the appearance of the website without the help of back-end devs.

我们作为一个团队的文化主要是基于全栈框架，例如Symfony 2和Ruby on Rails.我们使用模板引擎，但是模板大部分是根据设计人员的标记由backend-devs编写的.

Our culture as a team is mostly based on full-stack frameworks such as Symfony 2 and Ruby on Rails. We use templating engines but the templates are mostly written by backend-devs according to designers' markups.

我们正在考虑采取的步骤是将整体架构分离为后端rest API和作为"UI服务器"的NodeJS服务器. NodeJS服务器将处理客户端请求，使用后端API并返回渲染的模板.通过明确指定所提供的API和JSON，前端和后端开发人员可以并行工作，而出现的问题更少.此处的更多信息: http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/

The step we are considering to make is separating that monolithic architecture into a backend rest API and a NodeJS server as "UI server". The NodeJS server would handle the client request, consume the backend API and return a rendered template. By specifying clearly the API and the JSONs served, frontend and backend devs could then work in parallel with less problems. More info here: http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/

问题是，我们坚信这种分离与体系结构POV是一件好事，但我们担心这样做的弊端.我们怀疑这会使事情变得更艰难.团队中没有人从未使用过这种架构，因此任何有关这种架构的提示或经验都将是非常有价值的.

The thing is, we strongly believe that this separation is a good thing from an architecture POV, but we fear about the drawbacks. We suspect that it will make things way harder. None of us in the team has never worked with this kind of architectures, so any hint or experience about that would be very valuable.

值得吗?什么时候?为什么?

Is it worth it? When? Why?

推荐答案

您需要做的是要有一条清晰的线，将您的前端与后端分开.然后，无论后端团队需要什么前端，都将对其进行全面记录.

What you need to do, is to have a clear line that separates your front-end from back-end. Then whatever the front-end needs from the backend-end team, it will documented comprehensively.

让我们说您当前拥有的是这样的东西:

Let's say what you currently have is something like this:

app.get('/', function (req, res) {
    database.query('select * from user', function (err, result) {
        res.render(result);
    });
});

但是然后您要使它像这样:

But then then you want to make it like this:

在UI服务器中:

app.get('/', function (req, res) {
    request('apiServer/user', function (err, result) {
        res.render(result);
    });
});

在API服务器中:

app.get('/user', function (req, res) {
    database.query('select * from user', function (err, result) {
        res.send(result);
    });
});

这很好.通过将前端和后端分开，它们不仅在逻辑上而且在物理上都通过位于不同的服务器中而分开.

This is good. This will separate the front-end and back-end, but not only logically but also physically by being in different servers.

我相信，如果它们在同一台服务器上，那就没问题了.将它们放在不同的文件中，而不是上面的

I believe if they are under the same server it will be just ok. Instead of above, just have them in different files:

在user.js中:

exports.getAll = function (cb) {
    database.query('select * from user', cb);
};

在server.js中:

in server.js:

var user = require('./user');
app.get('/', function (req, res) {
    user.getAll(function (err, result) {
        res.render(result);
    });
});

为什么这比您的解决方案更好?因为它将触摸数据库和呈现数据分开，而且它没有额外的http往返路程.

Why this is better than your solution? Because it separates touching database, and rendering the data, and also it doesn't have a extra http round trip.

按照MVC模式，将类似user.js的文件放置在models目录中，将类似server.js的文件放置在控制器目录中.您要确保两者均已记录在案以供前端开发人员使用.

Following a MVC pattern, you put files that are like user.js in a models directory, you put files like server.js in a controller directory. You make sure both are documented for front-end developers.

现在，如果您的前端开发人员只是要更改UI，他们将只需触摸HTML文件.如果他们想添加一个包含数据的部分，他们将阅读后端文档，他们将向模型添加另一个调用以在呈现HTML的相应控制器中获取他们的数据.

Now if your front-end developers are just gonna make UI changes, they will just touch the HTML files. If they want to add a section with data, they will read the backend documentation, they will add another call to the model to get the data they in the respective controller that renders the HTML.

只需确保您将所有内容标准化，以便在出现新的变化时，您的团队中的程序员可以以某种方式预测接口的状态，请使用良好的ORM来繁重地进行数据库调用.如果您不是选择使用ORM，请进行良好的抽象.

Just make sure you will standardize everything, so when something new comes along, programmers in your team can somehow predict how the interface is going to be, use a good ORM to the heavy lifting on making database calls. If using an ORM is not your choice then make good abstractions.

因此，您的应用程序可以像这样:

So your application in layers can be like this:

Database --> ORM --> Models --> Controllers --> Views(HTML files)

现在，前端开发人员可以在上图的右侧进行操作.如果很好地提取了它们，他们只需要知道左侧的文档化API，但是他们不需要知道它是如何工作的.在控制器上工作的任何人都只需要知道左侧记录的API(即模型)即可.您可以一直将其继续到左侧的数据库.

Now the front-end developers, work on the right side the above diagram. They only need to know the documented API of their left side if it's nicely abstracted away, but they don't need to know how it works. Anyone who works on the controllers, only need to know the documented API of their left side which is Models. You can continue it all the way to the database on the left.

然后在每一层上都可以进行单元测试和集成测试，直到最前端，以确保接口一致.

Then on each layer you can have unit tests and integration tests all the way to the front to make sure the interfaces are consistent.

如果您的团队很大，并且代码库很大，请确保始终保持界面的向后兼容性，但在日志中警告不要使用的内容.永远不要尝试破坏任何东西.

And if you're team is large, with a large code base, make sure you always keep the backward compatibility in your interfaces, but with warnings in logs for deprecated stuff. Never try to break anything.

这篇关于关于使用NodeJS UI服务器分离前端和后端的担忧的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！