后端GraphQLAPI设计【免费下载链接】type-graphqlCreate GraphQL schema and resolvers with TypeScript, using classes and decorators!项目地址https://gitcode.com/gh_mirrors/ty/type-graphql点击查看免费下载依赖注入Dependency Injection, DI是解耦应用各部分、提升可测试性与可维护性的关键模式。TypeGraphQL 通过在buildSchema中注册第三方 IoC 容器让 Resolver 与服务类以声明式方式获得依赖自v0.13.0起更支持按请求创建独立实例的作用域容器Scoped Container用于请求级日志追踪与有状态服务管理。读完本文你将掌握在 TypeGraphQL 中接入 TypeDI 等容器、在 Apollo Server 中按请求注入唯一上下文、并通过插件生命周期清理容器以避免内存泄漏的完整实战方案。为什么 TypeGraphQL 需要 IoC 容器TypeGraphQL 的核心思想是用 TypeScript 类与装饰器声明 GraphQL Schema 与 Resolver。Resolver 类天然需要依赖业务服务、仓储或日志器等对象而手工new这些依赖会带来强耦合、难以测试与替换的问题。依赖注入模式将“创建对象”与“使用对象”分离由 IoC 容器负责实例化与装配Resolver 只声明自己需要什么。TypeGraphQL 将这一能力以可插拔方式提供框架自身不绑定任何具体容器只要求容器实现统一的get接口。在 src/utils/container.ts 中可以看到这一抽象的核心定义export interface ContainerType { get(someClass: any, resolverData: ResolverDataany): any | Promiseany; } export type ContainerGetterTContext extends object ( resolverData: ResolverDataTContext, ) ContainerType;也就是说buildSchema的container选项既可以直接传入一个容器实例满足get方法也可以传入一个容器获取函数ContainerGetter——后者正是作用域容器的入口。值得强调的是TypeGraphQL 在未配置任何容器时并非无法工作框架内置了 DefaultContainer它默认对每个类只创建一次实例并缓存复用因此“零配置”也能运行只是没有 DI 生命周期管理能力。基础用法注册第三方容器接入 DI 的步骤非常简单只需在buildSchema中注册容器即可。以 TypeDI 为例import { buildSchema } from type-graphql; // import your IoC container import { Container } from typedi; import { SampleResolver } from ./resolvers; // build the schema as always const schema await buildSchema({ resolvers: [SampleResolver], // register the 3rd party IOC container container: Container, });注册后TypeGraphQL 在执行解析流程时会把 Resolver 及中间件类的实例化委托给容器。从 src/resolvers/create.ts 的调用链可以看到框架在解析字段时通过container.getInstance(...)获取目标实例并将解析器数据一并传入授权检查器、中间件类同样经由容器实例化见 src/helpers/auth-middleware.ts 与 src/resolvers/helpers.ts。在底层IOCContainer.getInstance 会优先走用户注册的容器否则回退到内置DefaultContainer。随后 Resolver 就能声明依赖由 TypeDI 自动注入import { Service } from typedi; Service() Resolver(of Recipe) export class RecipeResolver { constructor( // constructor injection of a service private readonly recipeService: RecipeService, ) {} Query(returns Recipe, { nullable: true }) async recipe(Arg(recipeId) recipeId: string) { // usage of the injected service return this.recipeService.getOne(recipeId); } }服务本身也是一个普通类可以继续使用Service()与Inject声明其内部依赖import { Service, Inject } from typedi; Service() export class RecipeService { Inject(SAMPLE_RECIPES) private readonly items: Recipe[], async getAll() { return this.items; } async getOne(id: string) { return this.items.find(item item.id id); } }仓库中的 examples/using-container 提供了可完整运行的参考实现index.ts在buildSchema中传入container: Container并通过Container.set({ id: SAMPLE_RECIPES, factory: () sampleRecipes.slice() })预置数据recipe.resolver.ts通过构造函数注入RecipeServicerecipe.service.ts通过Inject(SAMPLE_RECIPES)注入样本数据并封装了getAll/getOne/add/findIndex等业务方法。使用 InversifyJS 的注意事项如果你使用 InversifyJS由于该库按具体类型concrete type进行绑定必须对 Resolver 类执行具体类型自绑定self-binding of concrete types否则容器无法解析 Resolver 依赖例如container.bindSampleResolver(SampleResolver).to(SampleResolver).inSingletonScope();inSingletonScope()将 Resolver 绑定为单例如果你需要按请求创建实例可将其替换为inTransientScope()或inRequestScope()取决于具体版本并在作用域容器章节中配合请求级容器使用。作用域容器为每个请求创建全新实例依赖注入虽然强大但某些高级场景需要为每一个请求创建全新的服务与 Resolver 实例例如按请求追踪日志、维护请求级状态。自v0.13.0起TypeGraphQL 正式支持作用域容器Scoped Container。与基础用法不同作用域容器要求你在buildSchema中传入一个容器获取函数即上文提到的ContainerGetter。该函数接收解析器数据ResolverData其中包含context并返回一个作用于当前请求的容器实例await buildSchema({ container: (({ context }: ResolverDataTContext) Container.of(context.requestId)); };这里的关键在于context.requestId的来源——TypeGraphQL 并不替你生成它你需要借助 HTTP GraphQL 中间件如express-graphql、apollo-server、graphql-yoga暴露的钩子手动提供。对于某些更高级的容器库你还可以在 context 构建时创建容器实例、将其放入 context 对象再在获取函数中取回await buildSchema({ container: (({ context }: ResolverDataTContext) context.container); };从源码看IOCContainer的构造函数会通过get in iocContainerOrContainerGetter typeof ...get function区分传入的是容器实例还是容器获取函数并在getInstance中执行containerGetter(resolverData)动态解析当前请求的容器src/utils/container.ts。ResolverData的结构root、args、context、info定义于 src/typings/resolver-data.ts因此容器获取函数中可以直接访问context等请求级信息。完整示例TypeDI Apollo Server将上述思路落到 Apollo Server 上需要在context创建方法中生成requestId、取出作用域容器并装配上下文import { ApolloServer } from apollo-server; import { Container } from typedi; const server new ApolloServer({ // schema comes from buildSchema as always schema, // provide unique context with requestId for each request context: () { // generate the requestId (it also may come from express-request-id or other middleware) const requestId Math.floor(Math.random() * Number.MAX_SAFE_INTEGER); // uuid-like const container Container.of(requestId); // get the scoped container const context { requestId, container }; // create fresh context object container.set(context, context); // place context or other data in container return context; }, });仓库中的 examples/using-scoped-container/index.ts 给出了与当前 Apollo Serverapollo/server对应的完整实现在context中通过Container.of(requestId.toString())创建作用域容器将context对象写入容器container.set(context, context)并在buildSchema中通过container: ({ context }: ResolverDataContext) context.container让每个请求使用各自独立的容器实例。作用域的效果可以从 examples/using-scoped-container/recipe/recipe.resolver.ts 直观看到RecipeResolver的构造函数打印RecipeResolver created!同时注入的Logger也打印Logger created!——每收到一个新请求控制台都会出现这两行输出证明 Resolver 与 Logger 都按请求被重新创建。Logger通过Inject(context)注入请求上下文并在日志中输出当前请求的requestIdexamples/using-scoped-container/logger.ts从而实现“同一请求的日志带有同一标识”。清理容器避免内存泄漏作用域容器会为每个请求创建新的服务与 Resolver 实例如果请求结束后不清理将造成严重的内存泄漏。因此必须在响应完成后销毁对应的作用域容器。Apollo Server 从 2.2.0 起提供插件机制其 willSendResponse 生命周期事件正好可用于请求结束后清理容器import { ApolloServer } from apollo-server; import { Container } from typedi; const server new ApolloServer({ // ... schema and context here plugins: [ { requestDidStart: () ({ willSendResponse(requestContext) { // remember to dispose the scoped container to prevent memory leaks Container.reset(requestContext.context.requestId); }, }), }, ], });在 examples/using-scoped-container/index.ts 中同样实现了这一清理逻辑willSendResponse中调用Container.reset(requestContext.contextValue.requestId.toString())并额外打印当前仍留在内存中的容器实例 IDInstances left in memory方便开发者观察多个并发请求下容器实例的创建与回收——注释明确提示可“发起多个并行请求”来观察该行为。容器生命周期配置与性能权衡完成buildSchema与服务器配置后剩下的工作就是容器库自身的生命周期配置。请查阅所用容器库的文档InversifyJS、injection-js、TypeDI 或其他来设置可注入对象的生命周期Transient瞬时每次解析都创建新实例Scoped作用域同一作用域请求内共享一个实例Singleton单例整个应用生命周期内仅一个实例。需要特别警惕某些容器库如 TypeDI在作用域模式下默认每个作用域都创建新实例这可能导致内存占用显著上升与查询解析速度下降。因此在启用作用域容器前请务必评估请求量与对象创建成本并确保清理逻辑如Container.reset在所有路径上都正确执行。关联文档与参考实现本文内容对应仓库中的官方文档 website/versioned_docs/version-1.2.0-rc.1/dependency-injection.md。你可以通过以下仓库资源进一步深入基础 DI 参考实现examples/using-container/index.ts、examples/using-container/recipe.resolver.ts、examples/using-container/recipe.service.ts作用域容器参考实现examples/using-scoped-container/index.ts、examples/using-scoped-container/context.type.ts、examples/using-scoped-container/logger.ts容器抽象与默认实现src/utils/container.ts容器选项的解析与存储src/schema/build-context.ts容器在解析流程中的实际调用src/resolvers/create.ts、src/resolvers/helpers.ts、src/helpers/auth-middleware.tsResolverData类型定义src/typings/resolver-data.ts。小结TypeGraphQL 的依赖注入体系可以总结为一条主线不绑定任何容器 → 通过ContainerType统一抽象接入第三方 IoC → 基础模式下全局单例共享 → 作用域模式下按请求动态创建并手动清理。实践中的关键点有三个一是用 InversifyJS 时务必对 Resolver 做具体类型自绑定二是作用域容器需要自行通过中间件/插件提供requestId并在buildSchema中以ContainerGetter形式注册三是务必在willSendResponse等生命周期钩子中销毁容器否则将面临内存泄漏风险。结合仓库中的两个官方示例你可以快速把 DI 与请求级状态管理落地到自己的 GraphQL 服务中。赞分享后端GraphQLAPI设计【免费下载链接】type-graphqlCreate GraphQL schema and resolvers with TypeScript, using classes and decorators!项目地址https://gitcode.com/gh_mirrors/ty/type-graphql点击查看免费下载相关推荐TypeGraphQL 依赖注入完全指南注册 IoC 容器与按请求作用域Scoped Container实战TypeGraphQL 依赖注入完全指南注册 IoC 容器与按请求作用域Scoped Container实战 依赖注入Dependency Inject后端GraphQLAPI设计lm-evaluation-harness 中的 Social IQA 任务从数据集解读到 YAML 配置与评测原理lm evaluation harness 中的 Social IQA 任务从数据集解读到 YAML 配置与评测原理 本篇技术指南聚焦 lm evaluati后端GraphQLAPI设计TypeGraphQL 依赖注入Dependency Injection完整指南集成 TypeDI、作用域容器与请求级实例管理TypeGraphQL 依赖注入Dependency Injection完整指南集成 TypeDI、作用域容器与请求级实例管理 本指南围绕 TypeGra后端GraphQLAPI设计上一篇Marqo开发者指南从零开始构建你的第一个智能检索应用下一篇Mem Reduct高效内存管理实用技巧与完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考