让我们连接！
让我们连接！
挑战在于：构建一个用户无需交换手机号码、电子邮件地址、照片或任何其他个人身份信息即可相互联系的应用程序。
在为您提供解决该挑战的解决方案之前，我想解释一下我的应用程序的目标。与其创建下一个伟大的社交网络，我想构建一个应用程序，以一种简单而强大的方式增强人们的人际关系。
在 Match U 中，用户只需按 1 到 10 的等级对他们想要的任何东西（电影、餐馆、运动队、电视节目、活动）进行评分。然后当他们亲自见到某人时，他们可以通过应用程序联系并查看他们的匹配方式：他们都喜欢/不喜欢哪些东西？他们的评分相似的事情是什么？它们在哪些方面有很大不同？目标主要是在现实生活中开始一对一的对话。
The Match U home screen
我想让人们能够在不分享他们的电子邮件地址、手机号码或其他身份信息的情况下相互联系，这样如果一个人想要终止一段关系，另一个人将无法访问他们（通过这个无论如何应用程序）。你也不能只搜索一个人的名字——你必须相互同意才能连接。
我首先创建了一个名为contacts 的表，其中每个人都有一个id、一个first_name 和一个last_name。我还创建了一个包含以下字段的匹配表：sender_contact_id、receiver_contact_id、match_code 和 match_confirmed。
假设 John 和 Jane 见面并决定通过应用程序进行连接。 John 可以进入进行匹配屏幕并单击按钮以生成匹配代码。此时，会生成一个由六个字符组成的随机字符串。系统确保代码是唯一的（稍后会详细介绍）。然后它在匹配表中创建一行，其中 John 的 id 作为 sender_contact_id 和唯一的 match_code。 recipient_contact_id 设置为 null，布尔 match_confirmed 字段设置为 false，因为还没有人收到或确认匹配。
The Make a Match screen
The Match code displayed
匹配代码显示在 John 的屏幕上。然后，简转到她应用程序上的“接收匹配”屏幕。约翰将密码读给她听，她输入了密码。系统查询匹配表中存在给定匹配代码的行，recipient_contact_id 仍然为空（因为尚未有人声明此代码），并且 match_confirmed 值为 false。如果找到这样的行，它会在接收者联系人 ID 字段中使用 Jane 的 ID 进行更新，但 match_confirmed 仍然为 false。
Enter the match code on the Receive Match screen
我原本以为这足以建立一个匹配。但我突然想到，当 John 生成一个代码时，它并没有指定这是给 Jane 的。所以一个人（或者更可能是一个机器人）可以通过猜测各种匹配代码来“拦截”匹配，与约翰（或其他用户）匹配，并了解他的名字以及他的好恶。
为了防止这种情况发生，John 现在需要确认 Jane 实际上是应该接收匹配请求的人。为此，系统在匹配表中查询包含 John 的 id 作为 sender_contact_id 的行，receiver_contact_id 字段不为空，并且 match_confirmed 为 false。因为他与 Jane 匹配的行应该符合该描述，所以她的名字将显示在他的待定匹配列表中。她的名字旁边是“确认”或“删除”匹配的按钮。
The pending match screen
如果他删除了匹配，简（或正确猜出匹配代码的机器人）将永远无法了解他的任何信息。但如果他按下“确认”按钮，则该表行的 match_confirmed 将设置为 true。然后比赛将成为正式比赛，两人将能够看到他们的好恶比较。
Top of John and Jane’s Match screen
Middle of John and Jane’s Match screen
那么让我们来谈谈生成match_code的代码。我创建了以下函数来选择一个由六个随机字符组成的字符串：
The function to generate
如您所见，字符是从大写字母和数字列表中选择的。我只选择了大写字母，因为我认为共享一个包含大写字母和小写字母的代码会很烦人。我们从结果变量的空字符串开始。 for 循环迭代 6 次，从列表中选择一个随机字符，并将其添加到结果变量中。
当用户单击 Make a Match 按钮时，它会触发 generateMatchCode 函数，其中一个 post 请求被发送到数据库。因为匹配码必须是唯一的，如果生成的码已经存在于数据库中，响应码就不会ok，函数会递归调用自己。如果代码是唯一的，则将生成该行并执行成功操作。
在开发这部分代码时，我一直在思考这是否是最佳方法的问题。相反，我们是否应该一次从数据库中获取所有现有的匹配代码，生成一个代码，并根据该列表检查它以确保它是唯一的？如果它是唯一的，我们可以将其发布到数据库中。这种方法听起来当然更可取，因为在我开发的版本中，我们反复尝试发布到数据库，直到我们选择一个唯一的代码。我们宁愿在后端处理这个问题，也不愿反复访问数据库。但是，根据从 26 个大写字母和 10 位数字中选出的 6 个字符代码，有 36⁶（超过 20 亿）种可能的代码组合。因此，必须运行 fetch 两次的可能性非常小。而且，即使我们采用另一种方法，我们仍然必须考虑到另一个用户在从数据库中获取代码列表到新的唯一生成了代码。当这个应用有数亿用户同时登录时，我们可能需要稍微调整一下我们的方法（这将是我最少的问题！）
我喜欢这个解决方案，因为它具有很强的安全性，并迫使人们相互交流。这不是我们的目标吗？如果您认为自己有更好的解决方案，请随时分享。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
