Why DataFetchers that use Dataloaders for lateinit variables should have prototype beans and not singletons?

[RIP21]

1. I replicated the same logic that you have in your example in my app and I'm still unsure why DataFetchers should be BeanAware and why they should be of prototype scope? (Note I do not clearly understand what BeanAware means, as I'm not super into Spring and used to be Java dev for 3 yrs without Spring (BigData stuff), but currently Node dev for the last 4 yrs, so do not assume I know Spring in and out while answering :D)

@Component("LastUpdatedDataFetcher")
@Scope(SCOPE_PROTOTYPE)
class LastUpdatedDataFetcher : DataFetcher<CompletableFuture<LastUpdated>>, BeanFactoryAware {
    private lateinit var beanFactory: BeanFactory

    override fun setBeanFactory(beanFactory: BeanFactory) {
        this.beanFactory = beanFactory
    }

    override fun get(environment: DataFetchingEnvironment): CompletableFuture<LastUpdated> {
        val companyId: UUID = environment.getSource<WithLastUpdatedDataloader>().companyId
        return environment
            .getDataLoader<UUID, LastUpdated>(LastUpdatedDataloader.NAME)
            .load(companyId)
    }
}

Like, they're stateless anyway. What's the point?

2. Why all this rollercoaster is needed with lateinit when you can simply.

data class DashboardReady(
    @GraphQLIgnore
    override var companyId: UUID,
    override var status: ProcessingStatus = ProcessingStatus.READY
): Dashboard, WithLastUpdatedDataloader {
    fun lastUpdated(environment: DataFetchingEnvironment): CompletableFuture<LastUpdated> {
        return environment
            .getDataLoader<UUID, LastUpdated>(LastUpdatedDataloader.NAME)
            .load(companyId)
    }
}

I see only code reuse purpose with something very generic like DB Models, but then it requires you to introduce some marker interfaces as I have above WithLastUpdatedDataloader that ensure you can cast safely :)

3. To reiterate. Am I right that just this config: (assuming I have all the config with CustomDataFetcherFactoryProvider + SpringDataFetcherFactory that is in example spring project that enables all lateinit stuff)

@Configuration
class DataLoaderConfiguration(private val lastUpdatedLoader: LastUpdatedDataloader) {
    @Bean
    fun dataLoaderRegistryFactory(): DataLoaderRegistryFactory {
        return object : DataLoaderRegistryFactory {
            override fun generate(): DataLoaderRegistry {
                val registry = DataLoaderRegistry()
                registry.register(LastUpdatedDataloader.NAME, lastUpdatedLoader.getLoader())
                return registry
            }
        }
    }
}

Plus this dataloader component defenition

@Component
class LastUpdatedDataloader(var lastUpdatedService: LastUpdatedService) {
    companion object {
        const val NAME: String = "lastUpdatedDataloader"
    }

    fun getLoader(): DataLoader<UUID, LastUpdated> {
        return DataLoader.newMappedDataLoader { companyIds ->
            CompletableFuture.supplyAsync {
                companyIds.map { it to lastUpdatedService.getLastUpdatedByCompanyId(it) }.toMap()
            }
        }
    }
}

And in place of use of data loader

data class DashboardReady(
    @GraphQLIgnore
    override var companyId: UUID,
    override var status: ProcessingStatus = ProcessingStatus.READY
): Dashboard {
    fun lastUpdated(environment: DataFetchingEnvironment): CompletableFuture<LastUpdated> {
        return environment
            .getDataLoader<UUID, LastUpdated>(LastUpdatedDataloader.NAME)
            .load(companyId)
    }
}

Will be absolutely enough to get Dataloader working just fine?

My main concern with lateinit is that, well, while it is really nice for reuse, it's still quite hacky and implicit, which I want to avoid :) But if I can use both, then I'm super happy as this looks 10x better than graphql-java raw usage of Dataloaders :)
Plus another concern is that you lock yourself into only ONE way of handling dataloading of some particular type or scalar type.
Like:
lateinit var someDate: LocalDate then you have one logic, let say for WhateverEntity, but if another entity named AnotherEntity that also has lateinit var anotherDate: LocalDate then as you have registered a Dataloader of lateinit handling for LocalDate for previous one you'll have possibly a conflict, so problems how to handle that and so I have no idea how you can tell schema gen engine that, for WhateverEntityyou use this DataFetcher to resolve late init LocalDate, but for AnotherEntity you should use this, another one made especially for you.

While for some basic stuff like optimize n+1 for regular DB foreign key fetching of Models, this may work wonders (while still requires annoying interfaces to cast stuff), for one-off optimizations that just ensure sort of memoization, like if some service function called in this same request with same args and does some heavy computations, just resolve promise once and then return from the cache to all callers, I guess the approach in point 3 is the best.

Sorry for a lot of text, just want to understand it better :)
BTW some sort of drawing of how kotlin-graphql works and generates DataFetchers per each field it detected will be nice for beginners. And when these DataFetchers are generated etc. As I see that dataloaders are getting registered per request, which is expected, but what about all others? Are they too? It's unclear to me yet :)

[smyrick]

@RIP21 We don't have a great diagram but hopefully this can better explain what code creates the data fetchers.

For properties, it is done here:

graphql-kotlin/graphql-kotlin-schema-generator/src/main/kotlin/com/expediagroup/graphql/generator/types/generateProperty.kt

