How do we handle DI in schemas? For queries, I'd suppose I could make it a Micronaut singleton, and inject repositories in it, but when types (data classes with functions for property resolution) need repos, it's a bit messy to inject them in each instance of a search result, or is that really the best practice here?

For spring we provide spring aware data fetcher that can autowire spring beans as function arguments. You could probably do something similar for micronaut

As long as something is private or marked as

@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.kt

When schema types need repos, I've generally leant towards using DataLoaders that have injected fields and are accessible from the DataFetchingEnvironment in a resolver function, fwiw

The

@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...

This is the traditional contructor approach I was mentioning that does require any special features and using DI through the contructor

@Component
class ServiceQuery(private val userService: UserService) : Query {
    fun getUser(id: String) = userService.findUser(id)
}

Yeah, that's fine, the problem really starts when you get further down into the results. But now that I think of it, one of my issues was filtering, which only needs agregation of the query. The real example that a repo would be needed is when completing results like fetching the friend list lazily. But that leads to another question: If the user's name, telephone, etc... would be functions to allow filtering on them, then either you need to collect all those filters somehow before running that query, or just stuff a UserFilterInput in getUser and repeat all the fields there...?

You would need to do one of the following * Access the client query and any arguments with the

DataFetchingEnvironment

* 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