为 React+Redux 应用程序发回规范化或非规范化 API 响应是否更好？答案

【问题标题】：Is it better to send normalized or denormalized API response back for React+Redux applications为 React+Redux 应用程序发回规范化或非规范化 API 响应是否更好？
【发布时间】：2017-05-25 15:05:59
【问题描述】：

我正在编写一个 react-redux 应用程序。一开始，它调用一个端点，该端点以高度嵌套的 JSON 形式返回大量数据。然后我对其进行规范化并将其放入我的 redux-orm 架构中。
对我来说，考虑到它来自规范化的 PostgreSQL 数据库，在后端创建嵌套数据只是为了遍历前端的嵌套数据以对其进行规范化似乎很愚蠢。

Database = Normalized --> 
API = Denormalized --> 
Frontend = Normalized

最好只发回规范化的 API 响应吗？

【问题讨论】：

当您谈论规范化/非规范化时，我认为它们是数据库实体，而不是域模型。听起来像是一个领域驱动的讨论，而不是一个简单的问题。
我会避免与数据库紧密耦合..
@Takahiro 所以你是说这是一个个案决定，没有最佳实践？
@user2864740 与非规范化 API 响应相比，发送规范化 API 响应如何增加前端和数据库之间的耦合？

标签： reactjs redux denormalization normalize redux-orm

【解决方案1】：

我不明白为什么有人会在前面正常化。我进行标准化的全部原因是为了摆脱重复。我不是多次发送相同的嵌套数据，比如用户对象，而是嵌套用户 ID，并在一个名为“users”的单独属性中，我会将所有需要的用户及其 ID 作为键发送，以便快速轻松地访问，如下所示：

"users": {
    "1": { "id": "1", "name": "user_name", ...rest_of_user_details},
    ...
}

毕竟前台处理非规范化的数据比较容易。只需按原样列出具有嵌套对象的数据，而不是使用对象 ID 访问其他属性中的这些对象，所需的代码更少。

【讨论】：

【解决方案2】：

这会有所帮助；如您所说，建议在状态下使用标准化数据：https://redux.js.org/faq/organizing-state#how-do-i-organize-nested-or-duplicate-data-in-my-state

如果您仍想从 API 发送嵌套数据，例如要仅发送需要的内容或者如果它是现有的 API，您可以在将数据添加到存储之前在客户端进行规范化。例如这个库：https://redux.js.org/faq/organizing-state#how-do-i-organize-nested-or-duplicate-data-in-my-state

【讨论】：

【解决方案3】：

我不确定是否有一种“好”的方法可以做到这一点。如果您必须处理现有的 API，则处理它，并在前端代码中使用代理/解析器将后端有效负载映射到您的 redux-orm 存储，以及在另一端。

在我们的 React/Redux/Redux-orm 应用程序 Wisembly Jam 生产近一年后，我不会在这里假装给出答案，而是提供反馈。

当我们从头开始时，我们选择将JsonAPI spec 用于我们的 API。我们喜欢它，因为它以一种非常适合我们的 PostgreSQL 方案以及我们的 redux-orm 方案的方式公开对象和关系。

这样，双向不需要模型关系嵌套，只有在 data 字段中处理的普通对象，在 included 字段中包含关系。它看起来非常好地结合在一起。

您可以检查我们的应用程序网络选项卡以查看我们的 api 有效负载响应，以及我们的 redux-orm 存储（使用 Redux Chrome 扩展程序）。

希望能有所帮助，尽管我的英语不是正确的答案:)

【讨论】：