Path to 0.5.0

[syrusakbary]

Version 0.5.0 compatible with the GraphQL Apr 2016 spec.
Related Pull Requests: #54 #59

Features

• Improve error handling Improve Error Handling #41
• Add ability to add custom errors (inheriting from GraphQLError)
• Expose all the function and classes
• Move modules from graphql.core.* to graphql.*
• Make tests relative to the directories
• Isolate promise package into own package in PyPI pypromise ☺️

Breaking changes

Improve the executor to be closer to the reference implementation:

• Uses Promise instead of Deferred as it simplifies the implementation. Use parallel resolvers automatically as default behavior when available. Related PR: Use Promises in execute context #59

Commit Checklist

Implement the commits from GraphQL-js:

• Allow edit nodes on enter and on leave: graphql/graphql-js@ecfdb3b + graphql/graphql-js@d2c005a
• Nit: fix missing quote in error message: graphql/graphql-js@db0924a
• Add test for parseLiteral on ComplexScalar: graphql/graphql-js@b3a5127
• Extract completeListValue function from CompleteValue: graphql/graphql-js@57d71e1...7a15a3f + graphql/graphql-js@533fc43
• [RFC] Proposed change to directive location introspection: graphql/graphql-js@e89c19d
• Fix error message for missing operation + tests: graphql/graphql-js@debf3d1 graphql/graphql-js@3278e86
• [RFC] Directives in schema language: graphql/graphql-js@fdafe32
• Updating schema parser to more closely match current state of RFC: graphql/graphql-js@b0885a0
• [RFC] Add Schema Definition to IDL graphql/graphql-js@8379e71
• Remove unused function parameters graphql/graphql-js@43992e3
• Include test for extending a schema that uses Enums graphql/graphql-js@37924d2
• Cache client schema exe function, and include test for unreferenced interface graphql/graphql-js@1083c7e
• Naming similarity graphql/graphql-js@3f6a7f4
• Move getTypeOf to execute.js and rename to defaultResolveTypeFn to mirror defaultResolveFn graphql/graphql-js@edc405a + graphql/graphql-js@a781b55
• Add tests and refine default resolve function. graphql/graphql-js@d506c23
• Add GraphQLSchema types field graphql/graphql-js@6a1f23e + Fix test graphql/graphql-js@09be751
• [RFC] Add explicit context arg to graphql execution graphql/graphql-js@d7cc6f9
• Improve coercion error messages graphql/graphql-js@dea5aac + Minor touch ups: graphql/graphql-js@136630f
• Clean up tests graphql/graphql-js@8514211
• Fix bug where @include directive is ignored if @Skip is present. graphql/graphql-js@d6da0bf + Spec compliant @skip/@include graphql/graphql-js@47f87fa
• Fix tests on abstract type invariant graphql/graphql-js@cf5b234
• Remove non spec compliant test graphql/graphql-js@07e627a
• Add tests for type comparators graphql/graphql-js@3201ebb
• Add sanity checks for schema to allow only a single query, mutation, subscription in schema graphql/graphql-js@ffe76c5
• RFC: Return type overlap validation graphql/graphql-js@c034de9

[Globegitter]

@syrusakbary We have been looking a lot into a parallel middleware in our app (on Python 2.7). I was planning on open sourcing them, but the one we currently use is a simple ThreadPool middleware (the gevent middleware turned out not to be compatible with our app because we use grpc). That has its own issues though because it actually is spinning off threads. So our latest approach would be to use Futures (grpc is also using futures), which has a nice backport to python 2.7: https://github.com/agronholm/pythonfutures as well with an additional package to make it then-able: https://github.com/dvdotsenko/python-future-then

Apart from the fact that this would be neater for our app (so I will already be slightly more biased towards a futures solution), I also do think it is the more pythonic solution and more and more projects (like grpc) do actually implement the futures interface. So this would in my opinion, generally make it easier to integrate with the parallel middleware.

Since this is something that we need in our app and it has been on our internal TODO, that might be something that I, or possibly one of my colleagues could tackle. But the earliest for me would be sometime towards end of next week.

cc @alamaison

[sdcooke]

I've ported a few more commits:

Add to unit tests to ensure test accepts both edits of enter and leave: graphql/graphql-js@d2c005a
in graphql-python/graphql-core#56

Add test for parseLiteral on ComplexScalar: graphql/graphql-js@b3a5127
in graphql-python/graphql-core#57

Extract completeListValue funciton from CompleteValue: graphql/graphql-js@ab77470
Extract completeLeafValue from CompleteValue: graphql/graphql-js@4c5904c
Extract completeObjectValue from CompleteValue: graphql/graphql-js@5a13648
Extract completeAbstractValue from CompleteValue: graphql/graphql-js@d484f31
Add invariant for unreachable condition: graphql/graphql-js@7a15a3f
in graphql-python/graphql-core#58

Nit: fix missing quote in error message: graphql/graphql-js@db0924a
is already fixed so doesn't need doing

[syrusakbary]

@Globegitter I think using futures is reasonable given the python context.
The main goal for using Promises is simplify the executor classes for only have one that could work in any case (sync or async resolver resolution).

If we could achieve it in a simple way with futures I think would be a good idea to use it instead of Promises. (Seems could be completely possible by using python-future-then 😉 )

[syrusakbary]

@sdcooke you did a great work!

[syrusakbary]

@Globegitter after researching and trying to implement using only futures I realized that everything would work great if we "promesify" the Futures automatically and have the advantages of using Promises at the same time.

So we can have the nice approach of Promises, but allowing the developer to use either a Deferred or Future if they want to. The Promise approach will not force any way for choosing how will be the executor (if asyncio, concurrent.futures, a Thread pool and so on), but will be only a layer on top of that.

[Globegitter]

@syrusakbary That sounds like a quite good option. What exactly would 'promesifying' Futures in your opinion mean? Would this just be adding the .then interface or more than that? I suppose a .catch could be quite handy as well.

[syrusakbary]

@Globegitter What I meant with promesifying Futures is wrapping each future in a Promise (will be done in the grapqhl library, with no extra effort from the developer).

Here is the related PR for Promises, if you want a take al look.
graphql-python/graphql-core#59

And here is the code for each executor... you might find useful too!
https://github.com/graphql-python/graphql-core/tree/features/promises/graphql/execution/executors

[Globegitter]

Thanks, that is amazing progress @syrusakbary! Also this might be part of fixing #41 but it seems in your PR to 0.4.14 you missed: graphql/graphql-js@3d27953

[syrusakbary]

@Globegitter I skipped intentionally this as we already pass the originalError to the GraphQLError exception.
https://github.com/graphql-python/graphql-core/blob/master/graphql/core/execution/executor.py#L230

Maybe what is not as obvious and need to be improved is that this original error is in the stack attr of the GraphQLError.
https://github.com/graphql-python/graphql-core/blob/master/graphql/core/error.py#L15

[syrusakbary]

@sdcooke any other port of the graphql-js commits will be welcome! 😉

[sdcooke]

I haven't disappeared! Just not finding enough time to get to it right now. I'm currently battling against relay connections in graphene!

[syrusakbary]

All the changes are now in the master branch. Closing this issue :)

[Globegitter]

Wow that's amazing progress. Great job @syrusakbary! :)

[syrusakbary]

This new graphql-core version will be pushed to PyPI soon.
I'm working in updating all external dependencies (aka graphene, graphql_relay, graphql-django-view, django-graphiql, flask-graphql) to support the new code structure and upload a new version for them too.