hello i personally would just do a suspendable function sinc

Question

hello i personally would just do a suspendable function since our functions effectively become the data fetcher in `graphql java` world there is really no need for the data loader e g ```class Employee val name String private val companyId Int suspend fun company = myCompanyService load companyId ``` there are number of ways of how to expose the `myCompanyService` in the above

Dariusz Kuc · Answer

it really depends how deep complex autowiring is

Dariusz Kuc · Answer

Top level queries objects can easily autowire stuff

Dariusz Kuc · Answer

Once you go deeper then you still can use it but you got to use some bean factory to create those objects

Dariusz Kuc · Answer

See our examples under graphql kotlin repo

Dariusz Kuc · Answer

Instead of autowiring sometimes calling the constructor might be easier

Robert · Answer

I don t know your code but I don t think every employee should have a dependency on companyService

Darren · Answer

Right Robert that s the awkwardness I m trying to avoid an output type shouldn t have a service dependency We ve been using the lateinit approach with data loaders but there s a level of indirection there that would be nice to avoid

Robert · Answer

Would some kind of AOP work

Robert · Answer

Or Kotlin delegates

Dariusz Kuc · Answer

gt an output type shouldn t have a service dependency why not your output classes don t have to be simple data classes POJOs and if you were to use them as such you will be severely limiting yourself e g functions will only be invoked if your query requests for it vs fields get calculated always

Darren · Answer

Yea so my preference would be to use functions to define expensive fields but it complicates the creation of those output types on one hand we want them to be data classes POJOs because some service will be building but in order to resolve a function a separate service would need to be injected into the out put type e g employee service is building employee objects but shouldn t need to inject the company service into the employee objects

Dariusz Kuc · Answer

well another alternative is to look into adding support for extension functions <https github com ExpediaGroup graphql kotlin issues 383>

Dariusz Kuc · Answer

while we don t support it out of the box it is possible to add support through the hooks

Dariusz Kuc · Answer

spring AOP doesn t really work with reactive stuff

Dariusz Kuc · Answer

well something like before after might be ok around aspects might have trouble

Dariusz Kuc · Answer

or not gt with coroutines you can enter the same function multiple times due to the callbacks on continuation

Robert · Answer

Oh good hint regarding AOP Will try to leverage Kotlin Delegation for this let s see

Robert · Answer

Back to my favorite topic joy my current workaround is a nullable property which is of course reflected in the schema and not optimal The field is populated only when requested I think this could be better if the schema object is an interface where the conditional property is a function The DataLoader just creates an instance of it if requested And some kind of dummy value for the nested field if not requested gt client will never see this

Darren · Answer

The approach we ended up using was an interface with a default function annotated with a custom annotation ` Fetchable` A custom data fetcher factory looks for properties with that custom annotation This also lets us define the contract for how we resolve a related object e g a product has a category but must expose the category id for the data fetcher to resolve the related category