服务器渲染：预取数据性能

Question

我有一个运行良好的 React Redux 服务器渲染应用程序。

当我进入不同的页面时，我测量了一些服务器响应时间：

• 在我的 /singin 页面上，我在 60 毫秒内收到了响应。很好。

• 在我的 /user 页面（需要身份验证）上，我在 300 毫秒内收到了响应。因为服务器必须通过请求 API 知道用户是否有权访问此页面来预取当前用户会话和当前用户

• 在我的 /user/graph 页面上。我在 600 毫秒内得到了响应。因为服务器必须通过请求 API 来预取当前用户会话、当前用户和图形数据。

主要问题是我无法并行化所有这些请求。

这是服务器流程：

• 接收 /user/graph 的页面请求
• 并行获取 /api/user/session 和 /api/user/me
• 用 React-Router 做路由匹配（需要知道用户是否经过认证才能重定向）
• 此时，服务器知道将要呈现的组件。对于它们中的每一个，它并行获取所需的数据。这意味着获取 /api/graph、/api/graphConstants1、/api/graphConstants2 等。
• 反应渲染

这是我的问题：

1. 最佳实践是什么？
2. 如何减少由于预取请求而导致的初始渲染时间？
3. 我应该只在客户端执行大请求（如 /api/graph）吗？但那服务器渲染的目的是什么？
4. 我是否应该要求我的 api 团队创建一个自定义超级方法，仅用于渲染服务器在一个请求中检索所有数据？

Answer 1

这是服务器流程：

• 接收/user/graph的页面请求
• 并行获取/api/user/session和/api/user/me
• 用 React-Router 做路由匹配（需要知道用户是否通过认证才能重定向）
• 此时，服务器知道将要呈现的组件。对于它们中的每一个，它并行获取所需的数据。这意味着获取/api/graph、/api/graphConstants1、/api/graphConstants2 等。
• 反应渲染

这对我来说看起来很完美，这就是基于 Microservices 的架构的行为方式。

正如您所说，大多数 API 调用都是并行进行的，因此无需担心连续 API 调用之间的延迟。

主要问题是我无法并行化所有这些请求。

但是，您可以要求 API 团队为所需的微服务提供一个综合 API。在这种情况下，API 团队需要并行或多线程处理。

并行获取/api/user/session和/api/user/me

看起来，您正在调用/api/user/session 来验证用户的session。但是，您不应该将caching 用于/api/user/me。

我猜/api/user/me 这是一个GET 请求，是减少此类调用的一种方法。如果 signin 成功并缓存数据，则此 API 发送的 data 可以轻松地发送到 signin API。

在对用户数据进行任何更新时，即在任何POST、PUT、DELETE 调用中，可以清除现有的缓存数据，并且API 可以返回将要使用的用户的最新状态预热缓存。

PS：这种决定可以/不能基于 StackOverflow 答案做出，但需要 API 提供者和消费者之间的深入讨论和协议。