You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 7, 2026. It is now read-only.
We should support code-first approach to type definition in addition to current schema-first one. My original idea was to do this through decorator (like how Strawberry does it) but my current idea is to use universal base types for both code-first and schema-first approaches to GraphQL schema definition. The differentiation factor between those two would be a presence of __schema__ atribute on the type:
# Schema first objectclassQuery(ObjectType):
__schema__=gql(
""" type Query { message: String! year: Int! } """
)
@fielddefmessage(*_):
return"Hello world!"@fielddefyear(*_):
returndate.today().year# Code first objectclassQuery(ObjectType):
@fielddefmessage(*_) ->str:
return"Hello world!"@fielddefyear(*_) ->str:
returndate.today().year
We should support code-first approach to type definition in addition to current schema-first one. My original idea was to do this through decorator (like how Strawberry does it) but my current idea is to use universal base types for both code-first and schema-first approaches to GraphQL schema definition. The differentiation factor between those two would be a presence of
__schema__atribute on the type: