Ask: Could FederationSchemaFactory allow programatic configuration of handler methods?

[klys-equinix]

Right now entity handler methods are automatically detected by FederationSchemaFactory based on EntityMapping annotations by

spring-graphql/spring-graphql/src/main/java/org/springframework/graphql/data/method/annotation/support/AnnotatedControllerDetectionSupport.java

Line 266 in bab967c

protected Set<M> detectHandlerMethods() {

It would seem that it would be very simple to add an option to add such handler methods manually, for example you could add method like

FederationSchemaFactory.setEntityHandler(entityName, handlerMethod)

It would also be useful to be able to access a list of those methods

[rstoyanchev]

Yes we could make direct registration possible.

For the list, this may be of limited use depending on the use. Up until the afterProperties call, it will only show manually registered mappings, and after that it won't be possible to register additional ones.

[klys-equinix]

I am using this in a customizer bean, like

  @Bean
  @Primary
  fun customizer(factory: FederationSchemaFactory): GraphQlSourceBuilderCustomizer {
    return GraphQlSourceBuilderCustomizer { builder: SchemaResourceBuilder ->
      builder
          .schemaFactory({ registry: TypeDefinitionRegistry, wiring: RuntimeWiring ->
            addEntityHandlerMethodsForAssetImplementations(registry, factory)
            factory.createGraphQLSchema(registry, wiring)
          })
    }
  }

  private fun addEntityHandlerMethodsForAssetImplementations(
      registry: TypeDefinitionRegistry,
      factory: FederationSchemaFactory
  ) {
    val typesImplementingAsset = getTypesImplementingAsset(registry)
    // TODO track this ticket https://github.com/spring-projects/spring-graphql/issues/1324
    val handlerMethodsField =
        FederationSchemaFactory::class.java.getDeclaredField("handlerMethods").apply {
          isAccessible = true
        }
    val handlerMethods = handlerMethodsField[factory] as MutableMap<String, Any?>
    typesImplementingAsset.forEach {
      if (!handlerMethods.containsKey(it)) {
        handlerMethods[it] = handlerMethods[Asset::class.simpleName]
      }
    }
  }

for now i am using reflection to get access. The reason why i need this is i want to use the same resolver for many entites (implementations of an interface)

[rstoyanchev]

Good to know. How does the resolver decide which entity to return? I also wonder if this is a case we could possibly support. If you don't mind sharing a snippet of representative schema and controller code, it would help to visualize.

[klys-equinix]

This particular resolver is very flexible. It does not really decide what type to return as it returns the entities as simple maps (this is allowed by graphql java), and it decides what fields to fetch for particular assets based on selection set (since the user can define what he wants to get on what interface/type)

  @EntityMapping(value = "Asset")
  fun assetEntities(
      @Argument(name = "maximoUid") maximoUids: List<String>,
      env: DataFetchingEnvironment,
  ) = fetchAssetsByMaximoUids(maximoUids, env)

    private fun fetchAssetsByMaximoUids(
        maximoUids: List<String>,
        env: DataFetchingEnvironment
    ): List<AssetAsMap> =
        federatedAssetQueryService
            .fetchAssetsByMaximoUids(
                maximoUids = maximoUids,
                env.selectionSet.fields
                    .noFieldsWithSeparateResolvers()
                    .toRequestedAssetTypesWithFields(),
            )
            .orderByMaximoUids(maximoUids)

class FederatedAssetQueryService(
    private val federatedAssetRepository: FederatedAssetRepository,
) {

  fun fetchAssetsByMaximoUids(
      maximoUids: List<String>,
      selection: AssetTypesWithSelectedFields,
      assetTypeIn: List<String> = emptyList()
  ) =
      federatedAssetRepository
          .fetchAssetsByMaximoUids(
              maximoUids = maximoUids,
              selection = selection,
              assetTypeIn = assetTypeIn,
          )
          .entries
}

Since the user can request any subtype of Asset in response, the resolver needs to be able to return any subtype anyway - so there is no need for a separate resolver for each subtype