Lazy resolvers?
We are trying to make use of nested resolvers such that the resolvers that comprise our graph are more composable and independent of one another.
Before/what we have currently:
from cloud_console.gql.resolvers.access_token import access_tokens
from cloud_console.gql.resolvers.groups import groups
from cloud_console.gql.resolvers.organization import organization
@strawberry.experimental.pydantic.type(model=CurrentUserPyd, all_fields=True)
class CurrentUser:
access_tokens = access_tokens
groups = groups
organization = organizationAfter/what we want to move towards:
@strawberry.experimental.pydantic.type(model=CurrentUserPyd, all_fields=True)
class CurrentUser:
@strawberry.field
async def access_tokens(self, info: strawberry.Info) -> list[AccessToken] | None:
from cloud_console.gql.resolvers.access_token import access_tokens
return await access_tokens(info)
@strawberry.field
async def groups(self, info: strawberry.Info) -> list[Group] | None:
from cloud_console.gql.resolvers.groups import groups
return await groups(info)
@strawberry.field
async def organization(self, info: strawberry.Info) -> Organization | None:
from cloud_console.gql.resolvers.organization import organization
return await organization(info)Is there anything we can do to avoid having to put the resolver imports in the field func definitions? Feels very not Pythonic to establish this pattern.
cc @patrick91
strawberry-graphql / strawberry
A GraphQL library for Python that leverages type annotations 🍓
4.0k
How does funding with Polar work?
1
Pay now to fund the work behind this issue.
2
Get updates on progress being made.
3
Maintainer is rewarded once the issue is completed.
FAQ
Backer
You're funding impactful open source efforts
Contributor
You want to contribute to this effort
Maintainer
You want to get funding like this too