将复杂嵌套SQL关联转换为可管理服务的前端数据建模最佳实践是什么？

Question

我正在寻求对这个问题的可能解决方案的看法。我将使用Rails和Rails，但实际上这个问题有点抽象，不需要在这些框架的上下文中得到回答。

在前端管理复杂嵌套SQL关联的最佳实践是什么？

假设您有posts，评论和注释嵌套在posts下面。您将文章以JSON的形式发送到前端，并在其下面嵌套注释。现在你可以在每个帖子下面显示它们了，太棒了。但随后出现了一些问题：

1. 如果你也想显示最近的评论呢？您的注释服务需要具有规范化集合中的注释，或者以允许按日期排序的方式访问它们。

- Does this mean you make a separate API call for comments sorted by date? This would duplicate comments on the front-end and require you to update them in two places instead of one (one for the posts and one for the comment, assuming comments can be edited or updated).
- Do you implement some kind of front-end data normalization? This meaning you have a caching layer that holds the nested data and then you distribute the individual resources to their corresponding service?

​

1. 如果有不同层次嵌套的数据怎么办？继续文章和评论的例子。如果你的评论能被回复到10的水平，那该怎么办？

- How does this effect your data model if you've made separate API calls for posts and comments?
- How does this effect your caching layer if you choose that approach?

​

1. 如果我们不是在谈论帖子呢？如果你可以评论照片和其他资源呢？

- How does this effect the two options for data-modeling patterns above?

​

如果我们讨论的是好友用户之间的递归关系，那么与示例不同呢？

我最初的想法和假设的解决方案

我最初的想法和我如何攻击它是用一个缓存层，并将数据规范化，这样：

1. 缓存层处理任何必要的规范化。
2. 缓存层保存每个记录的一种规范表示。
3. 服务与缓存层通信以执行CRUD操作。
4. 通常情况下，不关心，也不需要知道数据模型是如何嵌套/复杂的，当数据到达服务时，它已经规范化了。

递归关系在某个时候需要是有限的，不能永远继续嵌套。

当然，这听起来很棒，但我看到了很多潜在的陷阱，并希望能获得更多的视角。我发现很难将抽象的最佳实践与特定数据模型的具体解决方案分开。我很想知道其他人是如何解决这个问题的，他们将如何解决这个问题。

谢谢!

Answer 1

我假设您将使用restful，注意--我不知道rails --但我将建议您考虑一些通用实践

假设您有一个页面显示10个帖子及其按日期排序的10个注释，可以在一个api调用中实现此响应

还有一个页面只显示5个帖子，没有注释使用相同的api端点。

使用一些查询参数可以实现这一点。

尽量优化你的反应。

在任何编程语言中，您都可以在一个端点上输入多个响应类型，如果我们谈论API，我就是这样做的。

如果查询需要很长时间，并且该查询运行服务器时间，那么当然需要缓存，但是在每个api调用中讨论10个帖子不需要缓存。它不应该对数据库造成太大影响。

对于嵌套问题，您可以有一种机制使其成为可能，即我将获取10个帖子及其所有注释，我可以发送一个查询参数，其中包括每个帖子的所有注释

就像bar.com/api/v1/posts?include=comments

如果我只需要为他们的评论定制一些数据，我应该能够实现一些自定义包含。

就像bar.com/api/v1/posts?include=recent_comments

您的API层，应该首先与您的自定义包含(如果找不到)匹配，继续资源的关系。

对于更深层次的引用，如comments.publisher或recent_comments.publisher，您的API层需要知道您目前正在处理的是哪个资源。对于正常的包含，您不需要这样做，但是自定义包含应该描述它们所指向的模型/资源，这样就有可能创建无穷无尽的链。

我不知道Rails，但是如果您有一个强大的ORM/ODM，您可以很容易地使这种模式成为可能

有时候，你也需要做一些同样的过滤工作。

您可以使用筛选器查询参数并实现一些自定义筛选器。

即bar.com/api/v1/posts?include=recent_comments&filters=favorites

或者忘记一切然后在下面做点什么

bar.com/api/v1/posts?transformation=PageA

这将返回10个最近的帖子和他们最近的10个评论。

bar.com/api/v1/posts?transformation=PageB

这将只返回10个最近的帖子。

bar.com/api/v1/posts?transformation=PageC

这将返回10个最近的帖子和他们的所有评论。