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
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
The text was updated successfully, but these errors were encountered:
Yup, it should work with Pydantic too! The prototype I has decorator that introspects given type and sets __ariadne_graphql__ attribute on it with GraphQLObjectModel that make_executable_schema looks for to create GraphQLObjectType.
Currently, we are working on PR #32, which covers both schema-first and code-first approaches. Regarding Pydantic, we need to consider and plan whether and how we want to implement it.
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:The text was updated successfully, but these errors were encountered: