dave08
02/21/2021, 12:28 PMDariusz Kuc
02/21/2021, 6:13 PMShane Myrick
02/21/2021, 6:45 PM@GraphQLIgnore
in your query class you can still use what ever DI tool/format you are using today. In graphql-kotlin-spring-server
we override the data fetcher and check if any function arguments are marked with @Autowired
. This is a special feature for spring, but again we could just have every one handle their own DI through the constructor
https://github.com/ExpediaGroup/graphql-kotlin/blob/b65d61a2123c02a04deb10aa8707fa[…]pediagroup/graphql/server/spring/execution/SpringDataFetcher.ktJoe
02/21/2021, 9:08 PMdave08
02/22/2021, 10:33 AM@AutoWired
approach looks interesting 🙂! The DataLoaders approach isn't too clear to me yet, I'll have to look into it, thanks! BeanAware can get to be lots of boilerplate, so I'm avoiding that... I saw it in one of the examples, in simple cases it's fine, but I would get to alot of clutter in my case...Shane Myrick
02/22/2021, 5:43 PM@Component
class ServiceQuery(private val userService: UserService) : Query {
fun getUser(id: String) = userService.findUser(id)
}
dave08
02/23/2021, 3:10 AMShane Myrick
02/23/2021, 4:38 AMDataFetchingEnvironment
* Add arguments to your further down functions
* Save the data at the top level in the context to be used later
* Keep passing the top level arugments as private vars all the way down