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).

$ 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

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).

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

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).

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

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).

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).

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).

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?

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]

Bumps pydantic from 1.10.2 to 1.10.4.

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.

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:

• 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

Bumps sanic-testing from 22.9.0 to 22.12.0.

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.

Bumps sanic from 22.9.1 to 22.12.0.

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.

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