在代理商处选择新的无服务器数据库技术（案例研究）

本文得到了我们在 Fauna 的亲爱的朋友的大力支持，他们使每个软件开发团队都可以高效、可扩展且安全地处理运营数据。 谢谢！

对于担任领导职务的技术人员来说，采用新技术是最艰难的决定之一。 无论您是为其他组织还是在您自己的组织内构建软件，这通常是一个巨大且令人不安的风险领域。

在过去的 12 年里，作为一名软件工程师，我发现自己不得不以越来越高的频率评估一项新技术。 这可能是下一个前端框架、一种新语言，甚至是像无服务器这样的全新架构。

实验阶段通常是有趣和令人兴奋的。 这是软件工程师最在家的地方，在探索新概念的同时，拥抱“啊哈”时刻的新奇和兴奋。 作为工程师，我们喜欢思考和修补，但有了足够的经验，每个工程师都知道，即​​使是最令人难以置信的技术也有其缺陷。 你只是还没有找到它们。

现在，作为创意机构的联合创始人，我和我的团队经常处于使用新技术的独特位置。 我们看到许多新建项目，这成为引入新事物的绝佳机会。 这些项目还与较大的组织存在一定程度的技术隔离，并且通常较少受到先前决策的负担。

话虽如此，一位优秀的机构负责人受托照顾别人的大创意并将其传递给全世界。 我们必须比我们自己的项目更加小心地对待它。 每当我即将对一项新技术做出最后决定时，我经常会思考联合创始人 Stack Overflow Joel Spolski 的这条智慧：

“在你真正知道它足够好或意识到无论你多么努力你都不能......之前，你必须用一两年的时间流汗和流血

这就是恐惧，这是任何技术主管都不想置身其中的地方。为现实世界的项目选择新技术已经够难了，但作为代理机构，你必须与其他人的项目、某人的项目一起做出这些决定别人的梦想，别人的钱。 在代理机构，您最不想要的就是在项目的最后期限附近找到其中一个瑕疵。 紧迫的时间表和预算使得在超过某个阈值后几乎不可能逆转，因此发现一项技术不能做一些关键的事情或在项目中太晚不可靠可能是灾难性的。

在我作为软件工程师的整个职业生涯中，我曾在 SaaS 公司和创意机构工作过。 在为项目采用新技术时，这两种环境具有非常不同的标准。 标准有重叠，但总的来说，机构环境必须在严格的预算和严格的时间限制下工作。 虽然我们希望我们构建的产品随着时间的推移而老化，但通常更难以对不太成熟的产品进行投资或采用具有更陡峭的学习曲线和粗糙边缘的技术。

话虽如此，机构也有一些单一组织可能没有的独特限制。 我们必须偏向于效率和稳定性。 计费时间通常是项目完成后的最终计量单位。 我曾在 SaaS 公司工作过，在这些公司中花一两天时间进行设置或构建管道没什么大不了的。

在代理机构，这种类型的时间成本会给关系带来压力，因为财务团队看到利润率正在缩小，几乎没有可见的结果。 我们还必须考虑项目的长期维护，反之，如果项目需要交还给客户会发生什么。 因此，我们必须偏向于我们选择的技术的效率、学习曲线和稳定性。

在评估一项新技术时，我会关注三个总体领域：

1. 技术
2. 开发者体验
3. 这生意

在我开始真正深入研究代码和进行实验之前，这些领域中的每一个都有我喜欢满足的一组标准。 在本文中，我们将了解这些标准，并使用为项目考虑新数据库的示例，并在每个镜头下从高层次上对其进行审查。 做出这样一个切实的决定将有助于展示我们如何在现实世界中应用这个框架。

技术

在评估一项新技术时，首先要看的是该解决方案是否可以解决它声称要解决的问题。 在深入研究一项技术如何帮助我们的流程和业务运营之前，重要的是首先确定它是否满足我们的功能需求。 这也是我想看看我们正在使用哪些现有解决方案以及这个新解决方案如何与它们相抗衡的地方。

我会问自己这样的问题：

1. 它至少能解决我现有解决方案的问题吗？
2. 这个解决方案在哪些方面更好？
3. 在哪些方面更糟？
4. 对于更糟糕的领域，如何克服这些缺点？
5. 它会取代多种工具吗？
6. 技术有多稳定？

我们的为什么？

