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

Question

我伸出手来了解这个问题的可能解决方案。我将使用Angular和Rails，但实际上这个问题有点抽象，并且不需要在这些框架的上下文中得到解答。

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

我们假设您有帖子，评论和评论嵌套在帖子下。您将帖子作为JSON发送到前端，并在其下嵌套注释。现在你可以在每个帖子下面列出它们了，很棒。但随后出现了问题：

1. 如果您还想显示最近的评论怎么办？您的评论服务需要在规范化集合中发表评论，或者以允许按日期排序的方式获取对它们的访问权。

   • 这是否意味着您对按日期排序的评论进行单独的API调用？这会在前端复制注释，并要求您在两个地方而不是一个地方更新它们（一个用于帖子，一个用于注释，假设可以编辑或更新注释）。
   • 您是否实施了某种前端数据规范化？这意味着你有一个缓存层来保存嵌套数据，然后你将各个资源分配给它们相应的服务？

2. 如果您的数据具有不同的嵌套级别，该怎么办？继续发帖和评论示例。如果您的评论可以回复到10级，那该怎么办？

   • 如果您对帖子和评论进行了单独的API调用，这对数据模型有何影响？
   • 如果选择这种方法，这会如何影响您的缓存层？

3. 如果我们不只是在谈论帖子怎么办？如果您可以评论照片和其他资源怎么办？

   • 这对上面的数据建模模式的两个选项有何影响？

打破示例，如果我们谈论的是朋友之间的递归关系怎么办？

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

我最初的想法以及我对此的攻击方式是使用缓存层并对数据进行规范化，以便：

1. 缓存层处理任何必要的规范化
2. 缓存层包含每个记录的 ONE 规范表示
3. 服务与缓存层通信以执行CRUD操作
4. 服务通常不关心，他们也不需要知道数据模型的嵌套/复杂程度，到数据到达服务时它是否正常化

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

这当然听起来很棒，但我看到很多潜在的陷阱，并希望获得观点。我发现很难将抽象的最佳实践从具体的解决方案分离到特定的数据模型。我很想知道别人如何解决这个问题，以及他们将如何解决这个问题。

谢谢！

Answer 1

我假设你会使用restful apis，注意我不知道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篇最近的帖子及其所有评论