Lines 57 to 58 in b8ba162

	val dataFetcherFactory = generator.config.dataFetcherFactoryProvider.propertyDataFetcherFactory(kClass = parentClass, kProperty = prop)
	generator.codeRegistry.dataFetcher(coordinates, dataFetcherFactory)

And for functions it is done here:

graphql-kotlin/graphql-kotlin-schema-generator/src/main/kotlin/com/expediagroup/graphql/generator/types/generateFunction.kt

Lines 58 to 61 in b8ba162

	if (!abstract) {
	val dataFetcherFactory = generator.config.dataFetcherFactoryProvider.functionDataFetcherFactory(target = target, kFunction = fn)
	generator.codeRegistry.dataFetcher(coordinates, dataFetcherFactory)
	}

Everything else around the factories and providers is just to allow customization at various points and if you are using the spring-server, to do that with spring beans.

As for DataLoaders I would have to do some more digging myself as we do not use DataLoaders at Expedia Group. Instead we just either cache data in the service with traditional Java/Kotlin caching mechanism or cache at other layers of our service stack and not in GraphQL. If you have found a way to create and update the DataLoaders across requests, feel free to update the documentation with a better example.

BeanFactoryAware is used if you want LastUpdatedDataFetcher to still be a Bean you can load but do not have all the properties at start up time to create the bean, so you have to manually add it into the BeanFactory later once you have your lateinit value. I wouldn't say that lateinit is a hacky approach but if you can accomplish it without lateinit I would

[RIP21]

I would use DataLoaders only for batch requests.
But for the service method calls local cache. What would you use? Some sort of wrapper around service with Map?
You know, I just want to memoize per request. Like if service method was called before by other resolver with the same args, just instantly give an answer.
Surely at some point, some Redis will be introduced, but for now, we don't need that but in the future would so something that is easy to extend.

Can you provide may be an example of a traditional caching mechanism thingy? I assume some wrapper may be a simple thing to implement, but I'm afraid of possible problems with concurrency, so some good start to avoid stupid mistakes would be awesome :)

I imagine some service that always returns Promises (completable futures) and resolves it immediately if it's there, or if some of their services already called it with the same parameters a millisecond ago, and it's kinda pending/calculating/executing, just wait for this result instead of calling it again.

[smyrick]

For local cache we would use something like caffeine or if you have it included already the Guava Cache.

Then you would abstract the API call to a service that first checks it's own local cache

@Service
class MyCompanyService(private val webClient: WebClient) {
    private val cache = Cache()

    suspend fun getCompanyById(id: String): Company {
        if (cache.hasItem(id)) {
            return cache.get(id)
        } else {
            val company = webClient.get("/company/$id")
            cache.put(id, company)
            return company
        }
    }
}

Then if you wanted to abstract the cache to it's own service, like redis, you can do that by injecting the bean here too but the service calls don't have to change

[RIP21]

Yup. Pretty straight forward :) I was more about some "magical wrapper" but I guess we should leave it for JS :D (in TS I would just build a decorator function that composes ANY another service iterates over functions it has and wraps around it with a simple caching mechanism, same as you show above :)

[dariuszkuc]

Great questions!

As Shane mentioned, when building out GraphQL schema graphql-kotlin will automatically create FunctionDataFetcher for functions/methods and default to PropertyDataFetcher for getter fields. This mapping is stored in graphql-java CodeRegistry that is then referenced when resolving fields. By marking a field as lateinit it allows you to bypass the above default behavior and inject a custom data fetcher (i.e. your LastUpdatedDataFetcher) that abstracts away of how you resolve that field. If you create separate custom data fetcher (LastUpdatedDataFetcher) it allows you to reuse it in multiple places. In the example above there is no point in making the custom data fetcher bean aware (which requires lateinit var) as it does not need that functionality.

That being said, in general I think that is an overkill to create those custom data fetchers and I'd just retrieve the target data loader from the DataFetchingEnvironment instead (as in your # 2 example). I'm not an expert on DataLoaders but I think your config in # 3 looks fine.

--
As for the DataFetcher usage I guess it really depends on your underlying schema and types of queries that are executed against it. Technically, since graphql-kotlin exposes your functions you can put whatever logic inside (including caching if needed). I am unsure if Spring @Cacheable (which executes an around aspect) works with Webflux - it did not in the past but maybe it was fixed in new versions. Because of the continuations I am unsure whether aspects will work for coroutines either - idiomatic Kotlin would suggest to create your own coroutine that accepts a lambda to execute and wraps its execution with caching logic. For simple local caches you could use something like https://github.com/ben-manes/caffeine.

I think there was also some outstanding issue with mixing Mono and CompletableFuture when using DataLoader that forced you to only use CompletableFuture but don't remember the exact details.

[RIP21]

Nice! Thanks a lot for this write up. Totally forgot that Spring has AOP so probably the "magic" caching is possible to achieve without much effort but, surely, will have to dig into it later when needed.
Will check out caffeine too :)

Got it then, thanks a lot. You folks rock! At the beginning I was pretty sceptical of approach of generator from reflection etc., but now I see how nicely designed this thing is, everything is possible :)
And thanks for quick answers!

And have a great upcoming New Years celebrations :)

Once I'll become more familiar with all that machinery I'll definitely be glad to contribute into the docs :) So stay tuned :P