A Python 3.6+ port of the GraphQL.js reference implementation of GraphQL.

Overview

GraphQL-core 3

GraphQL-core 3 is a Python 3.6+ port of GraphQL.js, the JavaScript reference implementation for GraphQL, a query language for APIs created by Facebook.

PyPI version Documentation Status Build Status Coverage Status Dependency Updates Python 3 Status Code Style

The current version 3.1.2 of GraphQL-core is up-to-date with GraphQL.js version 15.1.0.

An extensive test suite with over 2200 unit tests and 100% coverage comprises a replication of the complete test suite of GraphQL.js, making sure this port is reliable and compatible with GraphQL.js.

Documentation

A more detailed documentation for GraphQL-core 3 can be found at graphql-core-3.readthedocs.io.

The documentation for GraphQL.js can be found at graphql.org/graphql-js/.

The documentation for GraphQL itself can be found at graphql.org.

There will be also blog articles with more usage examples.

Getting started

An overview of GraphQL in general is available in the README for the Specification for GraphQL. That overview describes a simple set of GraphQL examples that exist as tests in this repository. A good way to get started with this repository is to walk through that README and the corresponding tests in parallel.

Installation

GraphQL-core 3 can be installed from PyPI using the built-in pip command:

python -m pip install "graphql-core>=3"

Alternatively, you can also use pipenv for installation in a virtual environment:

pipenv install "graphql-core>=3"

Usage

GraphQL-core provides two important capabilities: building a type schema, and serving queries against that type schema.

First, build a GraphQL type schema which maps to your code base:

from graphql import (
    GraphQLSchema, GraphQLObjectType, GraphQLField, GraphQLString)

schema = GraphQLSchema(
    query=GraphQLObjectType(
        name='RootQueryType',
        fields={
            'hello': GraphQLField(
                GraphQLString,
                resolve=lambda obj, info: 'world')
        }))

This defines a simple schema with one type and one field, that resolves to a fixed value. The resolve function can return a value, a co-routine object or a list of these. It takes two positional arguments; the first one provides the root or the resolved parent field, the second one provides a GraphQLResolveInfo object which contains information about the execution state of the query, including a context attribute holding per-request state such as authentication information or database session. Any GraphQL arguments are passed to the resolve functions as individual keyword arguments.

Note that the signature of the resolver functions is a bit different in GraphQL.js, where the context is passed separately and arguments are passed as a single object. Also note that GraphQL fields must be passed as a GraphQLField object explicitly. Similarly, GraphQL arguments must be passed as GraphQLArgument objects.

A more complex example is included in the top level tests directory.

Then, serve the result of a query against that type schema.

from graphql import graphql_sync

query = '{ hello }'

print(graphql_sync(schema, query))

This runs a query fetching the one field defined, and then prints the result:

ExecutionResult(data={'hello': 'world'}, errors=None)

The graphql_sync function will first ensure the query is syntactically and semantically valid before executing it, reporting errors otherwise.

from graphql import graphql_sync

query = '{ BoyHowdy }'

print(graphql_sync(schema, query))

Because we queried a non-existing field, we will get the following result:

ExecutionResult(data=None, errors=[GraphQLError(
    "Cannot query field 'BoyHowdy' on type 'RootQueryType'.",
    locations=[SourceLocation(line=1, column=3)])])

The graphql_sync function assumes that all resolvers return values synchronously. By using coroutines as resolvers, you can also create results in an asynchronous fashion with the graphql function.

import asyncio
from graphql import (
    graphql, GraphQLSchema, GraphQLObjectType, GraphQLField, GraphQLString)


async def resolve_hello(obj, info):
    await asyncio.sleep(3)
    return 'world'

schema = GraphQLSchema(
    query=GraphQLObjectType(
        name='RootQueryType',
        fields={
            'hello': GraphQLField(
                GraphQLString,
                resolve=resolve_hello)
        }))


async def main():
    query = '{ hello }'
    print('Fetching the result...')
    result = await graphql(schema, query)
    print(result)


loop = asyncio.get_event_loop()
try:
    loop.run_until_complete(main())
finally:
    loop.close()

Goals and restrictions

GraphQL-core tries to reproduce the code of the reference implementation GraphQL.js in Python as closely as possible and to stay up-to-date with the latest development of GraphQL.js.

GraphQL-core 3 (formerly known as GraphQL-core-next) has been created as a modern alternative to GraphQL-core 2, a prior work by Syrus Akbary, based on an older version of GraphQL.js and also targeting older Python versions. Some parts of GraphQL-core 3 have been inspired by GraphQL-core 2 or directly taken over with only slight modifications, but most of the code has been re-implemented from scratch, replicating the latest code in GraphQL.js very closely and adding type hints for Python.

Design goals for the GraphQL-core 3 library are:

  • to be a simple, cruft-free, state-of-the-art implementation of GraphQL using current library and language versions
  • to be very close to the GraphQL.js reference implementation, while still using a Pythonic API and code style
  • to make extensive use of Python type hints, similar to how GraphQL.js makes uses Flow
  • to use black for automatic code formatting
  • to replicate the complete Mocha-based test suite of GraphQL.js using pytest

Some restrictions (mostly in line with the design goals):

  • requires Python 3.6 or newer
  • does not support some already deprecated methods and options of GraphQL.js
  • supports asynchronous operations only via async.io (does not support the additional executors in GraphQL-core)

