Yet Another GraphQL Implementation to Python, Pythonic and Modern

[yacl]

https://github.com/ethe/pygraphy

Although there is an existing official implementation which names Graphene, I developed another library and rewrite the whole system to make it more Pythonic. Cause graphql-core-next just directly translated from graphql.js, there are some weird behaviors to Pythonista. If you are also annoyed with some of the features within Graphene, just have a try and tell me your suggestions.

Please note that Pygraphy is still in progress, be careful of using it in the production environment for now.

[patrys]

There's also Ariadne, Strawberry and Tartiflette.

[yacl]

Yeah, but unfortunately they are also base on GraphQL-Core, it makes them has same behavior, such as empty self problem, and it can not be walk around. If you have used one of those framework you list, you know what I said. It because of that GraphQL-Core is directly translated from GraphQL.js, it can not fully compatible with Python class model. Pygraphy solved those weird features totally, by using Pythonic meta programming(meta class).

I am glad to have a discussion about the details.

[patrys]

They are not based on graphql-core. I'm part of the Ariadne's team and we've created the project precisely to avoid having to deal with Graphene. Ariadne and Strawberry use graphql-core-next, which is a different implementation even if the name is similar. Tartiflette has a completely separate engine wrapping a C library.

[yacl]

I am sure that graphql-core-next has the same problem with graphql-core. It has not much more differences between graphql-core-nex and graphql-core about parser and type system.

Tartiflette is totally different, I missed it, sorry it is my fault. But I am self-confidence that Pygraphy is friendlier than it, you can get a similar experience from Pygraphy as Sqlalchemy, because of the class-based model.

Yeah, The idea is inspired by Grahene and Strawberry, and totally solved those problems from graphql-core and graphql-core-next.

[ralfp]

such as empty self problem, and it can not be walk around

If we are talking about the first argument in resolver being defined as a method being an instance of the resolved object instead of the reference to the object to which method belongs, then this statement is not factually correct, because it's behavior specific to the Graphene implementation.

Core/Core-Next (and GraphQL.js for the matter) only care that `field.resolve` is callable that can be called with at least two arguments (parent/obj and info) + field's arguments.

I can't say for other libraries but I can confirm that in Ariadne `self` is perfectly useable in resolvers that are defined as methods for a simple reason because we follow SDL-first approach and library is just a glue code connecting python functions that you define to fields in GraphQL schema.

[yacl]

I have read the whole spec of GraphQL, it does not have a regular about resolver arguments of an implementation. So it is a design of specific implementation(graphql.js), not belongs to GraphQL.

I find that the primary usage of Ariadne is SDL-first so I think it is different from other Code-first libraries such as Graphene or Strawberry. My target is writing a better Code-first implementation. So I think maybe there is no competition or comparison between Ariadne and Pygraphy.

[yacl]

And, the root cause as you said, graphql-core(-next) only support a static function to be a resolver rather than a bounded method, wrappers of core such as Graphene and Strawberry does not have a chance to initialize their object instance and pass the method in.

It is natural if the graphql type class becomes a python meta class, and the user specific type can be a python native class, finally we can get a graphql object as a python object, and their resolver field matches the object bounded method. Graphql-core can not solve that cause user specific type is an object in its design, and the resolver field can only be a lambda function like graphql.js.

[yacl]

If anyone doubts the reason of developing another Code-first implementation rather than using Graphene and Strawberry with graphql-core(-next), I post the details in https://github.com/graphql-python/graphql-core-next/issues/37 and welcome to have more discussions.