FastAPI Synchronous/Blocking Resolvers

[donalddalton]

Hello! My team recently started using Strawberry to migrate a moderately sized FastAPI application from REST to GraphQL. To do this, we are making use of Strawberry's FastAPI GraphQLRouter. It seems as though this router assumes resolvers are implemented as asynchronous/non-blocking functions, but this is unfortunately not the case for the database access layer (pyscopg2/sqlalchemy) our resolvers call into. This is problematic because it means our queries are being executed on the "main" event loop thread and completely block the server for the duration of each request. Ideally, we'd like to avoid refactoring our app to use asyncio and instead have GraphQL requests execute on an external thread pool (FastAPI does this transparently for synchronous endpoint functions). I see that Strawberry supports both sync/async request handling for other web frameworks but I have not found anything for FastAPI (e.g. a synchronous version of GraphQLRouter). Any guidance/commentary on this topic would be greatly appreciated. Thanks!

[patrick91]

@donalddalton so I'm not familiar with how FastAPI handles the execution on different thread pools, but sync resolvers should just work, but I'm assuming that having the route handler as async means that FastAPI can't do the thread pooling, right?

It should be pretty straight-forward to implement a sync version of the Router, but I don't know if it is worth adding it to Strawberry, it would definitely be nicer to use the thread pooling logic for resolvers, but I feel like it might be quite a bit of work 😊

@donalddalton would it be an issue for you to have a custom version of the router that's sync? Also, are you planning on using dataloaders?

[donalddalton]

@patrick91 thanks for the quick reply!

I'm assuming that having the route handler as async means that FastAPI can't do the thread pooling, right?

Yeah exactly!

It should be pretty straight-forward to implement a sync version of the Router, but I don't know if it is worth adding it to Strawberry

For sure! Would definitely defer to you on this -- I just suspect other folks using FastAPI and coming to Strawberry may run into this same scenario because FastAPI handles both sync/async route handlers transparently and doesn't force you to go full-blown asyncio.

would it be an issue for you to have a custom version of the router that's sync? Also, are you planning on using dataloaders?

Nope! This would work fine for us 👍. I've not used dataloaders but from a glance, I am not sure how they can help us here.

[patrick91]

Nope! This would work fine for us 👍. I've not used dataloaders but from a glance, I am not sure how they can help us here.

it's more for the future, if you want to optimise data fetching, as you can't use them without async io 😊

For sure! Would definitely defer to you on this -- I just suspect other folks using FastAPI and coming to Strawberry may run into this same scenario because FastAPI handles both sync/async route handlers transparently and doesn't force you to go full-blown asyncio.

I wonder if we could make a field extension, like this:

import strawberry
from strawberry.extensions import FieldExtension


class ThreadPoolExecutorExtension(FieldExtension):
    def resolve(self, next_: Callable[..., Any], source: Any, info: Info, **kwargs):
        # do what FastAPI does
        return next_(source, info, **kwargs)



@strawberry.type
class Query:
    @strawberry.field(extensions=[ThreadPoolExecutorExtension()])
    def string(self) -> str:
        return "This is a test!!"

[donalddalton]

Thanks for the suggestion! I am not very familiar with the extensions API so speaking under correction -- an issue I see with that approach is that the resolve hook (when used in either a field or schema extension) could be called many times during the execution of a single query. So while we could implement an extension that runs next_ on a dedicated thread pool (drawing conclusions about your suggested approach), I can't imagine it would be very efficient.

Another possible approach might be to implement a custom Schema class and override its execute method like so:

class SynchronousSchema(strawberry.Schema):
    def __init__(self, **kwargs):
        super().__init__(**kwargs)
        
    async def execute(
        self,
        query: Optional[str],
        variable_values: Optional[Dict[str, Any]] = None,
        context_value: Optional[Any] = None,
        root_value: Optional[Any] = None,
        operation_name: Optional[str] = None,
        allowed_operation_types: Optional[Iterable[OperationType]] = None,
    ) -> ExecutionResult:
        loop = asyncio.get_event_loop()

        return await loop.run_in_executor(
            None,
            self.execute_sync,
            query,
            variable_values,
            context_value,
            root_value,
            operation_name,
            allowed_operation_types
        )

I think this precludes the use of async resolvers entirely but seems to work otherwise.