Integration with other libraries and roadmap

  • Graphene is a more high-level framework for building GraphQL APIs in Python, and there is already a whole ecosystem of libraries, server integrations and tools built on top of Graphene. Most of this Graphene ecosystem has also been created by Syrus Akbary, who meanwhile has handed over the maintenance and future development to members of the GraphQL-Python community.

    The current version 2 of Graphene is using Graphql-core 2 as core library for much of the heavy lifting. Note that Graphene 2 is not compatible with GraphQL-core 3. The new version 3 of Graphene will use GraphQL-core 3 instead of GraphQL-core 2.

  • Ariadne is a Python library for implementing GraphQL servers using schema-first approach created by Mirumee Software.

    Ariadne is already using GraphQL-core 3 as its GraphQL implementation.

  • Strawberry, created by Patrick Arminio, is a new GraphQL library for Python 3, inspired by dataclasses, that is also using GraphQL-core 3 as underpinning.

Changelog

Changes are tracked as GitHub releases.

Credits and history

The GraphQL-core 3 library

  • has been created and is maintained by Christoph Zwerschke
  • uses ideas and code from GraphQL-core 2, a prior work by Syrus Akbary
  • is a Python port of GraphQL.js which has been developed by Lee Byron and others at Facebook, Inc. and is now maintained by the GraphQL foundation

Please watch the recording of Lee Byron's short keynote on the history of GraphQL at the open source leadership summit 2019 to better understand how and why GraphQL was created at Facebook and then became open sourced and ported to many different programming languages.

License

GraphQL-core 3 is MIT-licensed, just like GraphQL.js.

