关于使用 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.我们使用模板引擎，但模板大多由后端开发人员根据设计师的标记编写.

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 服务器中:

in API server:

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 中:

in 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 的文件放在模型目录中，将类似于 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:

数据库 -->ORM -->型号 -->控制器 -->视图(HTML 文件)

现在前端开发人员，在上图的右侧工作.如果它被很好地抽象出来，他们只需要知道他们左侧的文档化 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屋！