无服务器: 我们如何通过跳过一半的工作来引导我们的初创公司

当我启动我的任务管理应用程序Moo.dowith我的联合创始人格兰特·沃特斯 (Grant Watters) 时，我们的目标对我们两个人来说似乎过于雄心勃勃。为了使一切正常，我们需要雇用开发人员来构建后端并管理服务器。为了负担得起，我们将花几个月的时间来获得风险投资资金。然后还需要几个月的时间来雇佣员工并增加他们的数量。所有这些都将在我们开始验证客户是否喜欢该产品之前。

幸运的是，我们在Google Drive实时ApI和Firebase启动时启动了Moo.do right。我们意识到我们可以完全跳过后端，节省大量时间和金钱，并自行引导公司。

无服务器

无服务器是当今web开发的新趋势。这个想法是，您的服务器代码 “在云中” 运行，您不必担心扩展或管理服务器。这是减少构建web应用程序所需工作的好方法。但是，我们更进一步: Moo.do完全是客户端，我们使用免费的外部服务作为后端。

好吧，这实际上是一个谎言。我们确实有一个小型服务器，仅用于较小的用户帐户详细信息，例如设置和计费，仅此而已。

Moo.do是一个电子邮件客户端，待办事项列表，看板和日历，在所有桌面和移动平台上具有实时协作。这是一项艰巨的任务，如果我们必须构建大规模数据存储和实时协作以及web和移动应用程序所需的后端，那将是不可能的。

它是如何工作的

所有用户的私人数据都存储在他的个人Google Drive帐户和Moo.do使用客户端api的一切:

当您启动Moo.do时，整个应用程序将下载并存储在本地应用程序缓存中，以便它可以脱机工作并加快加载时间。它加载存储在IndexedDB中的所有本地数据，然后连接到Google Drive实时ApI以设置实时同步，并与Gmail，Google Calendarand Google Drive ApI同步。最后，它快速ping我们的服务器以确认用户的高级帐户状态。

在典型的web应用程序中，大多数情况会发生在服务器端而不是客户端。做所有客户端可能听起来很疯狂，但我会解释为什么它工作得这么好。

快点开始。

我们在短短几天内就使用Google Drive实时ApI将实时协作添加到我们的初始原型中。这使我们能够快速构建一个有效的产品来证明这个想法。否则，我们将不得不花费大量时间来构建实时协作系统，然后才能验证人们是否喜欢该产品。

省钱。

这些服务和api是免费的，因此我们的运行成本几乎为零。由于我们正在引导公司，因此我们没有多余的钱可浪费，因此较低的成本可以扩展我们的跑道。免费增值商业模式的一个缺点是，免费用户可以提高需要抵消的成本。但是在我们的案例中，免费用户几乎不花费我们。

雇佣更少的人。

我们不需要后端工程师，因为我们没有复杂的后端工程师。而且我们不需要系统管理员，因为我们没有要管理的系统。我们能够将其建立为只有两位创始人，没有员工，也没有风险投资。

工作量较少，因此bug也较少。

为实时同步和协作构建后端将是一项巨大的工作。没人有时间，所以我们跳过了。而且，经过Google充分测试的大量使用的ApI的bug将比我们从头开始编写的代码少。当然，每个ApI或服务都需要一些工作才能适应应用程序。我们有很多客户端集成代码，比如冲突解决来支持离线使用，但其他一切都由谷歌负责。

我们可以无限扩展。

因为我们几乎完全在Google服务上运行后端，所以我们能够以Google规模运行。Moo.do可以在一夜之间获得100万新用户，一切都会好的。我们不需要限制注册，也不需要担心被Reddit的死亡拥抱击倒。

我们的服务器上没有数据或密码。

Moo.do使用Google OAuth登录，这具有巨大的安全优势，即我们永远不会收到用户的实际密码。

所有项目，任务和附件都存储在每个用户的个人Google Drive帐户中。Gmail和Google日历完全在客户端同步，这意味着电子邮件和约会不会通过，也不会存储在我们的服务器上。

不将用户的私人数据存储在我们的服务器上可以保护他们的隐私并限制他们可能遭受黑客攻击。

总之，一切都很好，没有缺点。

好吧，那是另一个谎言。放弃对我们后端的控制确实有一些缺点:

我们依赖谷歌。

众所周知，Google会关闭服务。这存在风险，但公司通常会事先发出警告，并有很长的时间才能迁移出去。它正在对Google云端硬盘进行大量投资，而且我们不会很快看到Gmail消失。对谷歌的依赖是一种风险，但我们相信这些服务会继续存在。

Api中可能存在错误-我们对此无能为力。

总是存在一个新的错误出现的风险，这是我们无法控制的。Google Drive实时ApI在早期就出现了一些问题，但是开发人员响应迅速并修复了错误，并且在过去两年中一直保持稳定。基于稳定性和响应能力的记录，我们感到安全。

静态页面使A/B测试变得困难。

由于Moo.do由CDN而不是服务器提供服务，因此它必须是静态页面。我们不能用初始页面发送用户特定的数据，所以一切都必须通过JavaScript加载。无论如何，离线优先应用程序都可以作为静态页面工作得最好，所以这个约束对我们来说很好。

静态页面对我们来说唯一真正的缺点是，它更难进行a/B测试，因为没有服务器来决定是发送用户A还是B。因此，对于A/B测试，我们必须向用户发送A和B，然后在客户端JavaScript中显示正确的用户。

谷歌驱动实时应用编程接口只有JavaScript。

如果您需要从本机应用程序访问数据，则使用替代解决方案可能会更好。我们可以接受这个限制，因为我们在JavaScript上投入了大量资金-甚至我们的iOS和Android应用程序都是移动web应用程序。