Comments
  • Performance of isawaitable

    Performance of isawaitable

    I've run a very simplistic benchmark, just returning a long list of single-field objects. It seems graphql-core-next is 2.5x slower than graphql-core: https://gist.github.com/ktosiek/849e8c7de8852c2df1df5af8ac193287

    Looking at flamegraphs, I see isawaitable is used a lot, and it's a pretty slow function. Would it be possible to pass raw results around more? It seems resolve_field_value_or_error and complete_value_catching_error are the main offenders here.

    optimization 
    opened by ktosiek 27
  • GraphQLSchema serialization using pickle

    GraphQLSchema serialization using pickle

    Is it possible to serialize an instance of GraphQLSchema?

    We would like to dump and load an instance of GraphQLSchema to/from a file for performance reasons.

    It does not appear to be serializable using pickle by default.

    >       res = pickle.dumps(schema)
    E       AttributeError: Can't pickle local object 'extend_schema_impl.<locals>.build_object_type.<locals>.<lambda>'
    

    Thanks in advance.

    enhancement 
    opened by rpgreen 24
  • Support adding types to GraphQLSchema

    Support adding types to GraphQLSchema

    I have a use case where part of the schema is specified using the SDL, and part of the schema is generated in code. In particular, interfaces are in SDL, while the concrete types are in code. To correctly modify the GraphQLSchema object that is generated by parsing the initial schema, you need to:

    • add the type concrete type to type_map
    • add the type to _implementations_map appropriately
    • reset _sub_type_map

    Would you be open to adding an add_type method or similar that takes care of all of the above?

    opened by alexchamberlain 14
  • The root_value of ExecutionContext.execute_operation should not be None

    The root_value of ExecutionContext.execute_operation should not be None

    Usually I want to use the custom method binded to GraphQLObjectType, such as:

    # use strawberry for example
    import strawberry
    
    
    @strawberry.type
    class User:
        name: str
        age: int
    
    
    @strawberry.type
    class Query:
        @strawberry.field
        def user(self, info) -> User:
            return self.get_user()
    
        def get_user(self):
            return User(name="Patrick", age=100)
    
    
    schema = strawberry.Schema(query=Query)
    

    Unfortunately, the self would always be None cause the root_value in ExecutionContext.execute_operation would be setted to None if it is the root node Query. I think modifying it as below is fine:

    def execute_operation(
            self, operation: OperationDefinitionNode, root_value: Any
        ) -> Optional[AwaitableOrValue[Any]]:
            """Execute an operation.
    
            Implements the "Evaluating operations" section of the spec.
            """
            type_ = get_operation_root_type(self.schema, operation)
            if not roo_value:
                root_value = type_
    

    Then we can use the custom method of GraphQLObjectType. And it not leads any problem I think.

    opened by ethe 14
  • Possible cache_key collision within collect_subfields

    Possible cache_key collision within collect_subfields

    Today I've noticed apollo-client displaying warnings in console about queried fields missing from server's response:

    Zrzut ekranu 2020-05-14 o 21 28 10

    At first I've thought that there's something wrong with Apollo client mistaking between fragments, but I've investigated server's response for query and GraphQL Playground, and realized that randomly, my query reuses result of one fragment where other fragment is expected:

    Zrzut ekranu 2020-05-14 o 22 05 12

    This result occurs at random. Sometimes I always get valid query result. Sometimes I keep running into invalid query result.

    Here's recording of this happening on Vimeo:

    https://vimeo.com/418611363

    I'm suspecting race condition within the Query executor, as it seems that moving category fields to bottom of thread seems to solve the issue, perhaps giving few more laps in the event loop for past subset to clean and new subset to be used?

    I haven't seen this error occur for first fragment used within query, only for the latter one.

    opened by rafalp 12
  • Frozenlist type only 15

    Frozenlist type only 15

    Follow up from https://github.com/graphql-python/graphql-core/pull/113

    @Cito would love your thoughts on the best approach. I chose to convert FrozenList to effectively just be an alias for Tuple.

    1. The FrozenList overrides hash (it also looks to be unsafe, in that the hash code would change if you reassigned an element, which is possible)
    2. This allowed the existing isinstance(FrozenList) checks to still exist, while actually making the type immutable.
    3. Having theses objects be truly immutable seems like a good idea, rather than simply expressing it in the type system.

    I considered using https://github.com/tobgu/pyrsistent but was hesitant to include another third party library.

    opened by corydolphin 11
  • Make nodes extensible and weak-referencable

    Make nodes extensible and weak-referencable

    Add standard dunder attributes to (almost) all instances of __slots__

    Using the test suite as a benchmark, this change produced no noticeable slow down.

    Closes #81

    opened by AstraLuma 10
  • Use explicit optional type on arguments

    Use explicit optional type on arguments

    This allows the type checks with mypy to pass in strict mode.

    The reason for this is that we run type checks with mypy using the --strict mode which includes no_implicit_optional. This means that calls like e.g.

    async def some_wrapper() -> ExecutionResult:
        schema: GraphQLSchema = ...
        query: str = ...
        variables: Optional[Dict[str, Any]] = ...
        return await graphql(schema, query, variable_values=variables)
    

    fill fail the check with an error

    src/mod.py:XXX: error: Argument "variable_values" to "graphql" has incompatible type "Optional[Dict[str, Any]]"; expected "Dict[str, Any]"
    

    A possible workaround would be maintaining a private set of type stubs for the graphql package with optional types wrapped into Optional.

    If you find the suggestion useful, I can extend this to the whole codebase. Of course, I understand that e.g.

    def execute(
        schema: GraphQLSchema,
        document: DocumentNode,
        root_value: Any = None,
        context_value: Any = None,
        variable_values: Optional[Dict[str, Any]] = None,
        operation_name: Optional[str] = None,
        field_resolver: Optional[GraphQLFieldResolver] = None,
        type_resolver: Optional[GraphQLTypeResolver] = None,
        middleware: Optional[Middleware] = None,
        execution_context_class: Optional[Type["ExecutionContext"]] = None,
    ) -> AwaitableOrValue[ExecutionResult]:
    

    starts to loose readability, but maybe it's time to introduce type aliases for common args; I find the current API great and already useable to be declared stable.

    opened by hoefling 10
  • ExecutionResult missing extensions field

    ExecutionResult missing extensions field

    GraphQL spec section 7.1 describes a 3rd response field called extensions that is intended to be used for custom data in addition to payload data and error responses. This is often used for metadata related to the query response such as performance tracing. Apollo GraphQL implements this on their server via an extensions middleware. We should probably follow a similar pattern here but we will need to support passing the extensions data to the client in the core in order to support middleware like that.

    https://graphql.github.io/graphql-spec/June2018/#sec-Response-Format

    The response map may also contain an entry with key extensions. This entry, if set, must have a map as its value. This entry is reserved for implementors to extend the protocol however they see fit, and hence there are no additional restrictions on its contents.

    investigate 
    opened by nikordaris 10
  • Disable suggestion

    Disable suggestion "Remove Did you mean..."

    Hi When you post an query with syntax errors graphql/graphene makes suggestions to you. By example, sending "i", it suggest "ID".

    query{
      users{
            i
      }
    }
    
    {
      "errors": [
        {
          "message": "Cannot query field \"i\" on type \"User\". Did you mean \"id\"?",
          "locations": [
            {
              "line": 5,
              "column": 9
            }
          ]
        }
      ]
    }
    

    Can suggestions be disabled?

    More info: Syntax analysis who add suggestions is executed before the middlewares. Apparently suggestions are made by ScalarLeafsRule class.

    opened by ckristhoff 9
  • Parser too strict on ordering after frozen lists

    Parser too strict on ordering after frozen lists

    When parsing a query, the parser adheres to the original order, even in places where order shouldn't matter (arguments). This causes the two below queries to be marked as inequal by the comparator. Recommendation would be to sort any nodes for places where order doesn't matter, as part of optional_many.

    We previously got around this issue by sorting the AST ourselves, but with the introduction of FrozenList, this now results in errors.

    E       AssertionError: queryA =
    E       {
    E         vehicle(id: 3, otherId: 2) {
    E           version
    E           cancel
    E           appointment {
    E             when
    E             afterDate
    E           }
    E           trigger {
    E             how
    E             Phase
    E             PhaseOption
    E             PhaseDelaySecs
    E           }
    E         }
    E       }
    E       
    E        queryB =
    E       {
    E         vehicle(otherId: 2, id: 3) {
    E           version
    E           cancel
    E           appointment {
    E             when
    E             afterDate
    E           }
    E           trigger {
    E             how
    E             Phase
    E             PhaseOption
    E             PhaseDelaySecs
    E           }
    E         }
    E       }
    
    discussion 
    opened by chadwhitely 9
  • A possible minor bug in ExecutionContext.complete_value

    A possible minor bug in ExecutionContext.complete_value

    I'm trying to figure out a way to return None for non-nullable fields if the requesting user doesn't have permission to view them.

    I was trying to pass Undefined from graphql.pyutils.undefined, but it doesn't work. It looks like the second check in this line

    # If result value is null or undefined then return null.
    if result is None or result is Undefined:
        return None
    

    can never run because Undefined is actually a descendant of ValueError and therefore triggers this check.

    if isinstance(result, Exception):
        raise result
    

    I don't know if this was meant as an escape hatch for returning null values if you really wanted to (which is what I really need right now), but the code itself seems wrong either way.

    bug discussion 
    opened by ipeterov 4
  • Bump certifi from 2022.9.24 to 2022.12.7

    Bump certifi from 2022.9.24 to 2022.12.7

    Bumps certifi from 2022.9.24 to 2022.12.7.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 0
  • Thanks for graphql-core!

    Thanks for graphql-core!

    Hello, thanks for graphql-core. I use it often in my projects with GraphQL.

    I created my project for pydantic model generation from some graphql schema. And for graphql queries generation from python classes. This project based on graphql-core. The project URL is https://github.com/denisart/graphql2python

    I was motivated by a famous project https://the-guild.dev/graphql/codegen/docs/getting-started. But my project so far has few settings. This will be fixed in future releases. Now you can to generate a file with pydantic classes from some GraphQL schema. You can see examples in https://denisart.github.io/graphql2python/query.html https://denisart.github.io/graphql2python/model.html

    I hope that the developments in this project can be useful for the community.

    opened by denisart 0
  • Discussion: decoupling async data loading from async graph resolution

    Discussion: decoupling async data loading from async graph resolution

    TLDR: I would like graph-core to tell me what "leaf" nodes from my query need returned. Allow me to fetch the data through whatever method I deem efficient. Then I would like graph-core to take care of returning the data. The current asyncio implementation, seems to fundamentally not work for this.

    I've been digging in deep on a graphql-core build recently and have stumbled across this interesting problem. If I've missed a key feature of the library here, than please point it out.

    To me, the ideal way to use the core library is to:

    1. Use graph-core to decide what data to retrieve.
    2. Use a separate data loading engine to read the data.
    3. Use graph-core to return the data.

    Its interesting to see where this problem fits in as either a graphe-core-3 issue, needing a feature, or a graphql issue. The essential catch is this, it's very hard to determine when the graph-core resolution has finished deciding what leaves from the graph need fetched. Here's an example to illustrate the point.

    ##########################################################
    ## TEST GRAPHE SCHEMA BASED ON ASYNCIO ######################
    ##########################################################
    from graphql import (
        GraphQLBoolean, graphql, GraphQLSchema, GraphQLObjectType, GraphQLField, GraphQLString)
    import logging
    import asyncio
    
    _logger = logging.getLogger('GrapheneDeferralTest')
    _logger.setLevel('DEBUG')
    
    query = """
    {
        ioHMIControls {
            EStopHMI,
            JogHMI,
        }
    }
    """
    
    async def resolve_EStopHMI(parent, info):
        _id = '_EStopHMI_id'
        info.context['node_ids'][_id] = None
        await info.context['awaitable']
        return info.context['node_ids'][_id]
    EStopHMI = GraphQLField(
        GraphQLBoolean,
        resolve=resolve_EStopHMI
    )
    
    async def resolve_JogHMI(parent, info):
        _id = '_JogHMI_id'
        info.context['node_ids'][_id] = None
        await info.context['awaitable']
        return info.context['node_ids'][_id]
    JogHMI = GraphQLField(
        GraphQLBoolean,
        resolve=resolve_EStopHMI
    )
    
    
    def resolve_ioHMIControls(parent, info):
        return ioHMIControls
    ioHMIControls = GraphQLObjectType(
        name='ioHMIControls',
        fields={
            'EStopHMI': EStopHMI,
            'JogHMI':JogHMI,
        }
    )
    
    def resolve_GlobalVars(parent, info):
        return GlobalVars
    GlobalVars = GraphQLObjectType(
        name='GlobalVars',
        fields={
            'ioHMIControls': GraphQLField(ioHMIControls, resolve=resolve_ioHMIControls)
        }
    )
    
    async def simulate_fetch_data(_ids):
        print(_ids)
        await asyncio.sleep(1)
        return {k:True for k in _ids.keys()}
        
    async def main():
        # Objective:
        #     1. Have graph determine what data I need by partially resolving
        #     2. Pause graph resolution.
        #     3. Collect data into a `data_loader` object.
        #     4. Retrieve data via `data_loader` object.
        #     5. Resume graph resolution with loaded data.
    
        # 3. collect ids of data fields into a dict
        _ids = {}
    
        #2. pause graph resolution by awaitn a future
        future = asyncio.Future()
        context = {
            'node_ids': _ids,
            'awaitable': future,
        }
        schema = GraphQLSchema(query=GlobalVars)
    
        # 1. Determine WHAT data to return
        resove_graph_task = asyncio.create_task(graphql(schema, query, context_value=context))
    
        # ?
        # There is no way to detect that resolve_graph_task
        # has finished fillin _ids dict with id values.
    
        # 4. Fetch the data
        fetch_data_task = asyncio.create_task(simulate_fetch_data(_ids))
    
        # ? 
        # This await doesn't work in this order or any order
        # becaus of the interdependancy of both tasks, coupled with 
        # the mechanics of asyncio.
        await fetch_data_task
    
        # 5. Resume graph resolution with retrieved data.
        future.set_result(0)
    
        # ? 
        # return the data from the graph, as a graph result. 
        # problem, is that the data is not there due to 
        # interdependancy between await tasks. 
        result = await resove_graph_task
        print(result)
    
    if __name__ == '__main__':
        asyncio.run(main())
    

    Results

    {}
    ExecutionResult(data={'ioHMIControls': {'EStopHMI': None, 'JogHMI': None}}, errors=None)
    

    The example is a little long, but I wanted it to be sufficiently complex. The gist is that there is no way in the current asyncio implementation to determine that: all resolvers have been reached.

    Looking at the implementations we could use some advanced event systems to manage this, but it would be a bit of work. Another possible solution could be to allow resolvers to return coroutines and put off type checking till those coroutines are themselves resolved. I think, this may be the most elegant method.

    Thoughts?

    opened by jmarshall9120 0
  • `exclude_unset` fields flag for removing fields that are not passed from the client to the server

    `exclude_unset` fields flag for removing fields that are not passed from the client to the server

    PR - https://github.com/graphql-python/graphql-core/pull/168

    I use graphene and graphene-pydantic libraries. Code example. You can run this for testing. https://gist.github.com/dima-dmytruk23/aaeba0fbc7a539c1f8bf3d0914fce580

    The client does not pass the name field, but it is still present in the mutation as None. Input query turns into a UserUpdateInput, which is when the default values are filled in to the dictionary. So then when code passes the dictionary in to build the UserUpdate, it sets all the fields -- so exclude_unset doesn't exclude anything, since all the fields were in fact set.

    I am fairly sure it's not in graphene-pydantic, though, since that is only responsible for converting to the GrapheneInputObjectType.

    I propose to resolve this issue by adding the exclude_unset flag to the GraphQLSchema class and use it in the coerce_input_value function.

    opened by dima-dmytruk23 1
  • Exclude unset fields

    Exclude unset fields

    Original discussion: https://github.com/graphql-python/graphene-pydantic/pull/75

    I use graphene and graphene-pydantic libraries. Code example: https://gist.github.com/dima-dmytruk23/aaeba0fbc7a539c1f8bf3d0914fce580

    The client does not pass the name field, but it is still present in the mutation as None. Input query turns into a UserUpdateInput, which is when the default values are filled in to the dictionary. So then when your code passes the dictionary in to build the UserUpdate, it sets all the fields -- so exclude_unset doesn't exclude anything, since all the fields were in fact set.

    I am fairly sure it's not in graphene-pydantic, though, since that is only responsible for converting to the GrapheneInputObjectType.

    I propose to resolve this issue by adding the exclude unset flag to the GraphQLSchema class and use it in the coerce_input_value function.

    opened by dima-dmytruk23 1
