如何构建Sangria GraphQL Context以避免包含全部所需服务？

这个问题我之前在项目里也碰到过——当服务数量上去之后，把所有服务都塞进Context确实会变得臃肿不堪，而且很多字段根本用不上大部分服务。下面分享几个我实践过的可行方案，帮你简化Context的设计：

1. 懒加载的服务定位器（Service Locator）模式 #

核心思路是不在Context里直接存储所有服务实例，而是存放一个能按需获取服务的定位器。这样Context本身非常轻量，只有一个定位器引用，解析字段时再根据需要拉取对应的服务。

示例代码： #

import scala.reflect.ClassTag

// 定义服务定位器接口
trait ServiceLocator {
  def getService[T](implicit tag: ClassTag[T]): T
}

// 用Guice实现（也可以用其他DI框架或自定义实现）
class GuiceServiceLocator(injector: com.google.inject.Injector) extends ServiceLocator {
  override def getService[T](implicit tag: ClassTag[T]): T =
    injector.getInstance(tag.runtimeClass.asInstanceOf[Class[T]])
}

// 简化后的Context
case class Context(serviceLocator: ServiceLocator)

// 字段解析时按需获取服务
val userField = Field(
  name = "user",
  fieldType = UserType,
  arguments = List(Argument("id", IDType)),
  resolve = ctx => {
    val userService = ctx.context.serviceLocator.getService[UserService]
    userService.getUser(ctx.arg[Long]("id"))
  }
)

优点：Context结构极简，新增服务无需修改Context定义；缺点：存在类型转换，需要依赖ClassTag，编译期类型安全稍弱。

2. 类型安全的依赖环境（结合ZIO等效果库） #

如果你的项目使用ZIO这类函数式效果库，可以用它的ZEnvironment作为Context——它本身就是一个类型安全的依赖集合，支持按需提取所需服务，完全避免臃肿。

示例代码： #

import zio._
import sangria.schema._

// 定义服务 trait
trait UserService { def getUser(id: Long): Task[User] }
trait ProductService { def getProduct(id: Long): Task[Product] }

// 用ZEnvironment作为Context
type AppContext = ZEnvironment[UserService with ProductService]

// 字段解析返回ZIO效果，按需获取服务
val userField = Field(
  name = "user",
  fieldType = UserType,
  arguments = List(Argument("id", IDType)),
  resolve = ctx => {
    for {
      userService <- ZIO.service[UserService]
      user <- userService.getUser(ctx.arg[Long]("id"))
    } yield user
  }
)

// 执行时提供完整环境
val env = ZEnvironment(UserServiceImpl(), ProductServiceImpl())
Executor.execute(schema, query, env)
  .provide(env)
  .unsafeRunSync()

优点：完全类型安全，依赖清晰；缺点：需要引入ZIO依赖，适合函数式风格的项目。

3. 拆分Context为子模块 #

把大Context拆分为多个子Context，每个子Context对应一个业务模块的服务集合，主Context通过懒加载持有这些子Context。这样字段解析时只需要访问对应的子Context，避免接触无关服务。

示例代码： #

// 子Context定义
case class UserContext(userService: UserService, authService: AuthService)
case class ProductContext(productService: ProductService, inventoryService: InventoryService)

// 主Context，用懒加载避免初始化所有服务
case class Context(
  userCtx: => UserContext,
  productCtx: => ProductContext
)

// 字段解析时访问对应子Context
val productField = Field(
  name = "product",
  fieldType = ProductType,
  arguments = List(Argument("id", IDType)),
  resolve = ctx => {
    ctx.context.productCtx.productService.getProduct(ctx.arg[Long]("id"))
  }
)

优点：业务模块边界清晰，Context结构更直观；缺点：新增模块需要扩展主Context，适合服务划分明确的项目。

4. 基于Reader Monad的细粒度依赖 #

Sangria支持解析函数返回Reader[Context, T]类型，你可以把Context设计成仅包含当前字段需要的服务，然后通过组合Reader来处理多服务依赖的场景。

示例代码： #

import sangria.schema._
import cats.data.Reader

// 单个服务的Context类型
type UserServiceContext = UserService
type ProductServiceContext = ProductService

// 字段解析函数依赖单个服务
val userField = Field(
  name = "user",
  fieldType = UserType,
  arguments = List(Argument("id", IDType)),
  resolve = ctx => Reader[UserServiceContext, User] { service =>
    service.getUser(ctx.arg[Long]("id"))
  }
)

// 组合多个Reader处理多服务依赖
val orderField = Field(
  name = "order",
  fieldType = OrderType,
  arguments = List(Argument("id", IDType)),
  resolve = ctx => {
    val userReader = Reader[UserServiceContext, User](_.getUser(ctx.arg[Long]("userId")))
    val productReader = Reader[ProductServiceContext, Product](_.getProduct(ctx.arg[Long]("productId")))
    
    (userReader |@| productReader).map { (user, product) =>
      Order(ctx.arg[Long]("id"), user, product)
    }
  }
)

优点：依赖完全按需，编译期类型安全；缺点：需要处理Reader的组合逻辑，适合对类型安全要求极高的场景。

内容的提问来源于stack exchange，提问作者tgk