Allow programatic configuration of handler methods in FederationSchemaFactory

[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

[rstoyanchev]

I've prototyped a fix locally. It's a bit more involved than expected, exposing a callback and a Registry that's called at the right time in the initialization lifecycle, but not complex.

That said I'm still wondering about more first class support. Would you be able to put together a small sample in snippets? Just a couple of interfaces, the schema bits, and an example query. That would help me to see the full picture and consider what we can do. It feels like entity interfaces would be a common issue that shouldn't require manual registration