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
Based on a new implementation, is needed to improve the following things for next stable package:
Schema lazy type registering: Register types as schema access it.
Simplify schema base types. Avoid @memoize hacks. EDIT: Partially resolved in fields. Improve schema type getter
Add field description based on resolver function __doc__
Add python class enums.Enum mapping to a GraphQL Enum
Map received arguments keys by resolvers to be snake_case
Add Mutations
Add Relay Mutations
Generalize use of instance/types instantiation
Add field definition in types using only resolvers and decorators
One way for deal with most of this improvements is using a TypeRegister as epoxy is doing, however for new types behavior is not as easy to scale.
Research on TypeRegister
Having a Type Register means it have to create a different object each time to have to access, for example, an interface (without doing any _add_interface_impl hacks).
Also, it means the graphql-core type is fixed for each defined class.
The advantages of having a fixed type your_class.T is that could be shared across not only this graphene projects, but any that uses graphql-core.
However, the cost of having a fixed type for each defined class are more than the advantages.
Disadvantages
Why is not good to have a fixed type for each class? Some classes, like a relay Node depends a lot on the context where is being executed (or schema/registry). Why create a new Node class for just changing the context?
Also, it requires to add manually the type into the registry (via mixins, or hacking the registry for automatically adding my type).
Practical solution
Create a schema.T(object_type) that will return the type for an object_type associated for this schema.
The text was updated successfully, but these errors were encountered:
Based on a new implementation, is needed to improve the following things for next stable package:
__doc__
enums.Enum
mapping to a GraphQL EnumAdd field definition in types using only resolvers and decoratorsOne way for deal with most of this improvements is using a TypeRegister as epoxy is doing, however for new types behavior is not as easy to scale.
Research on TypeRegister
Having a Type Register means it have to create a different object each time to have to access, for example, an interface (without doing any
_add_interface_impl
hacks).Also, it means the
graphql-core
type is fixed for each defined class.The advantages of having a fixed type
your_class.T
is that could be shared across not only this graphene projects, but any that uses graphql-core.However, the cost of having a fixed type for each defined class are more than the advantages.
Disadvantages
Why is not good to have a fixed type for each class? Some classes, like a relay
Node
depends a lot on the context where is being executed (or schema/registry). Why create a newNode
class for just changing the context?Also, it requires to add manually the type into the registry (via mixins, or hacking the registry for automatically adding my type).
Practical solution
Create a
schema.T(object_type)
that will return the type for an object_type associated for this schema.The text was updated successfully, but these errors were encountered: