客户端 - 服务器架构决策

时间:2012-11-13 23:02:29

标签: php ajax curl architecture client-server

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

我正处在需要解决和实施架构标准的十字路口。其中一个标准涉及客户端应用程序(基于AngularJS,因此具有多个视图的单页持久性)和第三方信息源之间的通信路由。

对我来说,通过我的后端路由所有对第三方库和数据的请求,然后通过CURL关闭到各个目的地似乎是直观和合乎逻辑的。

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

我很好奇行业标准会对此有何看法,以及潜在的陷阱。对我而言,它似乎会长期创造更多的秩序,组织和安全。

请告诉我您对此的看法,因为我需要外部观点。

1 个答案:

答案 0 :(得分:2)

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

我的简短回答是,我认为你走在了正确的轨道上。

我认为它更简洁,因为它保持数据路径简单,因为您的客户端总是向您的服务器发送请求 - 所以基本上您在客户端和其他所有内容之间得到非常松散的耦合(除了服务器上的控制器,很好,甚至是必要的IMO)。想要稍后更改数据源?客户端不受影响(除非格式不同)。如果您可以想象自己希望将来在某个时间将原始数据存储在数据库中,这也是有益的。根据您要连接的服务以及您要对数据执行的操作,通过您自己的服务器可以获得安全性好处(例如,如果您需要使用私钥对第三方服务进行身份验证,就像必须使用使用MasterCard提供的API。)

虽然性能受到打击,但除了额外的请求和DNS查找外,它还为您的服务器提供了更多功能,并且需要更多内存。然后,您将控制缓存,因此在某些情况下您可能会使服务稍微强大。

因此,除非表现至关重要,否则我会选择你想到的路线。究竟如何在您的服务器上完成路由是一个不同的问题,可能需要一些测试。只需确保使用的方法可以优雅地处理可能弹出的任何错误:)