客户端-服务器架构决策答案

【问题标题】：Client-Server Architectural Decision客户端-服务器架构决策
【发布时间】：2012-11-02 10:50:22
【问题描述】：

这不是一个故障排除问题，而是一个行业标准问题。

我正处于需要解决和实施架构标准的十字路口。这些标准之一涉及客户端应用程序（基于 AngularJS，因此具有多个视图的单页面持久性）和第三方信息源之间的通信路径。

对我来说，通过我的后端路由对第三方库和数据的所有请求，然后通过CURL 发送到各个目的地，这似乎既直观又合乎逻辑。

通过这种方式，我的服务器充当客户端和外部世界之间的网关（很像手机塔路由器和手机之间的关系）。

我很好奇行业标准对此有何规定，以及潜在的陷阱。对我来说，从长远来看，它似乎会创造更多的秩序、组织和安全。

请让我知道您对此有何想法，因为我需要外部观点。

【问题讨论】：

它是什么样的应用程序？它是数据流应用程序吗？您需要对这些数据/ETL 进行任何形式的详细说明吗？
B2B，没有数据流。一切都是异步的和基于会话的。

标签： php ajax curl architecture client-server

【解决方案1】：

不确定这是否重要，因为我不了解任何行业标准 - 但我将其解释为您真正要求的是一般的外部视角。所以这里是：

我的简短回答是，我认为您走在正确的轨道上。

我认为它更简洁，因为它使数据路径保持简单，因为您的客户端总是向您的服务器发送请求 - 所以基本上您的客户端和其他所有东西之间的耦合非常松散（除了服务器上的控制器，它很好，甚至是必要的国际海事组织）。想稍后更改数据源？客户端不受影响（除非格式当然不同）。如果您可以想象自己将来出于某种原因想要将原始数据存储在数据库中，这也是有益的。根据您要连接的服务以及您想对数据执行的操作，通过您自己的服务器可以带来安全优势（例如，如果您需要使用私钥对 3rd 方服务进行身份验证，就像必须使用 MasterCard 提供的 API）。

但性能会受到影响，因为除了产生额外的请求和 DNS 查找之外，它还让您的服务器有更多的工作要做并且需要更多的内存。再说一次，您将控制缓存，因此在某些情况下您可以使服务更加健壮。

所以除非性能是最重要的，否则我会走你想的路线。究竟如何在您的服务器上完成路由是一个不同的问题，可能需要进行一些测试。只要确保您使用的方法可以让您优雅地处理可能弹出的任何错误:)

【讨论】：