阅读 10716

我是如何在 72 小时内复刻 ClubHouse 的

大家好,我是白宦成(@bestony),前几天在 B 站直播写 ClubHouse 复刻版的开发者。当然,除了这个身份,在真实生活中,我还是 Linux 中国开源社区的技术负责人,负责开发我们自己的自用工具和平台。

作为一个 indiehacker(自诩的),我想和大家一起来复盘一下,这一次的直播活动和意料之外的爆火。

为什么要做 NESHouse

我其实想到复刻 ClubHouse 的时间是非常早的,我是在 2 月 1 日拿到了 ClubHouse 的邀请码,在试玩了一段时间以后,就觉得这个软件还不错,理念很有意思,但并没有太在意,放在了一边。可到了晚上,因为知道 Elon Musk 要来做分享,作为一个比较欣赏他的人,我自然不能错过,但遗憾的是,当我打开 ClubHouse 的时候,已经有太多的人涌入这个 App,几乎无法使用,总是不停的卡顿。

这时让我产生了怀疑:这个东西到底有多少的工作量?为什么这么容易性能卡顿?

结合实际的使用发现,有些时候,我可以正常聊天,但是却会报错,可以发现问题不在语音服务,而是在 ClubHouse 自身的业务能力不足以支撑超过预期的访问量

我上一份工作是在一家云计算企业工作,所以相对来说,对云计算产品有一定的了解。在我看来,这样的一个产品的增量,很难把现有的云计算产品的服务容量打穿,你能想象 ClubHouse 把 AWS、GCP、Azure 等云服务厂商打穿么?

我觉得,要么是开发者的大规模服务的架构经验不足,虽然用了云,但是没设计好,无法充分适应弹性;要么是开发者没有对超过预判的访问量做的预案不足。

这就让我思考,我能否复刻一个 ClubHouse?用一些更加具有弹性的服务?给大家打个样? 云计算是好,但用起来也要姿势对,才能不出问题。

72 小时复刻一个 ClubHouse,是一个什么概念?

既然要复刻项目,自然要做的不能和碰瓷的一样(这里鄙视几家碰瓷的 App,拿很久之前写的具备了语音聊天的 App,来碰瓷 ClubHouse)。

但我又不希望在这个事情上花费太多的事情,我还有很多更重要的事情要做,所以我选择了 72 小时。48 小时或 24 小时是一般的 Hackthon 的时间长度,但我确实又不熟悉这个项目,所以用 72 小时比较稳妥。

于是便立了一个 Flag ,说我要在 72 小时内,复刻一个 ClubHouse。立了个 Flag,说干就干。关于这 72 小时,我希望可以强调两点,也希望这两点能够帮助到你。

1. 明确自己要做的和不要做的

我的时间和精力以及资源都有限,所以并不是什么东西我都能要的。比如在做复刻的时候,考虑到我如果开发原生的 App 或者小程序,就需要提交审核。那我就不能选择做 App,不然 72 小时到了,审核还没过,就食言了。也是出于审核的考虑,我最终选择了使用 Web 的方式来开发 NESHouse

而到了具体的功能特性层面,受限于 Web 和 App 的机制不同,我很难要求用户必须做什么样的操作,也很难确保 App 响应什么样的功能,因此,我对于 ClubHouse 的功能进行了一些删减,邀请上台之类的功能,我就选择性的先不做,将重点放在更加重要的功能中。

在开发黑客松项目的时候,一定要先想清楚自己要什么,不要什么,这样才能确保自己在给定的时间内完成自己的工作。不然大概率会发现时间马上要截止,但核心功能还没有研发完成。

2. 选择一些新的、以后可能会用到的技术

在这次项目开发的时候,我选择的前端技术栈并非我过去惯用的 React、Vue ,而是一个相对小众 JS 框架的 Alpine.js。

选择 Alpine.js 的原因很简单,我后续需要在其它的项目上使用这个框架,但我此刻确实也不熟悉。如果我在这 72 小时里把这个工具用了一遍,如果评估觉得不错,我就可以在后续的项目中使用,如果这次我用的不太好,那我损失的也只有 72 小时,比在正式项目中使用的损失成本要低很多

而在另外的两个服务,选择起来就简单多了:

  • LeanCloud 的云服务我使用了很多年,使用体验也很不错,而且他们这种 Serverless 云服务,可以让我在开发 NESHouse 的时候,免于去写很重的部署和基础逻辑,更加专注在业务逻辑上。
  • 音频服务我则选择了国内用户比较多,开发起来也比较方面的声网,声网的 API 比较简单, NESHouse 中的声网音频接入只用 4 行代码就实现了。

除此之外,便是使用了 NES.css 这样的 CSS 框架,来让这个项目更加的有趣,更加的 Funny。

对于开发黑客松项目的时候,可以想想自己能否接受这一次的失败,如果可以接受自己的失败,不妨将这次黑客松看做是一次玩的机会,玩一玩新的技术,就算失败了,也不过是损失给定的时间。但如果你在工作项目中出现了问题,损失可就大了。

总结

72 个小时的复刻对于我来说不算难,实际上我也只花了 55 个小时就复刻成功了。但更难的,是如何让一个开源项目持续的成长下去,持续的获得用户、获得关注。

最后,在掘金发文章,给自己的项目求个 Star 不过分吧(

项目求 Star:github.com/bestony/nes…

文章分类
前端