Jonathan Kim

Thanks @jtratner ! I get the use case for this but I'm just wondering if this is the best API for it because it seems quite verbose. Could we simply...

I think that api makes more sense @jtratner so let's move towards that implementation. We can first start by preferring `input_fields` (or maybe just `input`) and `output_fields` options and emitting...

> Specifying fields or exclude will be required in future version (they only modify input fields). If specified in current version, it means that only output field is clientMutationId. exclude=graphene_django.ALL_FIELDS...

@Cito I think there is justification to add some kind of support for deferred functions that is not asyncio into graphql core because not all libraries are asyncio compatible yet...

@Cito any thoughts on this approach? Do you think it's a viable way of solving this problem?

Thanks for the detailed feedback @Cito and I agree with your summary of the problem, though specifically I'm trying to solve the case where you need batching in a purely...

Sounds good @Cito , having a specific ExecutionContext class sounds like a good idea to me, I just wasn't sure how to implement it without refactoring the implementation which I...

Sorry for not getting back to you sooner @Cito . Your code looks great and I think it's a much better approach. Regarding if we should split it out: I...

I've published a package for people to try this out: https://github.com/jkimbo/graphql-sync-dataloaders @Cito I still think this should live inside graphql-core for maintainability reasons but at least this way people can...

@Cito would you be open to splitting the ExecutionContext class into sync and async versions? That way we can drop most of the `is_awaitable` checks and simplify the code significantly.