Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements next stable package #15

Closed
8 of 9 tasks
syrusakbary opened this issue Oct 25, 2015 · 3 comments
Closed
8 of 9 tasks

Improvements next stable package #15

syrusakbary opened this issue Oct 25, 2015 · 3 comments
Assignees
Milestone

Comments

@syrusakbary
Copy link
Member

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.

@syrusakbary
Copy link
Member Author

@jhgg Check the reasons for graphene for not going through a TypeRegister.

@syrusakbary
Copy link
Member Author

And post any advantages that I might be missing! I would love to discuss that! :)

@syrusakbary
Copy link
Member Author

Feel free to reopen the task for discussing that! :)

ronachong pushed a commit to ronachong/graphene that referenced this issue Nov 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant