ios - parse.com 'retweet' 模式太冗长

Question

因此，我的任务是使用 Parse 在应用程序(iOS、Swift)中实现类似“转推”的功能。 .

这已经被问过here ，但那是 a) 相当高水平和 b) 我手头的任务 - 我不一定在架构决策上寻求帮助，但如果看起来我显然遗漏了什么，我很乐意接受反馈。

我的应用有 CAUSES，每个 CAUSES 都是由用户创建的。还有一个包含 TO 和 FROM 用户的 FOLLOW 表。因此，首先，我简单地查询 CAUSES 表，条件是发布的 USER 应该与 FOLLOW 表中的 TO 用户(当前用户是 FROM 用户)的 objectId 匹配。更简洁:

let getFollowedUsersQuery = PFQuery(className: Constants.kParseClassFollowers)
getFollowedUsersQuery.whereKey(Constants.kParseFieldFromUser, equalTo: PFUser.currentUser()!)

let causesQuery = PFQuery(className: Constants.kParseClassCauses)
causesQuery.whereKey(Constants.kParseFieldFromUser, matchesKey: Constants.kParseFieldToUser, inQuery: getFollowedUsersQuery)
causesQuery.findObjectsInBackgroundWithBlock({ (objects, error) -> Void in
    if let causes = objects {
        for cause in causes {
          // populate the tableview cells, etc.
        }
    }
})

现在我有来 self 关注的用户的所有原因......这都是非常标准的。

这就是它变得棘手的地方。
每个 CAUSE 也有一个称为 SUPPORTERS 的关系。现在我需要设计一种方法来从我不关注的人那里获取所有原因，但在他们的支持者列表中有我关注的用户。

我还没有找到一个优雅的解决方案，尽管我正在接近一个“蛮力”解决方案，而且它是如此繁琐和冗长，以至于我的程序员大脑的一半是 screaming at me like Susan Powter ...

这是一个示例:

let retweetQuery = PFQuery(className: Constants.kParseClassCauses)
retweetQuery.orderByDescending(Constants.kParseFieldCreatedAt)
retweetQuery.whereKey(Constants.kParseFieldFromUser, notEqualTo: PFUser.currentUser()!)
retweetQuery.whereKey(Constants.kParseFieldFromUser, doesNotMatchKey: Constants.kParseFieldToUser, inQuery: getFollowedUsersQuery)
retweetQuery.findObjectsInBackgroundWithBlock({ (objects, error) -> Void in
    if let causes = objects {
        for cause in causes {
            let supporterRelations = cause.relationForKey(Constants.kParseClassSupporters)
            let supporterQuery = supporterRelations.query()
            supporterQuery.findObjectsInBackgroundWithBlock { (supporters, error) in
                if(error == nil && supporters?.count > 0) {
                    for supporter in supporters! {
                        let user:PFUser = supporter as! PFUser
                        getFollowedUsersQuery.whereKey(Constants.kParseFieldToUser, equalTo: user)
                        getFollowedUsersQuery.whereKey(Constants.kParseFieldFromUser, equalTo: PFUser.currentUser()!)
                        getFollowedUsersQuery.findObjectsInBackgroundWithBlock({ (results, error) -> Void in
                            if(error == nil && results?.count > 0) {
                                for result in results! {
                                    // do stuff
                                }
                            }
                        })
                    }
                }
            }
        }
    }
})

现在，这纯粹是疯狂，而且非常浪费(特别是考虑到 Parse 如何计算免费层 - 我觉得如果将其推向生产，这可能会严重影响我的 API 限制)。

在已经完成两个查询后，我完全重做一个，然后对 SUPPORTER 关系执行另一个查询针对每个原因，然后对该关系中的每个用户执行另一个查询看看我是否关注他们......一旦我获得了这些信息，我需要遍历该用户支持的原因(由于 Parse 查询的异步返回，我觉得我不能回到父级循环)...我还没有实现，因为我即将认输 - 必须有更好的方法!

我希望我在这里遗漏了一个策略......

Answer 1

@jesses.co.tt 很抱歉，如果这太少太晚了，我绝对注意到我在这个问题被问到几个月后才回答，但我确实认为这总体上值得回答(也许可以仍然对你有值(value))。

总的来说，我 100% 同意使用 Parse 的三重查询 a) 其计费方式(在旧系统中)将非常低效 b) 考虑到这一点，即使使用 self 也似乎是错误的方法-hosted Parse(从上下文来看，这是目前唯一可用的机制，因为 Parse 现已关闭，但我认为当问题被问到时仍然可能会出现......无论如何......)。我看到有 2 个解决方案可以以相当干净的方式解决这个问题，假设可以对一般模式/架构进行这些更改。

1)第一个解决方案是重新架构数据集，本质上是“外键”支持者子集，每个 User 在 User 表本身中都有。这样，从理论上讲，您可以执行 Cause->Supporter->User，而不是从 Cause->Supporter code>->User(从用户那里，默认情况下您会得到他们的支持者，因为它是那里的一个专栏)。要在 Parse 中执行此操作，如果我没记错的话，您可以将列设置为具有特定类型的数组作为其值，然后具有 object 链接(在 Parse 仪表板中很好地显示)是实际的 Supporter 表对象，但在您的 User 表中维护此表的链接列。

虽然在write 方面需要做更多的工作，因为您必须手动执行此操作(我所说的手动是指write自己编写代码来执行此操作，它应该是自动化的，但就开发而言它不会免费发生)。通过这个稍微更前期的 write 操作，您可以进行 2 步 read 而不是 3 步。

2) 如果查询速度有问题，第二种解决方案是为此类数据使用不同的提供程序。在我的几个项目中，我使用基于套接字的方法来进行这种数据查询查找，并认为 Pusher 或 Firebase (两种非常不同的“包容性”级别， Firebase 更像是 Parse，但这次来自 Google， Pusher 有点更基本和“DIY”)。

与 Firebase ，例如，这个数据集的套接字 + 一个模式，其中 Cause 表本身有一个缓存，其中包含 User 属于他们的内容(和其中 User 有他们的 Supporter 的缓存)，这 3 步查找实际上可以是 1 个查询和 2 个参数(我认为这是理想的场景)。我相信这也可以通过 Parse 实现，但是需要对第一个提议的解决方案进行另一步架构重构。

我认为在评论中推荐了与此类似的内容(以上两种解决方案)，但格式更为不详尽。我希望这对最初的提问者或某人有所帮助。理论上，这也可以像有人建议的那样使用 PubNub 如 1 条评论所述，但它可以轻松地将此模式构建到托管在 AWS 或 Heroku 上的 PostgreSQL 数据库中 并在没有开销的情况下完成与 Parse 完全相同的机制。

此外，由于这是对现在仅作为开源自托管解决方案提供的 Parse 的引用，因此这里有一个迁移到在 AWS 上自行托管 Parse 的指南:link here