Releases(v3.3.0a2)
  • v3.3.0a2(Nov 3, 2022)

    Alpha release GraphQL-core v3.3.0a2, still based on GraphQL.js v17.0.0a1.

    This alpha release already ports some of the changes in GraphQL.js v17.0.0a2. There will be another alpha release with the remaining changes soon. This alpha release also adds the following new features:

    • Solve issues with pickled schemas (#173)
    • Use type guards (#183)

    Thanks to all who are sponsoring me (@Cito), particularly to Vendia for sponsoring the work on #173, and to others who contributed, particularly to @helderco for the suggestion to use type guards.

    Source code(tar.gz)
    Source code(zip)
  • v3.3.0a1(Sep 24, 2022)

    Alpha release GraphQL-core v3.3.0a1, based on GraphQL.js v17.0.0a1.

    This alpha release ports all of the changes in GraphQL.js v17.0.0a1.

    Note that his means the removal of several functions that had been marked as deprecated before.

    Other noteable changes:

    • starting with this alpha release, Python 3.6 is no longer supported
    • we use the new dependency groups feature of poetry (#177)
    • support for setuptools has been removed, builds must be done with poetry (#178)
    • we now use bugbear and bandit to detect possible security problems and code flaws

    Thanks again to all who are sponsoring me (@Cito) and thereby motivated me to continue maintaining this project.

    Source code(tar.gz)
    Source code(zip)
  • v3.2.3(Sep 23, 2022)

    Patch-release GraphQL-core v3.2.3, based on GraphQL.js v16.6.0.

    This patch-releases includes only one change in GraphQL.js v16.6.0:

    • The parser now allows to limit the number of tokens

    Thanks to all who are sponsoring me (@Cito) for maintaining this project.

    Source code(tar.gz)
    Source code(zip)
  • v3.2.2(Sep 22, 2022)

    Patch-release GraphQL-core v3.2.2, based on GraphQL.js v16.4.0.

    This patch-releases includes the changes in GraphQL.js v16.4.0, and the following fixes:

    • Require typing extensions when needed
    • Recommend using poetry instead of pipenv in the docs (#161)
    • Cast error message to string to handle proxy objects (#175)
    • Remove newline in description (#180)

    Thanks to @chenrui333, @conao3, @jkimbo, @singingwolfboy for contributing and to all who are sponsoring me (@Cito) for maintaining this project.

    Source code(tar.gz)
    Source code(zip)
  • v3.2.1(Apr 6, 2022)

    Patch-release GraphQL-core v3.2.1, based on GraphQL.js v16.3.0.

    This patch-releases includes the changes in GraphQL.js v16.3.0, and the following fix:

    • Serialize with maximum precision when converting float to FloatValue (#164)

    Thanks to @bennyweise for contributing and all who are sponsoring me (@Cito) for maintaining this project.

    Source code(tar.gz)
    Source code(zip)
  • v3.2.0(Jan 15, 2022)

  • v3.2.0rc5(Jan 15, 2022)

    Pre-release GraphQL-core v3.2.0rc5, based on GraphQL.js v16.1.0.

    In addition to porting the recent changes in GraphQL.js, this pre-release also contains the following improvements:

    • Add flag for using enum names or members as values (#73)
    • Add typed dicts for to_kwargs results (#99)
    • Add ast_to_dict utility function (#136)
    • Make print_block_string work with string proxy objects (#153)
    • Prevent infinite loop in OverlappingFieldsCanBeMergedRule (fetched ahead)

    Please test this pre-release and report any issues, the final release is imminent.

    Source code(tar.gz)
    Source code(zip)
  • v3.2.0rc4(Dec 29, 2021)

    Pre-release GraphQL-core v3.2.0rc4, based on GraphQL.js v16.0.1.

    In addition to porting the recent changes in GraphQL.js, this pre-release also contains the following improvements:

    • Use typed dictionaries for introspection results (#99)
    • Deprecate FrozenDict/List, use tuples as node lists (#112)
    • Experimental support for async iterables as list values (#123)
    • Make print_block_string work with string proxy objects (#153)

    Note that the use of tuples may break code that tries to modify the AST.

    Please test this pre-release and report any issues, the final release is imminent.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.6(Dec 29, 2021)

  • v3.2.0rc3(Dec 12, 2021)

    Pre-release GraphQL-core v3.2.0rc3, based on GraphQL.js v16.0.0rc3.

    In addition to porting the recent changes in GraphQL.js, this pre-release also contains the following improvements:

    • Add sync and async execution benchmarks (#141)
    • Minor code simplifications (#146)
    • Optimize node hash method through caching (#150)
    • Optimize performance of character class predicates
    • Include Python 3.10 in default test matrix
    Source code(tar.gz)
    Source code(zip)
  • v3.1.7(Dec 12, 2021)

    Patch release GraphQL-core v3.1.7, based on GraphQL.js v15.8.0.

    This release includes minor changes and improvements, in particular:

    • Set enum value values to value names in build_client_schema (#138)
    • Fix camel to snake case conversion with digits (#140)
    • Preserve deprecation_reason on GraphQLInputFields (d1ffaef2ec3e5e475cb8ae52397489fd05ea6a12)
    • Add missing __Directive.args(includeDeprecated) (0df0a32fe9cae2edafdd985f099490b55dca13e2)
    • Fix original_error.extensions overriding extensions argument (810d712ca53e5356027e6930b9585cf56152d3f5)
    Source code(tar.gz)
    Source code(zip)
  • v3.2.0rc2(Sep 30, 2021)

  • v3.2.0rc1(Sep 29, 2021)

    Pre-release GraphQL-core v3.2.0rc1, based on GraphQL.js v16.0.0rc2.

    In addition to porting the recent changes in GraphQL.js, this pre-release also contains the following improvements:

    • Set enum value values to value names in build_client_schema (#138)
    • Fix camel to snake case conversion with digits (#140)
    • Support Python 3.10
    Source code(tar.gz)
    Source code(zip)
  • v3.1.6(Aug 20, 2021)

  • v3.1.5(May 10, 2021)

    Patch release GraphQL-core v3.1.5, based on GraphQL.js v15.4.0.

    This release includes the following changes and imrovements:

    • Default parse_literal of GraphQLScalarType now handles variables
    • build_ast_schema now matches order of default types and directives
    • Return formatted errors in formatted execution result (fixes #129)
    • The is_deprecated property is now deprecated itself
    • Input fields and arguments can now be marked as deprecated
    • Handle case when MapAsyncIterator is cancelled (#131)
    • Improve return type for complete_list_value (#132)
    • Replace resolved types in lexicographic schema sort
    • EventEmitter helper class has been replaces by SimplePubSub
    • print_ast now breaks arguments over multiple lines

    Special thanks to @cancan101, @mlorenzana, @wuyuanyi135 for contributing.

    Source code(tar.gz)
    Source code(zip)
  • v3.1.4(Apr 8, 2021)

    Patch release GraphQL-core v3.1.4, based on GraphQL.js v15.3.0.

    This release fixes issues #125 and #126 regarding enum values.

    Thanks to @dkbarn for reporting the problem.

    Source code(tar.gz)
    Source code(zip)
  • v3.1.3(Feb 8, 2021)

    Patch release GraphQL-core v3.1.3, based on GraphQL.js v15.2.0.

    This release includes the following improvements:

    • Python 3.9 is now officially suported by GraphQL-core.
    • build_schema: allow to reference introspection types
    • Custom validation rules for "no schema introspection" and "no deprecated"
    • Added execute_sync() as synchronous version of execute()
    • Support deep copy of GraphQL schema (#100)
    • build_ast_schema now sets internal enum values (#111)
    • Do not double-wrap resolver errors any more (#106)
    • Use newer Sphinx version, fix for various autodoc issues (#104)
    • Fix example in docstring of GraphQLUnionType (#105)
    • Let default resolver check for Mapping instead of dict (#102)

    Thanks to everyone who helped with their feedback, particularly

    @berekuk, @charmasaur, @Checho3388, @jstlaurent and @pmantica1.

    Source code(tar.gz)
    Source code(zip)
  • v3.1.2(Jul 5, 2020)

    Patch release GraphQL-core v3.1.2, based on GraphQL.js v15.1.0.

    This release includes the following improvements:

    • Added @specifiedBy directive
    • Extended type definitions (#89)
    • Enum type for visitor return values (#96)
    • Visitors can now use class and static methods
    • Lists in AST nodes are not optional any more (#98)

    Thanks to everyone who helped with their feedback.

    Source code(tar.gz)
    Source code(zip)
  • v3.1.1(May 18, 2020)

    Bugfix release GraphQL-core v3.1.1, based on GraphQL.js v15.0.0.

    The following issues are fixed in this release:

    • Fixed rendering of ReST in docstring (#84, #85, #86, #87)
    • Added type hint to default_field_resolver (#88)
    • Fixed memoization of collect_subfields (#91)
    • Fixed method name in Visitor docstring (#92)

    Contributors to this release were:

    @Cito, @hoefling, @nawatts, @rafalp

    Thanks to everyone who helped by sending bug reports or pull requests.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.5(May 18, 2020)

    Bugfix release GraphQL-core v3.0.5, based on GraphQL.js v14.6.0.

    The following issues are fixed in this release:

    • Added type hint to default_field_resolver (#88)
    • Fixed memoization of collect_subfields (#91)
    • Fixed method name in Visitor docstring (#92)

    Contributors to this release were:

    @Cito, @hoefling, @nawatts, @rafalp

    Thanks to everyone who helped by sending bug reports or pull requests.

    Source code(tar.gz)
    Source code(zip)
  • v3.1.0(Apr 3, 2020)

  • v3.0.4(Apr 3, 2020)

  • v3.1.0b2(Mar 21, 2020)

    Third beta release of GraphQL-core 3.1, based on GraphQL.js v15.0.0rc2.

    In addition to incorporating the latest changes from the master branch of GraphQL.js, this release also contains the following improvements:

    • Increased performance by using a faster isawaitable() function (#54).
    • Nodes and some other objects are now extensible and weak-referencable (#82).

    We also renamed the repository on GitHub from graphql-python/graphql-core-next to graphql-python/graphql-core.

    Contributors to this release were:

    @Cito, @astronouth7303, @Hellzed and @qeternity

    Thanks to everybody who contributed by sending bug reports or pull requests. Please continue to report any problems you find in this beta release, so that these can be fixed in the final v3.1 release.

    Source code(tar.gz)
    Source code(zip)
  • v3.1.0b1(Mar 4, 2020)

    Second beta release of GraphQL-core 3.1, based on GraphQL.js v15.0.0rc2.

    In addition to incorporating the latest changes in GraphQL.js v15.0.0rc2, this release also contains the following improvements and changes:

    • Following a change in GraphQL.js to keep the order of user provided types, the type map reducer for the GraphQLSchema has been removed.
    • We now support inheritance when evaluating the __typename attribute (#25).
    • FieldNodes and InputValueNodes are now only DefinitionNodes, not TypeDefinitionNodes.
    • The test suite now has 100% coverage, and less coverage will count as failure.

    Contributors to this release were:

    @Cito, @Hellzed

    Thanks to everybody who contributed by sending bug reports or pull requests. Please continue to report any problems you find in this beta release, so that these can be fixed in the final v3.1 release.

    Source code(tar.gz)
    Source code(zip)
  • v3.1.0b0(Feb 10, 2020)

    First beta release of GraphQL-core 3.1, based on GraphQL.js v15.0.0rc1.

    In addition to incorporating the latest changes from GraphQL.js (see the list of changes in GraphQL.js v15.0.0a1, v15.0.0a2 and v15.0.0rc1), this release also contains the following improvements and changes:

    • Change: Use Undefined instead of INVALID which is now deprecated (#77)
    • Use explicit Optional type on arguments (#76)
    • Remove unnecessary result type annotation from __init__ methods (python/mypy#5677)
    • Better docstring for ast_from_value
    • Better docstring for lexicographic_sort_schema (#75)
    • Fixed a minor issue when coverting lists in ast_from_value()
    • Fixed a minor issue with MapAsyncIterator.athrow()
    • Improved test coverage (trying to reach 100% for final release)

    Contributors to this release were:

    @Cito, @hoefling

    Thanks to everybody who contributed by sending bug reports or pull requests. Please continue to report any problems you find in this beta release, so that these can be fixed in the final v3.1 release.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.3(Feb 2, 2020)

    Patch release of GraphQL-core 3, based on GraphQL.js v14.6.0.

    This is essentially the same as version 3.0.2 except for one minor change:

    • Added Undefined as a forward compatible alias for INVALID, which should be imported from the top level.
    Source code(tar.gz)
    Source code(zip)
  • v3.0.2(Jan 26, 2020)

    Patch release of GraphQL-core 3, based on GraphQL.js v14.6.0.

    This is essentially the same as version 3.0.1 except for one minor change:

    • Added the missing validation rules that could not be imported from the graphql and graphql.validation packages.

    Some requirements have also been updated, and we officially support Python 3.8 now.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.1(Dec 6, 2019)

    Patch release of GraphQL-core 3, based on GraphQL.js v14.5.8.

    This is essentially the same as version 3.0.0 except for one minor change:

    • The utilities.get_introspection_query module has been renamed back to utilities.introspection_query, since that was the name used in GraphQL.js v14.5.8 - renaming the module will be postponed to a version that replicates GraphQL.js v15.0.0.

    Note that the introspection_query constant was already deprecated in v14 and had not been ported to graphql-core, like some other deprecated features.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.0(Nov 30, 2019)

    Final release of GraphQL-core 3, based on GraphQL.js v14.5.8.

    GraphQL-core 3 is the successor to both GraphQL-core 2 and GraphQL-core-next.

    In addition to porting the minor changes in GraphQL.js since v14.5.6, this release also contains the following improvements:

    • GraphQL-core 3 now officially supports Python 3.8
    • Use mypy 0.750 and the new semantic analyzer (#67)
    • Fix for possible sort errors in build_response() (#68)
    • Document the differences between GraphQL-core 3 and GraphQL.js (#24)

    See also the changes in v3.0.0b0 and v3.0.0b1.

    Contributors to this release were:

    @Cito, @tebanep

    Thanks to everyone who sent bug reports or pull requests.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.0b1(Sep 26, 2019)

    Second beta release of GraphQL-core 3, based on GraphQL.js v14.5.6.

    GraphQL-core 3 is the successor to both GraphQL-core 2 and GraphQL-core-next.

    In addition to incorporating the latest changes from GraphQL.js (see particularly the list of changes in GraphQL.js v14.5.5), this release also contains the following improvements and changes:

    • Changes: format_error now returns locations as a list of dicts (#62)
    • Bugs: Detect args passed to directive without args (#63)

    Contributors to this release were:

    @Cito, @Dodobibi, @ktosiek

    Thanks to everybody who contributed by sending bug reports or pull requests. Please continue to report any problems you find in this beta release, so that these can be fixed in the final v3 release.

    Source code(tar.gz)
    Source code(zip)
Owner
GraphQL Python
GraphQL Python
GraphiQL & the GraphQL LSP Reference Ecosystem for building browser & IDE tools.

Black Lives Matter ?? GraphQL IDE Monorepo Security Notice: All versions of graphiql < 1.4.7 are vulnerable to an XSS attack in cases where the GraphQ

GraphQL 14.5k Jan 8, 2023
MGE-GraphQL is a Python library for building GraphQL mutations fast and easily

MGE-GraphQL Introduction MGE-GraphQL is a Python library for building GraphQL mutations fast and easily. Data Validations: A similar data validation w

MGE Software 4 Apr 23, 2022
GraphQL security auditing script with a focus on performing batch GraphQL queries and mutations

BatchQL BatchQL is a GraphQL security auditing script with a focus on performing batch GraphQL queries and mutations. This script is not complex, and

Assetnote 267 Dec 24, 2022
A Django GraphQL Starter that uses graphene and graphene_django to interface GraphQL.

Django GraphQL Starter GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data... According to the doc

0101 Solutions 1 Jan 10, 2022
Graphql-codegen library - a pure python implementation

turms DEVELOPMENT Inspiration Turms is a pure python implementation of the awesome graphql-codegen library, following a simliar extensible design. It

Johannes Roos 22 Dec 23, 2022
GraphQL framework for Python

Graphene ?? Join the community on Slack We are looking for contributors! Please check the ROADMAP to see how you can help ❤️ The below readme is the d

GraphQL Python 7.5k Jan 1, 2023
GraphQL framework for Python

Graphene ?? Join the community on Slack We are looking for contributors! Please check the ROADMAP to see how you can help ❤️ The below readme is the d

GraphQL Python 7.5k Jan 1, 2023
Ariadne is a Python library for implementing GraphQL servers using schema-first approach.

Ariadne Ariadne is a Python library for implementing GraphQL servers. Schema-first: Ariadne enables Python developers to use schema-first approach to

Mirumee Labs 1.9k Jan 1, 2023
GraphQL Engine built with Python 3.6+ / asyncio

Tartiflette is a GraphQL Server implementation built with Python 3.6+. Summary Motivation Status Usage Installation Installation dependencies Tartifle

tartiflette 839 Dec 31, 2022
A new GraphQL library for Python 🍓

Strawberry GraphQL Python GraphQL library based on dataclasses Installation ( Quick Start ) The quick start method provides a server and CLI to get go

Strawberry GraphQL 2.8k Jan 1, 2023
A python graphql api, which serves ECB currency rates from last 90 days.

Exchange Rate Api using GraphQL Get Code git pull https://github.com/alaturqua/exchangerate-graphql.git Create .env file with following content and s

Isa 1 Nov 4, 2021
This is a simple Python that will parse instanceStats GraphQL Query into a CSV

GraphQL Python Labs - by Gabs the CSE Table of Contents About The Project Getting Started Prerequisites Installation and Usage Roadmap Contributing Li

Gabriel (Gabs) Cerioni 1 Oct 27, 2021
Pygitstats - a package that allows you to use the GitHub GraphQL API with ease in your Python programs

Pygitstats - a package that allows you to use the GitHub GraphQL API with ease in your Python programs

Dillon Barnes 4 Mar 29, 2022
tartiflette-aiohttp is a wrapper of aiohttp which includes the Tartiflette GraphQL Engine, do not hesitate to take a look of the Tartiflette project.

tartiflette-aiohttp is a wrapper of aiohttp which includes the Tartiflette GraphQL Engine. You can take a look at the Tartiflette API documentation. U

tartiflette 60 Nov 8, 2022
ASGI support for the Tartiflette GraphQL engine

tartiflette-asgi is a wrapper that provides ASGI support for the Tartiflette Python GraphQL engine. It is ideal for serving a GraphQL API over HTTP, o

tartiflette 99 Dec 27, 2022
GraphQL is a query language and execution engine tied to any backend service.

GraphQL The GraphQL specification is edited in the markdown files found in /spec the latest release of which is published at https://graphql.github.io

GraphQL 14k Jan 1, 2023
Integrate GraphQL into your Django project.

Graphene-Django A Django integration for Graphene. ?? Join the community on Slack Documentation Visit the documentation to get started! Quickstart For

GraphQL Python 4k Dec 31, 2022
Adds GraphQL support to your Flask application.

Flask-GraphQL Adds GraphQL support to your Flask application. Usage Just use the GraphQLView view from flask_graphql from flask import Flask from flas

GraphQL Python 1.3k Dec 31, 2022
A library to help construct a graphql-py server supporting react-relay

Relay Library for GraphQL Python GraphQL-relay-py is the Relay library for GraphQL-core. It allows the easy creation of Relay-compliant servers using

GraphQL Python 143 Nov 15, 2022