在这一点上，我还想回顾一下我们为什么要寻求另一种解决方案。 一个简单的答案是我们遇到了现有解决方案无法解决的问题。 然而，这种情况通常很少发生。 多年来，我们利用我们今天拥有的所有技术解决了许多软件问题。 通常发生的情况是，我们转向一项新技术，使我们目前正在做的事情变得更容易、更稳定、更快或更便宜。

让我们以 React 为例。 当 jQuery 或 Vanilla JavaScript 做这项工作时，为什么我们决定采用 React？ 在这种情况下，使用该框架强调了这是处理有状态前端的更好方法。 通过使用数据结构而不是直接的 DOM 操作，我们可以更快地构建过滤和排序功能。 这节省了时间并提高了我们解决方案的稳定性。

Typescript是我们决定采用它的另一个例子，因为我们发现代码的稳定性和可维护性有所提高。 在采用新技术时，我们通常不会寻求解决一个明确的问题，而只是希望保持最新状态，然后发现比我们目前使用的更有效和更稳定的解决方案。

对于数据库，我们特别考虑迁移到无服务器选项。 我们在无服务器应用程序和部署方面取得了很多成功，减少了我们作为一个组织的开销。 我们认为缺乏这一点的一个领域是我们的数据层。 我们看到像 Amazon Aurora、Fauna、Cosmos 和 Firebase 这样的服务正在将无服务器原则应用于数据库，并想看看是否是时候自己迈出这一步了。 在这种情况下，我们希望降低运营开销并提高开发速度和效率。

在您开始涉足新产品之前，了解您的原因很重要。 这可能是因为您正在解决一个新问题，但更多时候您希望提高自己解决已经解决的问题的能力。 在这种情况下，您需要盘点您去过的地方，以确定哪些内容可以为您的工作流程提供有意义的改进。 基于我们查看无服务器数据库的示例，我们需要看看我们目前如何解决问题以及这些解决方案的不足之处。

我们去过的地方……

作为代理商，我们之前使用过的数据库范围很广，包括但不限于 MySQL、PostgreSQL、MongoDB、DynamoDB、BigQuery 和 Firebase Cloud Storage。 不过，我们的绝大多数工作都围绕三个核心数据库：PostgreSQL、MongoDB 和 Firebase 实时数据库。 事实上，它们中的每一个都具有半无服务器产品，但新产品的一些关键特性让我们重新评估了之前的假设。 让我们先来看看我们在这些方面的历史经验，以及为什么我们首先要考虑替代方案。

我们通常为大型、长期项目选择PostgreSQL ，因为这是几乎所有事物都经过实战考验的黄金标准。 它支持经典事务、规范化数据，并且符合 ACID。 几乎每种语言都有大量可用的工具和 ORM，它甚至可以用作具有 JSON 列支持的临时 NoSQL 数据库。 它与许多现有的框架、库和编程语言很好地集成，使其成为真正的随处可用的主力。 它也是开源的，因此不会让我们锁定任何一个供应商。 正如他们所说，没有人会因为选择 Postgres 而被解雇。

话虽如此，我们逐渐发现自己使用 PostgreSQL 的次数越来越少，因为我们变得更像是一个面向节点的商店。 我们发现 Node 的 ORM 乏善可陈，需要更多的自定义查询（尽管现在这已变得不那么成问题了），而在 JavaScript 或 TypeScript 运行时工作时，NoSQL 感觉更自然。 话虽如此，我们经常有一些项目可以通过电子商务工作流等经典关系模型快速完成。 然而，处理数据库的本地设置、统一跨团队的测试流程以及处理本地迁移是我们不喜欢的事情，并且很高兴随着 NoSQL、基于云的数据库变得越来越流行而放弃这些事情。

随着我们采用 Node.js 作为首选后端， MongoDB越来越成为我们的首选数据库。 使用 MongoDB Atlas 可以轻松快速地开发和测试我们团队可以使用的数据库。 有一段时间，MongoDB 不符合 ACID，不支持事务，并且不鼓励太多类似内部连接的操作，因此对于电子商务应用程序，我们仍然最常使用 Postgres。 话虽如此，有大量的库与之配套，Mongo 的查询语言和一流的 JSON 支持为我们提供了关系数据库所没有的速度和效率。 MongoDB 最近增加了对 ACID 事务的支持，但长期以来，这是我们选择 Postgres 的主要原因。

MongoDB 还向我们介绍了新的灵活性水平。 在代理项目的中间，需求必然会发生变化。 无论您多么努力地防御它，总会有最后一刻的数据要求。 一般来说，对于 NoSQL 数据库，数据结构的灵活性使这些类型的更改不那么苛刻。 我们最终没有得到一个装满迁移文件的文件夹来管理添加和删除以及在项目出现之前再次添加的列。

作为一项服务，Mongo Atlas 也非常接近我们在数据库云服务中所期望的。 我喜欢将 Atlas 视为一种半无服务器产品，因为您在管理它时仍有一些运营开销。 您必须预先配置一定大小的数据库并选择一定数量的内存。 这些东西不会自动为您扩展，因此您需要监控它何时需要提供更多空间或内存。 在真正的无服务器数据库中，这一切都将自动和按需发生。

我们还在几个项目中使用了 Firebase 实时数据库。 这确实是一种无服务器产品，其中数据库可按需扩展和缩减，并且采用按需付费定价，这对于预先不知道规模且预算有限的应用程序是有意义的。 我们使用它而不是 MongoDB 来处理具有简单数据需求的短期项目。

我们不喜欢 Firebase 的一件事是，它感觉与我们习惯的围绕规范化数据构建的典型关系模型相去甚远。 保持数据结构平坦意味着我们经常有更多的重复，随着项目的增长，这可能会变得有点难看。 您最终不得不在多个位置更新相同的数据或尝试将不同的引用连接在一起，从而导致多个查询变得难以在代码中进行推理。 虽然我们喜欢 Firebase，但我们从未真正爱上查询语言，有时发现文档乏善可陈。

一般来说，MongoDB 和 Firebase 都对非规范化数据有相似的关注，并且由于无法访问高效的事务，我们经常发现许多工作流很容易在关系数据库中建模，这导致应用层的代码更加复杂，它们的NoSQL 对应物。 如果我们能够获得这些 NoSQL 产品的灵活性和易用性以及传统 SQL 数据库的健壮性和关系建模，我们真的会找到一个很好的匹配项。 我们认为 MongoDB 具有更好的 API 和功能，但 Firebase 在操作上拥有真正的无服务器模型。

我们的理想

在这一点上，我们可以开始考虑我们将考虑哪些新选项。 我们已经清楚地定义了我们以前的解决方案，并且我们已经确定了对我们来说重要的事情，至少要在我们的新解决方案中拥有。 我们不仅有一个基线或最低要求集，而且我们还有一系列问题，我们希望新的解决方案能够为我们缓解。 以下是我们的技术要求：

1. 可按需扩展的无服务器操作
2. 灵活建模（无模式）
3. 不依赖迁移或 ORM
4. 符合 ACID 的事务
5. 支持关系和规范化数据
6. 适用于无服务器和传统后端

所以现在我们有了一份必备品清单，我们实际上可以评估一些选项。 新的解决方案在这里钉住每一个目标可能并不重要。 可能只是它在现有解决方案不重叠的情况下达到了正确的功能组合。 例如，如果你想要无模式的灵活性，你必须放弃 ACID 事务。 （长期以来，数据库就是这种情况。）

另一个领域的一个例子是，如果你想在模板渲染中进行打字稿验证，你需要使用 TSX 和 React。 如果您使用 Svelte 或 Vue 之类的选项，您可以通过模板渲染获得它——部分但不是全部。 因此，即使缺少其他功能，使用 React 和 TypeScript 的模板级别类型检查为您提供 Svelte 的微小占用空间和速度的解决方案也足以被采用。 项目之间的平衡、需求和需求将发生变化。 由您决定价值将在哪里，并决定如何勾选分析中最重要的点。

我们现在可以查看一个解决方案，看看它如何根据我们想要的解决方案进行评估。 Fauna是一种无服务器数据库解决方案，拥有全球分布的按需规模。 它是一个无模式数据库，提供符合 ACID 的事务，并支持关系查询和规范化数据作为一项功能。 Fauna 可用于无服务器应用程序以及更传统的后端，并提供与最流行语言一起使用的库。 Fauna 还提供身份验证工作流程以及简单高效的多租户。 这些都是需要注意的可靠附加功能，因为当两种技术在我们的评估中并驾齐驱时，它们可能是影响因素。

现在，在查看了所有这些优势之后，我们必须评估劣势。 其中之一是 Fauna 不是开源的。 这确实意味着存在供应商锁定的风险，或者您无法控制的业务和定价变化。 开源可能很好，因为如果您愿意或可能回馈项目，您可以经常将技术提供给另一个供应商。

在代理世界中，供应商锁定是我们必须密切关注的事情，与其说是因为价格，不如说是因为基础业务的可行性。 必须更改处于开发中期或几年前的项目的数据库对于代理机构来说都是灾难性的。 通常，客户必须为此买单，这不是一次愉快的谈话。

我们关注的另一个弱点是对JAMstack的关注。 虽然我们喜欢 JAMstack，但我们发现自己构建各种传统 Web 应用程序的频率更高。 我们希望确保 Fauna 继续支持这些用例。 过去，我们与一家托管服务提供商的经历很糟糕，该提供商全力投入 JAMstack，我们最终不得不从该服务中迁移相当多的网站，因此我们希望对所有用例都将继续看到充满信心坚实的支持。 目前，情况似乎如此，Fauna 提供的无服务器工作流实际上可以很好地补充更传统的应用程序。

在这一点上，我们已经完成了我们的功能研究，并且知道这个解决方案是否可行的唯一方法是开始编写一些代码。 在代理环境中，我们不能只花几周的时间让人们评估多种解决方案。 这是在代理机构与 SaaS 环境中工作的本质。 在后者中，您可能会构建一些原型来尝试找到正确的解决方案。 在代理商中，您将有几天的时间进行试验，或者可能有机会做一个附带项目，但总的来说，在这个阶段我们确实必须将其缩小到一两种技术，然后将手指放在键盘上。

开发者体验

判断新技术的体验方面可能是三个领域中最困难的，因为它本质上是主观的。 它也会因团队而异。 例如，如果你问一个 Ruby 程序员、一个 Python 程序员和一个 Rust 程序员他们对不同语言特性的看法，你会得到相当多的回答。 因此，在您开始判断体验之前，您必须首先确定哪些特征对您的团队整体而言最重要。

对于代理商，我认为在开发人员体验方面存在两个主要瓶颈：

1. 设置时间和配置
2. 易学性

这两者都以不同的方式影响新技术的长期可行性。 在代理机构中让临时的开发人员团队保持同步可能是一件令人头疼的事情。 众所周知，具有大量前期设置成本和配置的工具很难让代理商使用。 另一个是可学习性以及开发人员开发新技术的难易程度。 在开始评估开发人员体验时，我们将更详细地讨论这些内容以及为什么它们是我的基础。

设置时间和配置

代理商往往没有足够的耐心和时间进行配置。 对我来说，我喜欢锋利的工具，采用符合人体工程学的设计，让我能够快速解决手头的业务问题。 几年前，我曾在一家 SaaS 公司工作，该公司有一个复杂的本地设置，涉及许多配置，并且经常在设置过程中的随机点失败。 设置好之后，传统观念是不要碰任何东西，并希望你在公司的时间不够长，以至于不得不在另一台机器上重新设置它。 我遇到过非常喜欢配置他们的 emacs 设置的每一小部分的开发人员，并且没有想到会在一个破碎的本地环境中浪费几个小时。

总的来说，我发现代理工程师在日常工作中对这些类型的事情不屑一顾。 在家里，他们可能会修补这些类型的工具，但在截止日期前，没有什么能像工具一样正常工作。 在代理机构，我们通常更愿意学习一些效果良好、始终如一的新事物，而不是能够根据每个人的个人品味来配置每项技术。

使用非开源云平台的好处是他们完全拥有设置和配置。 虽然这样做的缺点是供应商锁定，但好处是这些类型的工具通常会做他们设置好的事情。 无需修补环境，无需本地设置，也无需部署管道。 我们要做的决定也更少。

这本质上就是无服务器的吸引力。 总的来说，无服务器对专有服务和工具的依赖程度更高。 我们交换托管和源代码的灵活性，以便我们可以获得更大的稳定性并专注于我们试图解决的业务领域的问题。 我还要指出，当我在评估一项技术时，我觉得可能需要从平台迁移，这通常在一开始就不是一个好兆头。

在数据库的情况下，当与数据库需求可能不明确的客户合作时，设置即忘记设置是理想的。 我们的客户不确定某个程序或应用程序的受欢迎程度。 我们有一些客户在技术上没有签约以这种方式提供支持，但当他们需要我们扩展他们的数据库或应用程序时，他们还是惊慌失措地打电话给我们。

过去，我们在制作 SOW 时总是必须考虑冗余、数据复制和分片以扩展等因素。 试图涵盖每个场景，同时还准备在数据库无法扩展的情况下移动一整本业务书，这是不可能准备的情况。 最后，无服务器数据库使这些事情变得更容易。

您永远不会丢失数据，您不必担心跨网络复制数据，也不必配置更大的数据库和机器来运行它——这一切都可以正常工作。 我们只关注手头的业务问题，技术架构和规模将始终得到管理。 对于我们的开发团队来说，这是一个巨大的胜利； 我们的消防演习、监控和上下文切换更少。

易学性

有一个经典的用户体验衡量标准，我认为它适用于开发者体验，那就是易学性。 在为某种用户体验进行设计时，我们不只是看第一次尝试是否明显或容易。 技术只是比大多数时候更复杂。 重要的是新用户学习和掌握系统的难易程度。

谈到技术工具，尤其是功能强大的工具时，要求零学习曲线是很重要的。 通常我们寻找的是最常见的用例有很好的文档，并且在项目中可以轻松快速地构建这些知识。 浪费一点时间来学习第一个技术项目是可以的。 在那之后，我们应该看到每个后续项目的效率都会提高。

我在这里特别寻找的是我们如何利用我们已经知道的知识和模式来帮助缩短学习曲线。 例如，对于无服务器数据库，在云中设置和部署它们的学习曲线几乎为零。 当谈到使用数据库时，我喜欢的一件事是当我们仍然可以利用多年来掌握关系数据库并将这些学习应用到我们的新设置时。 在这种情况下，我们正在学习如何使用新工具，但这并没有迫使我们从头开始重新考虑我们的数据建模。

例如，在使用 Firebase、MongoDB 和 DynamoDB 时，我们发现它鼓励非规范化数据，而不是尝试连接不同的文档。 这在对我们的数据进行建模时产生了很多认知摩擦，因为我们需要根据访问模式而不是业务实体进行思考。 在这个动物群的另一边，我们可以利用我们多年的关系知识以及我们在建模数据时对规范化数据的偏好。

我们必须习惯的部分是使用索引和新的查询语言将这些部分组合在一起。 总的来说，我发现保留作为更大软件设计范式一部分的概念可以使开发团队在可学习性和采用方面更容易。

我们如何知道一个团队正在采用和喜爱一项新技术？ 我认为最好的迹象是当我们发现自己在问该工具是否与上述新技术集成时？ 当一项新技术达到了团队正在寻找将其纳入更多项目的方法的渴望和享受的水平时，这是一个好兆头，你有一个赢家。

这生意

在本节中，我们必须了解一项新技术如何满足我们的业务需求。 这些问题包括：

• 它的定价和集成到我们的支持计划中有多容易？
• 我们可以轻松地将其转移给客户吗？
• 如果需要，客户可以使用此工具吗？
• 如果有的话，这个工具实际上可以节省多少时间？

无服务器作为一种范式的兴起非常适合代理机构。 当我们谈论数据库和 DevOps 时，机构对这些领域专家的需求是有限的。 通常，当我们完成一个项目或以有限的能力长期支持它时，我们会移交一个项目。 我们倾向于偏向全栈工程师，因为这些需求在很大程度上超过了 DevOps 的需求。 如果我们聘请了 DevOps 工程师，他们可能会花费几个小时来部署一个项目，并花费更多的时间等待着火。

在这方面，我们总是准备好一些DevOps 承包商，但不会全职为这些职位配备人员。 这意味着我们不能依赖 DevOps 工程师准备好应对意外问题。 对于我们来说，我们知道通过直接访问 AWS 可以获得更好的托管费率，但我们也知道通过使用 Heroku，我们可以依靠我们现有的员工来调试大多数问题。 除非我们有需要长期支持特定后端需求的客户端，否则我们喜欢默认托管平台即服务。

数据库也不例外。 我们喜欢依靠像 Mongo Atlas 或 Heroku Postgres 这样的服务来使这个过程尽可能简单。 随着我们开始看到越来越多的堆栈转向 Vercel、Netlify 或 AWS Lambda 等无服务器工具，我们的数据库需求必须随之发展。 Firebase、DynamoDB 和 Fauna 等无服务器数据库非常棒，因为它们与无服务器应用程序集成得很好，而且还让我们的业务完全免于配置和扩展。

