A new GraphQL library for Python 🍓

Overview

Strawberry GraphQL

Python GraphQL library based on dataclasses

CircleCI Discord PyPI

Installation ( Quick Start )

The quick start method provides a server and CLI to get going quickly. Install with:

pip install strawberry-graphql[debug-server]

Getting Started

Create a file called app.py with the following code:

import strawberry


@strawberry.type
class User:
    name: str
    age: int


@strawberry.type
class Query:
    @strawberry.field
    def user(self, info) -> User:
        return User(name="Patrick", age=100)


schema = strawberry.Schema(query=Query)

This will create a GraphQL schema defining a User type and a single query field user that will return a hardcoded user.

To run the debug server run the following command:

strawberry server app

Open the debug server by clicking on the following link: http://0.0.0.0:8000/graphql

This will open GraphiQL where you can test the API.

Type-checking

Strawberry comes with a mypy plugin that enables statically type-checking your GraphQL schema. To enable it, add the following lines to your mypy.ini configuration:

[mypy]
plugins = strawberry.ext.mypy_plugin

Django Integration

A Django view is provided for adding a GraphQL endpoint to your application.

  1. Add the app to your INSTALLED_APPS.
INSTALLED_APPS = [
    ...
    'strawberry.django',
]
  1. Add the view to your urls.py file.
from strawberry.django.views import GraphQLView
from .schema import schema

urlpatterns = [
    ...,
    path('graphql', GraphQLView.as_view(schema=schema)),
]

WebSockets

To support graphql Subscriptions over WebSockets you need to provide a WebSocket enabled server. The debug server can be made to support WebSockets with these commands:

pip install strawberry-graphql[debug-server]
pip install uvicorn[standard]

Contributing

We use poetry to manage dependencies, to get started follow these steps:

git clone https://github.com/strawberry-graphql/strawberry
cd strawberry
poetry install
poetry run pytest

This will install all the dependencies (including dev ones) and run the tests.

Pre commit

We have a configuration for pre-commit, to add the hook run the following command:

pre-commit install

Links

Licensing

The code in this project is licensed under MIT license. See LICENSE for more information.

Comments
  • Add basic Channels integration

    Add basic Channels integration

    Description

    This is a draft PR implementing #1408 - so far it has pretty good coverage of the websocket side of things, but I need to finish:

    • the HTTP consumer
    • the high level API for the Channels Layers, to make it easy to work with, especially if you're in a sync Django view.
    • some more unit tests, especially in relation to the http consumer

    I've just rewritten the PR to make the commits a little tidier, and also to clean up the implementation of the consumers which I wasn't happy with.

    I'm currently treating it as separate from the Django integration, with its own package path in strawberry.channels - I can imagine before long all the integrations might get consolidated in a common namespace but for now I'm sticking with the same style as FastAPI, aiohttp, etc.

    The most likely use case for this will be using it to provide subscriptions support on Django, with the channels layer offering a pretty nice way to integrate it with the rest of a Django project, even if it is a mostly synchronous one.

    I've been building some tests, mostly re-using tests from the other GraphQL integrations (I have been wondering as well, do we really need separate test suites for each integration when it comes to websockets? Seems like something that could be done once for all of them, except perhaps for the issue that the context isn't implemented consitently?)

    The Channels integration is pretty small and simple to be honest - the biggest part of this is likely to actually be a good example and some documentation (like a how-to) on how this can actually be used. I have something in progress for that, which I figure I should PR to the strawberry/examples repo...

    The main thing I'm working on now that the websockets consumer implementation is fairly stable is to add the Layers high level API to make it easy to integrate with a Django app. See the issue ticket for thoughts on this.

    Types of Changes

    • [ ] Core
    • [ ] Bugfix
    • [x] New feature
    • [ ] Enhancement/optimization
    • [ ] Documentation

    Issues Fixed or Closed by This PR

    Checklist

    • [x] My code follows the code style of this project.
    • [x] My change requires a change to the documentation.
    • [x] I have updated the documentation accordingly.
    • [x] I have read the CONTRIBUTING document.
    • [ ] I have added tests to cover my changes.
    • [ ] I have tested the changes and verified that they work and don't break anything (as well as I can manage).
    ok-to-preview bot:has-release-file bot:release-type-minor 
    opened by LucidDan 38
  • [bug?] custom directives have their first argument cut off during introspection

    [bug?] custom directives have their first argument cut off during introspection

    $ pip freeze | grep strawberry
    strawberry-graphql==0.96.0
    

    Here's a quick repro:

    import strawberry
    from strawberry.directive import DirectiveLocation
    from typing import Optional
    
    @strawberry.directive(locations=[DirectiveLocation.QUERY])
    def hello_world(
        foo: str,
        bar: str,
        baz: str,
    ):
        pass
    
    
    @strawberry.type
    class Query:
        _service: Optional[str]
    
    
    schema = strawberry.federation.Schema(query=Query, directives=[hello_world])
    print(schema.execute_sync("""
        query SubgraphIntrospectQuery {
            _service {
                sdl
            }
        }
    """).data['_service']['sdl'])
    
    $ python test.py
    directive @helloWorld(bar: String!, baz: String!) on QUERY
    
    type Query {
      _service: _Service!
      Service: String
    }
    
    scalar _Any
    
    type _Service {
      sdl: String!
    }
    

    Let's zoom in on that directive SDL: directive @helloWorld(bar: String!, baz: String!) on QUERY - what happened to thefoo arg?

    I guess this behaviour is coming from the slicing here: https://github.com/strawberry-graphql/strawberry/blob/b8ead94d0cceb9eb5f9a6ea5a37123efd9bf48a3/strawberry/directive.py#L26

    opened by magicmark 25
  • Fix compatibility with starlette 0.18.0 and above

    Fix compatibility with starlette 0.18.0 and above

    Description

    Types of Changes

    • [ ] Core
    • [x] Bugfix
    • [ ] New feature
    • [ ] Enhancement/optimization
    • [ ] Documentation

    Issues Fixed or Closed by This PR

    • Closes #1593

    Checklist

    • [ ] My code follows the code style of this project.
    • [ ] My change requires a change to the documentation.
    • [ ] I have updated the documentation accordingly.
    • [ ] I have read the CONTRIBUTING document.
    • [ ] I have added tests to cover my changes.
    • [x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).
    bot:has-release-file bot:release-type-minor 
    opened by TimPansino 21
  • Allow to use init=False on fields

    Allow to use init=False on fields

    Pretty much like dataclasses we should allow to skip fields from being included in the init method, like this:

    @strawberry.type
    class IceCream:
        num_scoops: int
        sequence_scoops: List['Flavour']
        example: str = dataclasses.field(init=False)
    

    We should be able to do this:

    @strawberry.type
    class IceCream:
        num_scoops: int
        sequence_scoops: List['Flavour']
        example: str = strawberry.field(init=False)
    

    Edit:

    We should also support default and default_factory on strawberry.field

    enhancement good first issue Hacktoberfest 
    opened by patrick91 20
  • Update GraphiQL page to the latest version

    Update GraphiQL page to the latest version

    Description

    Updated the GraphiQL page to use [email protected] (was previously using [email protected]).

    This is necessary because older versions of GraphiQL have a Cross-site Scripting vulnerability (see snyk and the GraphiQL docs).

    I have updated the file to be based upon the CDN example provided by the GraphiQL team.

    I have made a couple of modifications to the file to bring in line with our current GraphiQL page:

    • Using the GraphiQL provided fetcher with the subscriptions URL (dependent on if subscriptions are enabled for the integration)
    • Added a CSRF token, which was a previous modification to the file made in this PR

    There are a couple of changes to the interface due to the updated version, most notably the loss of the "Explorer". It may be possible to add this back in via the graphiql-explorer package.

    Types of Changes

    • [ ] Core
    • [ ] Bugfix
    • [ ] New feature
    • [x] Enhancement/optimization
    • [ ] Documentation

    Issues Fixed or Closed by This PR

    • Closes #1268

    Checklist

    • [x] My code follows the code style of this project.
    • [ ] My change requires a change to the documentation.
    • [ ] I have updated the documentation accordingly.
    • [x] I have read the CONTRIBUTING document.
    • [ ] I have added tests to cover my changes.
    • [x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).
    bot:has-release-file bot:release-type-minor 
    opened by MattExact 19
  • Add experimental support for Pydantic

    Add experimental support for Pydantic

    This PR adds (basic) support for Pydantic. Full support will likely be done with multiple PRs. For now the focus will be in being able to generate GraphQL types from a Pydantic model and use it.

    So far we have a conversion being implemented, just for str and int (but we can easily add more scalars), we also have a way to reference other registered pydantic models, though the implementation is not really nice.

    For this PR do be done we need:

    • [x] Support for all the scalars
    • [x] Support for extending types
    • [ ] Proper resolvers and init method (see explaination below).
    • [x] Force users to declare the list of fields that should be exposed in GraphQL

    Closes #302 Solves #444

    enhancement 
    opened by patrick91 19
  • Add graphql_type parameter to `strawberry.field`

    Add graphql_type parameter to `strawberry.field`

    Description

    This PR adds a new graphql_type parameter to strawberry.field that allows you to explicitly set the field type. This parameter will take preference over the resolver return type and the class field type.

    For example:

    @strawberry.type
    class Query:
        a: float = strawberry.field(graphql_type=str)
        b = strawberry.field(graphql_type=int)
    
        @strawberry.field(graphql_type=float)
        def c(self):
            return "3.4"
    
    schema = strawberry.Schema(Query)
    
    str(schema) == """
      type Query {
        a: String!
        b: Int!
        c: Float!
      }
    """
    

    Notes:

    ~~I'm open to alternative names to field_type. It doesn't look that great to have the duplication on strawberry.field(field_type but I didn't want to use just type since it's a built in function in Python.~~ Renamed to graphql_type.

    Implementation notes:

    I noticed that we almost have this feature with the type_annotation parameter on StrawberryField so I just renamed it to graphql_type and exposed it in the decorator.

    Types of Changes

    • [ ] Core
    • [ ] Bugfix
    • [x] New feature
    • [ ] Enhancement/optimization
    • [ ] Documentation

    Issues Fixed or Closed by This PR

    • Fixes #2308

    Checklist

    • [ ] My code follows the code style of this project.
    • [ ] My change requires a change to the documentation.
    • [ ] I have updated the documentation accordingly.
    • [ ] I have read the CONTRIBUTING document.
    • [ ] I have added tests to cover my changes.
    • [ ] I have tested the changes and verified that they work and don't break anything (as well as I can manage).
    bot:has-release-file bot:release-type-minor 
    opened by jkimbo 18
  • Implement explicit interface type resolution

    Implement explicit interface type resolution

    Description

    The behavioral changes included in this PR are: a) duck typing on fields that return interfaces or types implementing an interface now requires an explicit is_type_of opt-in b) adding an explicit is_type_of opt-in is now implemented with a is_type_of classmethod

    This seems like it might require a change to the documentation mentioning the classmethod, which I can make assuming this approach looks good.

    Also, what release type should this be? Technically it is a breaking change, though it's quite minor.

    Types of Changes

    • [ ] Core
    • [x] Bugfix
    • [ ] New feature
    • [x] Enhancement/optimization
    • [ ] Documentation

    Issues Fixed or Closed by This PR

    • https://github.com/strawberry-graphql/strawberry/issues/1405

    Checklist

    I did dev work within a codespace based on your template (which was very convenient), so at the very least all the pre-commit scripts ran correctly. I also ran the test suite, which passes.

    • [x] My code follows the code style of this project.
    • [x] My change requires a change to the documentation.
    • [ ] I have updated the documentation accordingly.
    • [x] I have read the CONTRIBUTING document.
    • [x] I have added tests to cover my changes.
    • [x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).
    opened by AlecRosenbaum 17
  • Add custom dataclass init function

    Add custom dataclass init function

    Description

    This PR adds a custom dataclass init function that enforces that all args get passed as keyword arguments. This allows us to avoid the problem where a type cannot define a field with a default value before a field that doesn't have a default value.

    Types of Changes

    • [x] Core
    • [ ] Bugfix
    • [ ] New feature
    • [ ] Enhancement/optimization
    • [ ] Documentation

    Issues Fixed or Closed by This PR

    Checklist

    • [ ] My code follows the code style of this project.
    • [ ] My change requires a change to the documentation.
    • [ ] I have updated the documentation accordingly.
    • [ ] I have read the CONTRIBUTING document.
    • [ ] I have added tests to cover my changes.
    • [ ] I have tested the changes and verified that they work and don't break anything (as well as I can manage).
    bot:has-release-file bot:release-type-minor 
    opened by jkimbo 16
  • Add IDE support for strawberry.Private

    Add IDE support for strawberry.Private

    My apologies, not knowing the internals of pythons type hinting system, I can't articulate this issue well Is there something that can be done to strawberry.Private to prevent this from happening?

    image

    bug 
    opened by lijok 16
  • Apollo Federation Support

    Apollo Federation Support

    I was thinking of adding support for Apollo Federation, in order to make this happen the following TODOs need to be tackled:

    • [ ] Allow support for custom directives #109 not really true, but having a pythonic way of defining directives will help
    • [ ] Output types in schema even if they are not used by a query Right now we only output fields that are used (directly and indirectly) in a query. Federated schemas might not define a query at all, so we need to output types anyway.
    • [x] Add support for custom scalars #3

    Federation specification

    scalar _Any
    scalar _FieldSet
    
    # a union of all types that use the @key directive
    union _Entity
    
    type _Service {
      sdl: String
    }
    
    extend type Query {
      _entities(representations: [_Any!]!): [_Entity]!
      _service: _Service!
    }
    
    directive @external on FIELD_DEFINITION
    directive @requires(fields: _FieldSet!) on FIELD_DEFINITION
    directive @provides(fields: _FieldSet!) on FIELD_DEFINITION
    directive @key(fields: _FieldSet!) on OBJECT | INTERFACE
    
    directive @extends on OBJECT | INTERFACE
    

    Federation spec: https://www.apollographql.com/docs/apollo-server/federation/federation-spec/

    Python API

    Initial Ideas

    type Review {
      body: String
      author: User @provides(fields: "username")
      product: Product
    }
    
    extend type User @key(fields: "id") {
      id: ID! @external
      reviews: [Review]
    }
    
    extend type Product @key(fields: "upc") {
      upc: String! @external
      reviews: [Review]
    }
    
    @strawberry.type
    class Review:
      body: str
      author: User = strawberry.field(directives=[provides(fields="username")])
      product: Product
    
    
    @strawberry.type(extend=True, directives=[key(fields="id")])
    class User:
      id: ID = strawberry.field(directives=[external()])
      reviews: typing.list[Review]
    
    
    @strawberry.type(extend=True, directives=[key(fields="upc")])
    class Product:
      upc: str = strawberry.field(directives=[external()])
      reviews: typing.list[Review]
    
    enhancement help wanted discussion 
    opened by patrick91 16
  • Bump pydantic from 1.10.2 to 1.10.4

    Bump pydantic from 1.10.2 to 1.10.4

    Bumps pydantic from 1.10.2 to 1.10.4.

    Release notes

    Sourced from pydantic's releases.

    v1.10.4 (2022-12-30)

    Full Changelog: https://github.com/pydantic/pydantic/compare/v1.10.3...v1.10.4

    v1.10.3 (2022-12-29)

    Full Changelog: https://github.com/pydantic/pydantic/compare/v1.10.2...v1.10.3

    Changelog

    Sourced from pydantic's changelog.

    v1.10.4 (2022-12-30)

    v1.10.3 (2022-12-29)

    NOTE: v1.10.3 was "yanked" from PyPI due to #4885 which is fixed in v1.10.4

    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)
    dependencies 
    opened by dependabot[bot] 1
  • Proposal: Internal refactor

    Proposal: Internal refactor

    Motivation: extendability and reduce code duplications:

    • Strawberry has a lot of code duplication mainly in integrations.
    • Integration sometimes needs to reinvent the wheel and not only that it is not DRY, some tests in strawberry "core" simply won't apply to the integration.
    • Strawberry as a lot deffered imports.
    • It is not clear at all where does a type \ field is considered "ready to go" i.e
    @strawberry.type
    class A:
       foo: B #  this field is deferred
       bar: int  #  this field is good
       
    @strawberry.type
    class B:
       ...
    

    If I am building an integration and I want to modify this filed behaviour I will need to "wait" until this field is evaluated.

    • Strawberry itself (surprisingly) is not type hinted well, mainly the cryptic
    if hasattr(type_, "_type_definition"):
        type_definition: TypeDefinition = type_._type_definition
    

    that is scattered through the code base.

    • Strawberry relies many @propertys for the type hints mainly to support deferred types. This introduces another layer of comlexity and will (in the future maybe), performance penalty, and may make it harder for stawberry to work with R or have our own graphql-core. These are some profiling results from a project of mine: imageimage

    • https://github.com/strawberry-graphql/strawberry/blob/feacc0f186458d138ba0231a006317cadb0b7753/strawberry/field.py#L62 StrawberryField is inheriting dataclasses.Field and that IMO unnecessary burden, results namespace clashes, tights strawberry to dataclasses too much and finally it is not a dataclass like many other parts of strawberry.

    • generic types are evaluated in a very complex way (copy_with) and it is not clear at a first glance when a type is already evaluated or not.

    Strawberry current workflow:

    • @strawberry.type is applied on a class
    • https://github.com/strawberry-graphql/strawberry/blob/feacc0f186458d138ba0231a006317cadb0b7753/strawberry/object_type.py#L105 is called and preforms some checks that arguably relates to that function.
    • https://github.com/strawberry-graphql/strawberry/blob/feacc0f186458d138ba0231a006317cadb0b7753/strawberry/object_type.py#L129 is called and some magic happends, note that the type is not necesserely ready yet as explained above.
    • types are later converted at the schema to gql-core types, This is when you can say that you are certained that a type is "ready to go".

    Alternative:

    This approach is a successor of what I wrote at #2117.

    strawberry would have a type registerer that returns a StrawberryObject the registerer would be provided to strawberry.Schema, the schema would evaluate all the types and cache generic classes.

    Pros:

    • Know all the types statically.
    • Can cache generic classes.
    • Better support for integrations.
    • No need for type as a @property.
    • Reduced deferred imports.
    • Cleaner code.
    • More "staticly typed" than before.
    • Strawberry itself would be "typed" (with the use of StrawberryObject)

    Cons

    • strawberry would not be able to nativly support field injections (not that it is now though I would discorage that anyway). You could inject fields only at TypeRegisterer level and fields are not evaluated at this step if you have any custom logic you would have to access __annotations__...

    • integrations would have to rewrite their codebase.

    • wrong usage errors would popup only at schema level, this is solveable by adding a debug flag to TypeRegisterer that will store __file__ and the line number. when wrong usage occur raise the error with the file and line no.

    Example:

    class StrawberryObject:
        __strawberry_definition__: ClassVar[TypeDefinition] = None
        
        def __class_getitem__(cls, item):
            if cls.__strawberry_definition__:
                return cls.__strawberry_definition__.types.generic_cache[item]
    
    class TypeRegisterer:
        store: dict[str, Type]
        
        @dataclass_transform
        def type(t: Type[T]) -> Type[StrawberryObject]:
            return self.class_transformer(t)  #  maybe support other dataclass idioms
        
    class Type Evaluator:
        def evaluat(self) -> None:
            types = {}
            types.update(self.types)
            for t in self.types.values():
                tp_hints = get_type_hints(t, globalns=types)
                #  yada yada
    
    class Schema:
        integrations: TypeEvaluator
        
        def _evaluate_types(self) -> None:
            for integration in self.integrations:
                integration.evaluate(self.types)
    

    In action:

    registerer = TypeRegisterer()
    
    @registerer.type
    class Query:
       a: Foo
    
    @registerer.type
    class Foo:
        bar: int
    
    schema = strawberry.Schema(types=registerer, query=Query)
    

    cc/ @patrick91 @BryceBeagle @jkimbo

    opened by nrbnlulu 0
  • Bump sanic-testing from 22.9.0 to 22.12.0

    Bump sanic-testing from 22.9.0 to 22.12.0

    Bumps sanic-testing from 22.9.0 to 22.12.0.

    Release notes

    Sourced from sanic-testing's releases.

    Version 22.12.0

    What's Changed

    New Contributors

    Full Changelog: https://github.com/sanic-org/sanic-testing/compare/v22.9.0...v22.12.0

    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)
    dependencies 
    opened by dependabot[bot] 1
  • Bump sanic from 22.9.1 to 22.12.0

    Bump sanic from 22.9.1 to 22.12.0

    Bumps sanic from 22.9.1 to 22.12.0.

    Release notes

    Sourced from sanic's releases.

    Version 22.12.0

    Features

    • #2569 Add JSONResponse class with some convenient methods when updating a response object
    • #2598 Change uvloop requirement to >=0.15.0
    • #2609 Add compatibility with websockets v11.0
    • #2610 Kill server early on worker error
      • Raise deadlock timeout to 30s
    • #2617 Scale number of running server workers
    • #2621 #2634 Send SIGKILL on subsequent ctrl+c to force worker exit
    • #2622 Add API to restart all workers from the multiplexer
    • #2624 Default to spawn for all subprocesses unless specifically set:
      from sanic import Sanic
      

      Sanic.start_method = "fork"

    • #2625 Filename normalisation of form-data/multipart file uploads
    • #2626 Move to HTTP Inspector:
      • Remote access to inspect running Sanic instances
      • TLS support for encrypted calls to Inspector
      • Authentication to Inspector with API key
      • Ability to extend Inspector with custom commands
    • #2632 Control order of restart operations
    • #2633 Move reload interval to class variable
    • #2636 Add priority to register_middleware method
    • #2639 Add unquote to add_route method
    • #2640 ASGI websockets to receive text or bytes

    Bugfixes

    • #2607 Force socket shutdown before close to allow rebinding
    • #2590 Use actual StrEnum in Python 3.11+
    • #2615 Ensure middleware executes only once per request timeout
    • #2627 Crash ASGI application on lifespan failure
    • #2635 Resolve error with low-level server creation on Windows

    Deprecations and Removals

    • #2608 #2630 Signal conditions and triggers saved on signal.extra
    • #2626 Move to HTTP Inspector
      • 🚨 BREAKING CHANGE: Moves the Inspector to a Sanic app from a simple TCP socket with a custom protocol
      • DEPRECATE: The --inspect* commands have been deprecated in favor of inspect ... commands
    • #2628 Replace deprecated distutils.strtobool

    Developer infrastructure

    ... (truncated)

    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)
    dependencies 
    opened by dependabot[bot] 1
  • Implement oneOf for input types

    Implement oneOf for input types

    Might be worth implementing this upcoming feature, unions are not allowed in input types and this is a good alternative to that, also should be easy to implement in code 😊

    https://stepzen.com/blog/coming-soon-to-graphql-the-oneof-input-object

    It's also been implemented in other libraries, for example async GraphQL (a rust library)

    From: https://github.com/strawberry-graphql/strawberry/discussions/2420#discussioncomment-4499708

    feature-request 
    opened by patrick91 0
Releases(0.151.2)
Owner
Strawberry GraphQL
A Python library for creating GraphQL APIs
Strawberry GraphQL
A Python 3.6+ port of the GraphQL.js reference implementation of GraphQL.

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 crea

GraphQL Python 458 Dec 13, 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
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
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-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
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
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
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 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
Django registration and authentication with GraphQL.

Django GraphQL Auth Django registration and authentication with GraphQL. Demo About Abstract all the basic logic of handling user accounts out of your

pedrobern 301 Dec 9, 2022