It is not completed by graphene itself, but in fact, libraries such as graphql-core and graphql-relay are hidden under graphene. GraphQL is a port of graphql-core because it has been popular under the JavaScript environment since its inception. Graphene is a python-like version of the core library graphql. When you think "there is not enough description" in the graphene document, it is actually the explanation part of the lower library. Eventually, you can find the answer by going back to the reference implementation.
The graphene field definition procedure is easy to add with mixin. The mixin style is recommended as it can be a pitfall when trying to use class inheritance.
graphene.relay: The relay itself is an additional specification based on GraphQL. Since it is widely used, it is less confusing to deal with it basically. The interfaces Connection and Node stand out.
Node interface
With Node, you can pull a single object from ʻid` via node query. Since it is not visible by default, Prepare as needed. If such an access path is not desirable (for security reasons, for example), implementation may be omitted.
You can import with graphene.Node without accessing with graphene.relay.Node.
Connection interface
Total_count of Connection is not supported by the library. If you take care of it separately, there will be less trouble. For example, graphene-sqlalchemy may have to be derived from the query object, so it is presumed that it is quarantined.
https://github.com/graphql-python/graphene/issues/776 https://github.com/graphql-python/graphene-django/issues/162
With relay.Connection support, the metadata on the relay.Node side is supposed to declare that it supports Node interfaces.
In graphene_sqlalchemy.SQLAlchemyConnection, if you put aNode interface declaration, it will cause a double definition, so do it well (currently it seems good to survive with a hack-like response).
You can get out of the declaration order trap by delaying the first argument of ConnectionField with lambda :.
Recommended Posts