如何使GraphQl和DynamoDB一起效果很好

无服务器体系结构，GraphQL API和DynamoDB数据库形成了网站开发的强大组合。虽然无服务器和GraphQl广泛流行，但DynamoDB通常被误解或避免，有时被错误地被视为在大规模尺度上仅有益。

最初，我分享了这种误解，更喜欢我的无服务器项目的SQL数据库。但是，在获得DynamoDB的经验之后，我发现了各种项目规模的优势。为了说明，让我们从头开始构建样本API，绕过复杂的ORMS或GraphQl框架以揭示基础机制。这种动手方法可能会改变您对DynamoDB价值的看法。

解决共同的问题

DynamoDB采用的主要障碍是其陡峭的学习曲线，尽管其功能很少有争议。尽管学习曲线很重要，但SQL数据库并不是无服务器应用程序的理想选择。在无服务器环境中部署和管理SQL数据库连接的挑战是重大的。 DynamoDB本质上是无服务器友好的，可以通过减轻未来扩展的复杂性来提供长期优势。最初对学习DynamoDB的投资最终可以节省大量的未来头痛。

配对GraphQL与DynamoDB的适合性更为复杂。现有的GraphQL文档，教程和示例中的大部分都假设了关系数据库。即使是DynamoDB专家，也是“ DynamoDB书”的作者Alex Debrie，也建议您使用这种组合，这主要是由于将GraphQL解析器作为顺序的，独立的数据库调用的常见实践，导致过多的读取。

另一个潜在的问题是DynamoDB偏爱预定义的访问模式。 GraphQl的强度在于它比休息更容易处理任意查询的能力。对于用户可以制作不可预测的查询的公共API，这变得更加问题。但是，GraphQL经常用于私有API，其中对客户端和服务器的控制允许管理和控制查询模式。如果没有仔细的设计，GraphQl查询就可以轻松地超载任何数据库。

一个简单的数据模型

此示例API将与团队，用户和认证的组织建模。这些关系在下面的实体关系图中描述。每个团队都有多个用户，每个用户都可以拥有多个认证。

关系数据库表示

尽管我们的目标是DynamoDB模型，但SQL数据库表示形式将类似于以下图：（图将在这里，显示表格和关系）

为了处理用户与认证之间的多对多关系，引入了一个名为“凭据”的中介表。到期日期是此表中的唯一属性。为简单起见，省略了其他属性。

访问模式

有效的DynamoDB数据建模取决于了解访问模式。关系数据库以标准化数据开头，并使用加入进行数据检索。 DynamoDB缺乏连接；因此，数据模型必须与预期的访问方法一致。这是一个迭代过程。优先考虑频繁的访问模式。许多人将直接映射到GraphQl查询，而其他则可以内部用于身份验证或授权。频繁的操作（例如，每周行政检查）不需要优化的设计；效率低下的方法（如表扫描）就足够了。

高频访问：

• 用户通过ID或名称
• 由ID或名称的团队
• 用ID或名称认证

频繁访问：

• 团队中的所有用户（按团队ID）
• 用户的所有认证
• 所有团队
• 所有认证

不经常访问：

• 团队中用户的所有认证
• 所有拥有特定认证的用户
• 所有团队中获得认证的用户

DynamoDB单台设计

DynamoDB缺乏连接需要根据主要键或预定义索引进行查询。数据库不强制执行模式，允许单个表中的各种项目类型。最好的做法是将所有项目存储在单个表中，以有效地共同确定的数据访问。下面的模式反映了这种方法，与前面确定的访问模式保持一致。 （架构详细信息将在这里，显示主键，排序键和索引）

主要键是分区密钥（PK）和Sort Key（SK）的复合材料。检索项目需要指定分区密钥以及单一键值或范围。索引（GSI1PK，GSI1SK等）用于灵活访问不同项目类型。 “＃”符号充当了空键的占位符。

数据库架构实现（代码段）

数据库模式在应用程序中执行。 DynamoDB的API功能强大，但复杂。许多开发人员使用ORM来简化。在这里，我们将使用助手功能直接访问数据库来定义团队项目架构。 （db_map的代码段，包括团队的get，put和解析功能，将在这里）

要添加一个新团队，您会致电： DB_MAP.TEAM.put({teamId:"t_01",teamName:"North Team"})

这将生成数据库API的索引和键值。 parse方法将数据库项转换回应用程序模型。

GraphQL模式（代码段）

（类型团队，用户，认证，凭据和查询的类型类型定义定义将在这里。）

将GraphQL和DynamoDB与解析器连接

解析器执行GraphQl查询。解析器对于构建我们的API至关重要。 GraphQL模式中的每个查询都有一个相应的根解析器（此处仅显示团队解析器）。这些解析器返回承诺或包含部分查询结果的对象。

如果查询返回Team类型，则执行将继续使用Team类型解析器。该解析器具有每个Team属性的功能。如果丢失了解析器（例如，对于id ），则检查根解析器是否提供了值。

查询采用四个参数： root （parent对象）， args （查询参数）， context （应用程序数据，包括数据库参考）和info （查询详细信息，在此处未使用）。

下面的解析器使用ctx.db.singletable可访问DynamoDB表。 get和query方法直接与数据库进行交互，并且DB_MAP.TEAM...使用辅助函数转换架构。 parse方法将数据转换为GraphQL架构格式。 （ResolverMap的代码段，包括用于查询的解析器，QUERY.TEAMBYNAME，QUERY.ALLTEAMS，team.name，team.Members.Members，user.name，user.credentials将在这里）

让我们跟踪以下查询的执行：团队根解析器按ID读取团队，返回ID和名称。 Team类型解析器然后检索所有团队成员。 User类型解析器为每个用户获取凭据和认证。每个成员和五个凭证都有七个数据库读取。尽管与SQL数据库（可能是四个呼叫）相比，这似乎看起来过高，但根据各种因素，七个DynamoDB读取可能更快，更便宜。

查询{team（ID：“ T_01”）{
  ID
  姓名
  成员{
    ID
    姓名
    证书{
      ID
      认证{
        ID
        姓名
      }
    }
  }
}}}

过度提取和n 1问题

优化GraphQL API涉及许多权衡。在DynamoDB和SQL之间进行选择时，有两个关键的考虑因素是过度提取的，而N 1问题。这些通常是对立的力量。当解析器要求更多的数据时，就会发生过度提取。当根部或类型的解析器（例如， Team解析器中的members ）试图在单个数据库调用中检索过多的数据时，就会发生这种情况。如果查询没有请求name属性，请检索它是浪费的。

N 1问题恰恰相反。将所有读取到最低级别的解析器都意味着更高级别的数据库请求。代替了一个五个成员的电话，而是进行了五个单独的读数。这可能会导致更多读取。实际上，诸如DataLoader批处理这些请求之类的工具减少了数据库调用的数量。这些较小的原子要求对于有效的批处理至关重要。

对于SQL，通常最好的带有数据加载器的小型低水平解析器是最好的。对于DynamoDB，与单台设计对齐的“更智能”的高级解析器更有效。在这种情况下，过度取得的邪恶通常是较小的邪恶。

部署（摘要）

可以使用Architect快速部署此示例，这是用于在AWS上构建无服务器应用程序的开源工具。 GitHub存储库提供代码。克隆和运行npm install后，可以在本地启动应用程序（包括本地数据库）。在AWS（包括DynamoDB）上的生产部署也很简单。

以上是如何使GraphQl和DynamoDB一起效果很好的详细内容。更多信息请关注PHP中文网其他相关文章！