创建通过生成的类型使用gRPC和GraphQL的TypeScript API

上面显示的每个层都由自己的模型,转换器和错误组成,其中在父层中执行双向模型转换-允许每个层与消费者无关。 在每层上都有模型表示的决定源于对正确分离关注点的需求,这使得代码更易于维护,更易于测试和可重用。 这样做的代价是冗长,这是付出很小的代价来支付我们认为是一个重大胜利,就好像我们希望我们的客户层生活在一个单独的仓库中,由另一个项目使用一样—这将非常简单。 考虑上图,目录结构以类似的综合结构进行布局: API层 API层(GraphQL)既定义端点,又将其路由到其适当的解析程序(控制器)。 我们使用Express作为应用程序的基础,并添加Apollo Server作为中间件,以帮助路由和解释GraphQL模式。 我们选择Apollo Server的主要原因在于开发人员工具: 作为API的使用者,模拟一个或多个响应非常容易。 这意味着经典的“我们应该创建端到端或集成测试”辩论已经开始,甚至还没有开始。 集成测试成为一种规范,因为简单的布尔标志为您模拟API响应。 内置了GraphQL Playground,可轻松执行针对API的查询和更改。 可以认为这是内置在端点中的Postman(或REST客户端),该端点知道API的定义,甚至可以在尝试执行之前验证和协助请求语法。 模式目录包含我们所有API模型和端点的定义,并且是根据Apollo文档中描述的模式模型定义进行定义的。 服务层…