在我的应用程序架构中，我有以下组件：
手机正在与api交谈，这很明显。 但是，我想知道哪个Web组件应该与api交谈。
一开始，我开始将其作为服务器端。然后我意识到服务器只是调用api，客户端也可以这样做 - 那么为什么不将这些调用委托给客户端呢？那就是：
我们得到：
它的优点是我们的服务器必须减少网络呼叫，从而减少带宽。现在客户端可能需要一些增加的带宽，但它并不需要处理所有用户。此外，客户端整体加载时间没有增加（我认为？），因为客户端无论如何都必须等待api响应;是否来自服务器。
因此，目前，我的网络客户端正在直接与网络对话。 但是，感觉有点奇怪，特别是关于身份验证。
答案 0 :(得分：2)
将客户端配置为通过中间Web服务器运行并不是一个糟糕的设置，可能更可取。
如果您的Web服务器只是向后端提供静态内容和管道API请求，那么它可能支持许多API实例的流量。这意味着您可以通过拥有多个API实例来增加容量，并让Web服务器在它们之间实现负载平衡。
此外，您可以通过在内部网络上访问API并通过可公开访问的Web服务器路由呼叫来减少托管环境的攻击面。这样您还可以选择要发布的API接口的数量。
最后，您可以在一个地方处理身份验证。如果身份验证由Web服务器处理，并且在将其路由到API服务器之前检查每个调用的身份验证，那么您的API服务器就不用担心了（这假设您的API服务器只能在您的内部网络上访问，如上所述。）您甚至可以在此时实现身份验证方案，以便用户只能访问API服务器接口的子集。
答案 1 :(得分：1)
这个问题已经存在了一段时间，但我会添加一个答案作为参考。
客户端渲染会影响初始加载，因为客户端（本例中的浏览器）首先必须从Web服务器接收所有javascript代码，然后再向API服务器发出另一个请求以获取数据。 / p>
另一个问题是SEO。网络抓取工具不会处理javascript呈现（谷歌是唯一声称在此问题上的改进）。他们只是希望html作为对他们请求的响应，而没有数据的页面对索引目的无用。
为了缓解这个问题，可以采用混合方法，即所谓的通用（以前称为同构）应用程序。这是一个可以在客户端和服务器上呈现的应用程序。它将具有客户端应用程序的优势，但服务器端呈现将提供Web爬网程序并将负责第一次加载。现在，通用方法非常可行，因为JavaScript可以在服务器和客户端上运行。因此，大多数代码都可以共享。
在airbnb中有一篇非常好的博客文章可以讨论它：http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/