这些解决方案也适用于更传统的应用程序，我们没有无服务器应用程序，但我们仍然可以在数据库级别利用无服务器效率。 作为一家企业，我们学习一个可以同时适用于两个世界的数据库比上下文切换更有效率。 这类似于我们决定采用 Node 和同构 JavaScript（和 TypeScript）。

我们发现无服务器的缺点之一是为我们管理这些服务的客户定价。 在更传统的架构中，统一费率等级可以很容易地将这些费率转换为客户的费率，这些客户在可预测的情况下会发生增加和超额。 当谈到无服务器时，这可能是模棱两可的。 财务人员通常不喜欢听到我们每阅读超过 100 万次就收取 1/10 美分的费用，等等。

即使对于工程师来说，这也很难转化为一个固定的数字，因为我们经常构建不确定用途的应用程序。 我们经常必须自己创建层，但是 lambda 成本计算中的许多变量可能很难让您理解。 最终，对于 SaaS 产品来说，这些现收现付定价模型非常棒，但对于代理机构来说，会计师喜欢更具体和可预测的数字。

对于 Fauna，这肯定比说一个标准的 MySQL 数据库更加模糊，该数据库在一定数量的空间中具有固定费率的托管。 好处是 Fauna 提供了一个很好的计算器，我们可以用它来组合我们自己的定价方案。

无服务器的另一个困难方面可能是这些提供商中的许多都不允许轻松分解托管的每个应用程序。 例如，Heroku 平台通过创建新的管道和团队使这变得非常容易。 如果他们不想使用我们的托管计划，我们甚至可以为他们输入客户的信用卡。 这也可以在同一个仪表板中完成，因此我们不需要创建多个登录。

当涉及到其他无服务器工具时，这要困难得多。 在评估无服务器数据库时，Firebase 支持按项目拆分付款。 在 Fauna 或 DynamoDB 的情况下，这是不可能的，所以我们必须做一些工作来监控他们仪表板中的使用情况，如果客户想离开我们的服务，我们必须将数据库转移到他们自己的帐户。

最终，无服务器工具在成本节约、管理和流程效率方面提供了巨大的商机。 然而，在定价和账户管理方面，它们通常确实对代理商具有挑战性。 这是我们不得不利用成本计算器来创建我们自己的可预测定价层或使用他们自己的账户设置客户以便他们可以直接付款的一个领域。

结论

作为代理机构采用新技术可能是一项艰巨的任务。 虽然我们在与有新技术机会的新的、未开发的项目合作方面处于独特的地位，但我们还必须考虑这些项目的长期投资。 他们将如何表现？ 我们的员工会高效并喜欢使用它们吗？ 我们可以将它们纳入我们的业务产品吗？

You need to have a firm grasp of where you have been before you figure out where you want to go technologically. When evaluating a new tool or platform it's important to think of what you have tried in the past and figure out what is most important to you and your team. We took a look at the concept of a serverless database and passed it through our three lenses – the technology, the experience, and the business. We were left with some pros and cons and had to strike the right balance.

After we evaluated serverless databases, we decided to adopt Fauna over the alternatives. We felt the technology was robust and ticked all of our boxes for our technology filter. When it came to the experience, virtually zero configuration and being able to leverage our existing knowledge of relational data modeling made this a winner with the development team. On the business side serverless provides clear wins to efficiency and productivity , however on the pricing side and account management there are still some difficulties. We decided the benefits in the other areas outweighed the pricing difficulties.

Overall, we highly recommend giving Fauna a shot on one of your next projects. It has become one of our favorite tools and our go-to database of choice for smaller serverless projects and even more traditional large backend applications. The community is very helpful, the learning curve is gentle, and we believe you'll find levels of productivity you hadn't realized before with existing databases.

When we first use a new technology on a project, we start with something either internal or on the smaller side. We try to mitigate the risk by wading into the water rather than leaping into the deep end by trying it on a large and complex project. As the team builds understanding of the technology, we start using it for larger projects but only after we feel comfortable that it has handled similar use cases well for us in the past.

In general, it can take up to a year for a technology to become a ubiquitous part of most projects so it is important to be patient. Agencies have a lot of flexibility but also are required to ensure stability in the products they produce, we don't get a second chance. Always be experimenting and pushing your agency to adopt new technologies, but do so carefully and you will reap the benefits.

延伸阅读

• Serverless Database Wishlist - What's Missing Today
• Relational NoSQL: Yes, that is an option
• Concerning toolkits - A great piece about the merits of zero configuration on developer experience