Support/help with promise-based resolvers

[AlexCLeduc]

I think I have a good use-case for non-async, promise-based resolution.

We are making django ORM from our dataloaders. We moved away from using async in django 3.0 because django would force us to isolate ORM calls and wrap them in sync_to_async. Instead, we ditched async and used promises with a generator based syntax. Examples below:

What we'd like to do, but django doesn't allow

class MyDataLoader(...):
    async def batch_load(self, ids):
        data_from_other_loader = await other_loader.load_many(ids)
      	data_from_orm = MyModel.objects.filter(id__in=ids) # error! can't call django ORM from async context. 
        # return processed combination of orm/loader data

What django would like us to do

class MyDataLoader(...):
    async def batch_load(self, ids):
        data_from_other_loader = await other_loader.load_many(ids)
        data_from_orm = await get_orm_data()
        # return processed combination of orm/loader data
    
@sync_to_async
def get_orm_data(ids):
    return MyModel.objects.filter(id__in=ids)

What we settled on instead (ditch async, use generator-syntax around promises)

class MyDataLoader(...):
    def batch_load(self,ids):
        data_from_other_loader = yield other_loader.load_many(ids)
        data_from_orm = MyModel.objects.filter(id__in=ids)
        # return processed combination of orm/loader data

I have a generator_function_to_promise tool that allows this syntax, as well as a middleware that converts generators returned from resolvers into promises. I have hundreds of dataloaders following this pattern. I don't want to be stuck isolating all the ORM calls as per django's recommendations because it's noisy and decreases legibility.

If it's not difficult to re-add promise support, I'd really appreciate it. If not, can anyone think of a solution to my problem?

[Cito]

Since Python and its standard lib do not support promises, my first question is: What kind of promises do you have in mind? Is this something that Django provides? Or are you using the separate promise package used by Core-2?

[AlexCLeduc]

Yes, we are using the promise package used by Core-2 and the dataloader class included with graphene 2.

[Cito]

The problem with this is that these are legacy packages. I'm not sure how well they are maintained and I want to keep GraphQL-core simple and not in some way dependent of external non-standard packages or in the need of supporting these forever. The execution mechanism has also been completely changed and simplified, relying only on async.io, so no, it would not be easy to add the old promise support back in a way that does not degrade performance.

GraphQL-core should really be a core library as the name says - if you want to have support for non-standard async mechanisms such as promises, this should happen in a separate package that adds these capabilities to GraphQL-core. I think that would be the cleaner and more maintainable way to solve this. The middleware and execution_context_class parameters of the execute function should be usable as hooks allwing to implement this, but if necessary we could add more hooks. Could you imagine to create such a package?

[AlexCLeduc]

Thanks for the advice, I'll look into middleware and execution_context_class. I've also followed up with graphene to see if they can re-add support for promises. You can close this issue if you'd like, but it might be a good place to discuss those additional hooks, should the need arise.

[jkimbo]

@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 (Django being the notable one). While it's possible to create a custom execution context class to handle Promises it's pretty fiddly and would be prone to breaking if anything changed. You can see my attempt here: strawberry-graphql/strawberry#614

I don't think graphql-core needs to support Promises specifically but having a way to handle deferred execution so that you can build dataloaders on threads instead of asyncio would be very helpful. GraphQL Ruby has the concept of lazy execution which is exactly what is needed: https://graphql-ruby.org/schema/lazy_execution

[Cito]

@AlexCLeduc @jkimbo Thanks for your feedback. I understand that deferred execution (particularly for the DataLoader mechanism) without asyncio is a real world use case that we should support in some way.

@jkimbo you have a point that adding this support in a separate package or on a higher level like Graphene or Strawberry has also its downsides. If it relies on internal details of GraphQL-core it would be prone to break with every new release of GraphQL-core. To avoid this, we could either extend the official API (as suggested above) or actually move such support into GraphQL-core itself.

If we do this, then I think we agree it should be done in a generic way, not special casing for the old Promise lib or Django, and it should not degrade performance for the existing execution modes. Currently I don't have the time and need to work on this myself, so the initiative must come from people like you. Don't hesitate to send in PRs with suggestions. But please always include tests and performance benchmarks (see the tests/benchmarks directory).

I will keep this issue open for discussion and coordination of these efforts.