AngularJS:服务器端架构 [英] AngularJS: Server Side Architecture

问题描述

在我们的企业内网中，我们有一些端点服务平台，如 BPM、文档管理系统等.这些端点服务公开了 REST API.我们使用 AngularJS 作为前端开发 Web 应用程序.

Within our corporate intranet, we have a few end-point service platforms like BPM, document management system, etc. These end-point services expose REST API. We develop web applications using AngularJS as front end.

关于如何从 AngualJS 调用这些端点服务有两种选择.

There are two options on how we can make calls from AngualJS to these end-point services.

选项 1:鉴于这些端点服务公开 REST，直接从 AngualrJS 调用这些 REST API.

Option 1: Given these end-point services expose REST, call these REST API directly from AngualrJS.

选项 2: 引入中间层(在 WebLogic 或 Tomcat 等应用服务器上).构建一个调用端点 REST API 的 Java 应用层；并将其托管在此 Millde 层上.AngularJS 调用这个中间层提供的 REST；该中间层依次调用端点 REST.

Option 2: Introduce a middle layer (on an application server like WebLogic or Tomcat). Build a Java application layer that calls into the end-point REST API; and host it on this millde layer. The AngularJS calls into REST provided by this middle layer; this middle layer inturn calls into the end-point REST.

我个人更喜欢选项 1；但是我邀请您就此事发表意见.我已经列出了我所看到的选项 1 的优缺点.

I personally prefer the Option 1; however I invite your openion on this matter. I have listed the pros and cons of Option 1 as I see them.

选项 1 的优点:

• 由于 HTTP 请求的跃点减少一跳，因此性能(吞吐量)更高.
• 由于组件减少，开发/部署工作量减少.
• 较少的故障点.如果有问题，我们会在 AngualrJs 或最终服务中知道它.

选项 1 的缺点:

• 安全问题?不确定这一点 - 希望专家对此发表评论.
• CORS:终端服务需要为适当的域启用 Access-Control-Allow-Origin.
• 记录不佳?如果出现问题，日志将仅在用户计算机(IE/Chrome 开发工具)或终端服务上可用.
• AngualJS 层处理过多?这个处理主要是解析端服务的结果.这还取决于所使用的终端服务类型.

推荐答案

在我看来，从长远来看，选项 2 是更好的选择.这样做的原因很少.

option 2 in my opinion is a better option in long run. There are few reasons for that.

安全是首要的，如果中间有一个中间件，你就可以拥有固有的安全性，这意味着你可以只公开你的 angular webapp 需要的那些 REST API.您还可以包含 oAuth 等安全机制，因为您可以控制中间件.

Security is first and foremost, If you have a middleware in between, you can have inherent security, which means you can expose only those REST APIs which your angular webapp needs. You can also include a security mechanism like oAuth since you control the middleware.

日志是另一回事.当然，现在任何应用程序都需要某种审计.安全性和日志记录都是实际 REST 调用之前的层.

Logging is another one. for sure any application nowadays do need some sort of auditing. both security and logging are layers before your actual REST calls.

您可以在任何关键 REST API 上添加一些方面，以便在调用该 API 时触发邮件的情况下，即使我们目前不需要这些灵活性，也总是很方便.

You would be able to add some aspects on any key REST API, such that in case if that API is called trigger a mail, it's always handy to have those flexibility even we don't need at the moment.

您可以有效地包含响应转换和错误处理.一旦你从服务中得到响应，你就可以在你的中间件中转换响应，删除不必要的或关键的字段，召唤一些值等等.这一切都可以用 angular 来完成，但真正的响应或错误会暴露给客户端.

You can include response transformation and error handling efficiently. Once you get the response from service, in your middleware you can transform the response, remove unnecessary or critical fields, conjure some values etc. This all can be done with angular also but then the real response or error is exposed to the client.

不利的一面是，您正确地提到了性能是其中之一，但是让您的 REST 中间件与服务 REST 保持同步的 imo 更加有害.服务添加的任何新 API 都需要包含在中间件中，重新编译和重新部署.但这也取决于这些变化的可能性和频率是多少?对于任何这些更改，您无论如何可能需要在 angular webapp 中更改以包含它.

On the downside you rightly mentioned performance is one but imo keeping your REST middlware in sync with services REST is more bane. any new API added by services, needs to be included in middleware, recompiled and redeployed. But it also depends what are the likelihood and frequency of those changes? for any those changes you anyhow might need to change in angular webapp to include it.

这篇关于AngularJS:服务器端架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！