在 Typescript 应用程序中管理生成的 graphql 模式的最佳实践

Posted 2023-03-10

【中文标题】在 Typescript 应用程序中管理生成的 graphql 模式的最佳实践

【英文标题】：Best practices on managing a generated graphql schema in Typescript applications

【发布时间】：2021-10-12 18:57:24

【问题描述】：

我在制定管理生成的 graphql 文件的最佳策略时遇到了一些问题。我遇到的问题是我们有一个开发操作管道，它使用 docker 构建两个容器，一个容器基于第一个构建模式。

这两个容器是 Hasura 数据库和 express 服务器（在 Typescript 中）。

快速服务器使用 hasura 数据库生成模式并使用此类型检查查询/突变。

为了管理生成的架构，我尝试了以下解决方案。

当 express server 内置在 docker 中时，它有一个重试功能来不断从 hasura 数据库中获取 schema。开发人员很快告诉我，在两个容器之间建立依赖关系是一个糟糕的主意（尽管我真的不明白为什么它们之间存在合法的依赖关系）。 在没有 graphql 架构的情况下在 express 服务器中编译打字稿，忽略由此产生的错误。 typescript 代码被编译为 javascript 并在运行时使用，因此类型检查只是用于静态测试的工具。这有效，正确编译了 Javascript。但是，作为打字稿编译器的 docker 错误会引发错误。我不知道如何让它静音。 将生成的架构上传到 GitHub。据我了解，当您上传生成的文件时，这是一个危险信号，应该避免。当我想在本地处理稍微不同的架构（比如未发布的架构）以及管理潜在的合并冲突时，我可以预见到这会导致头痛。

我的直觉是解决方案 1 是正确的。我的docker知识非常有限，那么有没有正确的方法来使用docker来实现呢？还是其他解决方案之一更合适？目前，该团队已经实施了解决方案 3。

非常感谢任何帮助提示！

【参考方案1】：

我会选择选项 #3。将生成的代码提交到源存储库并不总是不鼓励的，有时是正确的做法。例如，考虑依赖锁文件（package-lock.json、yarn.lock）。

生成的架构代表开发时的快照，这是您的应用程序所期望的合同。我不希望在 CI 时生成它，因为在开发依赖于模式的应用程序客户端代码时必须知道它。更新架构应该是在开发应用程序时有意识地做出的决定，而不是在 CI/CD 管道期间偶然发生。