跳过主要内容
故事

__CAPGO_KEEP_0__ 团队添加组织系统的背后故事

capgo 团队添加组织系统的背后故事

无所不包

WcaleNieWolny

内容营销专家

全新组织系统

介绍

嘿,我是 WcaleNieWolny - Capgo 的首席软件工程师。

在过去的 8 个月里,我一直在开发 __CAPGO_KEEP_0__ 的组织系统,并且截至 2024 年 4 月 14 日,我很高兴地宣布该系统已完成 🎉 🎊

在 8 个月后,Capgo 的每个部分都可以供组织成员访问。这包括:

  • 应用
  • 统计数据
  • 账单
  • 全 CLI 支持
  • 还有很多更多的功能!

到达这里并非易事;系统经过了3次重大修订。

组织 v1

起初的步骤并不顺利… 我刚加入项目2周后就开始工作了。 当时我对代码库几乎一无所知,也没有更大的想法来实现这个功能。 这导致我只实现了最hack的解决方案,仅支持访问应用、频道和版本。 甚至不允许被邀请的用户查看统计数据。 然后我等待了Martin的审查,但什么也没发生。3个月后,我决定回到这个问题并解决所有的合并冲突。 我也决定进行测试,结果证明这是一个很好的决定。 毫无意外,hack的解决方案完全失败了。在那一刻,我决定修复所有的bug并编写一个全面的E2E测试。 我不得不与非常破碎的 __CAPGO_KEEP_0__ 和过去的我做出的很多糟糕决定一起工作,但经过2个艰难的周后,我终于让它正常工作了。 这并不意味着它是完美的。组织的拥有者仍然拥有比最高被邀请用户更多的访问权限。用户体验也相当糟糕。被邀请的用户甚至无法查看应用统计数据、管理账单, __CAPGO_KEEP_0__ 仅支持上传。 尽管面临着这些挑战,Martin已经审查了PR,一个星期后它就被推入生产环境中了。

组织 v2

And then I waited for Martin to review this. I waited and waited, but nothing really happened. 3 months later, I decided to come back to this and fix all the merge conflicts. I also decided to test, which turned out to be a great idea. To no surprise, the hacky solution completely failed. At that moment, I decided to fix all bugs and write an extensive E2E test. I had to work with very broken code and a lot of bad decisions made by the past me, but after 2 hard weeks, I finally got it to function.

That does not, however, mean that it was perfect. The owner of the organization still had a lot more access than even the highest invited user. User experience also was quite lacking. The invited user could not even see the application statistics, manage billing, and the CLI was limited to upload only.

Organizations v1

Organizations v2

尽管面临各种挑战,组织系统仍然运作得相当顺利。用户正在使用它,并且它真正推动了整个项目的进展。然而,我仍然需要:

  • 修复在 行级安全性
  • 为整个CLI添加支持
  • 确保管理员用户具有与所有者相同的访问权限

之后 与马丁进行了大量讨论后,我们决定最好的方法是重写整个安全规则,并将所有资源的所有权转移到组织中,而不是用户中。 这将使与新组织系统的集成变得更加容易,并且也将移除大量的遗留__CAPGO_KEEP_0__。 编写新的RLScode非常繁琐,但经过一周半的时间,整个迁移就准备好了。

Writing the new RLS code was very tedious, but after a week and a half, the entire migration was ready.

然而,它并没有… Turns out我破坏了用户注册,新用户无法创建账户 😅

在一通快速的紧急电话后,我迅速推送了一些更改到生产环境,然后就睡觉了。然而,我的更改只会带来更多的问题 😰

之后

我醒来后发现用户有很多空的组织。这不是应该发生的事情,因为每个用户只应该有一个组织。经过一些时间的思考和讨论后,我们成功地移除了所有的重复组织,除了这点之外,其他变化都比较顺利。

组织 v3

即使这样也不是足够的。还缺少一个巨大的组件——计费。

目前只有管理员才能管理计费。这导致了一个有趣的问题:用户购买了一个计划,认为他是在为组织购买的。 我们快速地修复了这个问题,之后我们决定这个问题是不可接受的。

迁移过程相对比较顺利。花了一个星期的时间,但与 V1 和 V2 相比,确实不是那么难以承受 🚀

组织 v4 - 未来

经过了这么多的努力,我想现在是时候专注于其他事情了 😎

这不是容易的,但我学到了很多,capgo 也获得了一个非常棒且重要的功能 我还需要废弃旧的函数、改善 Web 应用用户体验、监控 bug 等,但这个系统应该不会有太大的变化。


感谢您的阅读 🚀

实时更新 Capacitor 应用

当 web 层面的 bug 活动时,通过 Capgo 将修复推送到应用,而不是等待几天的应用商店审批。用户在后台接收更新,而本机更改仍在正常的审批路径中。

立即开始

博客最新文章

Capgo 给您需要创建真正专业的移动应用所需的最佳见解。