`strawberry schema-codegen` feedback + suggestions

[magicmark]

👋 looking into pairing https://strawberry.rocks/docs/codegen/query-codegen and https://github.com/graphql-python/gql

specifically, I want the client application (another python service) to do everything, rather than "generating clientlibs" and maintaining a pipeline for that. (this approach is similar to web clients)

Here's the current workflow

• download the schema.graphql of the service I want to call from the registry
• use $ strawberry schema-codegen schema.graphql to generate a schema.py
• use $ strawberry codegen --schema schema ... to generate operation result files
• find and replace to add @dataclass to all generated classes
• use from dataclass_wizard import fromdict to recursively convert the raw dict response into the dataclasses

...which I think works pretty well!

Here's some improvements I'd love to add to add to strawberry to reduce the amount of logic on our side - let me know if you'd be open to some PRs for this!

1. for $ strawberry codegen, allow a --sdl flag as a (mutually exclusive) alternative to --schema which accepts the schema in SDL format. (Internally, strawberry could still run schema-codegen). This will make it easier for external services and tooling to do codegen, rather than assuming it all happens in the server's codebase.

2. $ strawberry codegen currently uses the basename of the input file, rather than the name of the query, as the name of the output file. This potentially leads to conflicts when run in parallel if there are two files named get_foo.py but in different locations. An option to use the query name, or arbitrarily specify would be good. Former pairs well with the common rule of "no duplicated query names" within a codebase. This would let us just xargs into the codegen command.

3. use dataclasses (or ability to specify this) rather than raw classes

4. add some __post_init__ logic to allow dict unpacking into a dataclass for nested types. This would remove the need to use from dataclass_wizard import fromdict.

   Something like this(?):

   from dataclasses import dataclass
   
   @dataclass
   class ReviewResultUser:
       name: str
   
   @dataclass
   class ReviewResultReview:
       id: str
       author: User
   
       def __post_init__(self):
           if isinstance(self.author, dict):
               self.author = ReviewResultUser(**self.author)
   
   @dataclass
   class ReviewResult:
       review: ReviewResultReview
   
       def __post_init__(self):
           if isinstance(self.review, dict):
               self.review = ReviewResultReview(**self.review)
   
   # raw dict response from https://github.com/graphql-python/gql
   raw_result = {"review": {"id": "123", "author": {"name": "alice"}}}
   
   # parsed into dataclasses generated by strawberry
   result = ReviewResult(**raw_result)

wdyt?

[erikwrede]

I probably need some more time to come up with a vision myself, but my immediate thought here was that typed dicts are a fitting and much leaner alternative for this use case. The contract is verified by the GraphQL server, and the code is generated - I don't see much advantage in the conversion overhead produced by the dataclasses. Do you have a specific use case in mind where a dataclass might be favorable?

[magicmark]

typed dicts works too! (just noting that the current output uses raw classes)

[bellini666]

I like the idea, and I also think TypedDict would be a lot better here.

Maybe we should reconsider our "query codegen" to generate TypedDicts instead of classes? They are currently in a very experimental state, so IMO this is the perfect time to introduce this kind of a breaking change.

Not sure what @patrick91 thinks about this

[renier]

As feedback, I just started looking at strawbery because of its schema codegen capability. Right away noticed it did not support custom directives.

For example, we have this in our SDL:

directive @authz(resource: String!, action: String!) on FIELD_DEFINITION

This makes strawbery schema-codegen schema.sdl return the following:

NotImplementedError: Unknown definition None

There is even a bug in the code that raises this exception since it prints a definition variable that has not been set, thus the None. If I change that line of code to print instead type(graphql_definition).__name__, then the error is clearer about what it could not understand:

NotImplementedError: Unknown definition DirectiveDefinitionNode

I can remove those custom directives from the SDL and then the codegen works great. Will continue on my journey, but yes this would be nice to support, or at a minimum to skip and not break on it.

[patrick91]

I can remove those custom directives from the SDL and then the codegen works great. Will continue on my journey, but yes this would be nice to support, or at a minimum to skip and not break on it.

yes, let's add support for these!

[patrick91]

@magicmark you basically want to be able to type something like:

query = gql(
    """
    query getContinents {
      continents {
        code
        name
      }
    }
"""
)

right?

[patrick91]

@magicmark thanks!

I also would love to make this possible: https://play.ty.dev/dd4d70e2-93c0-4bac-9cec-a423a7f25256

[patrick91]

Also I'm ok with doing the changes requested here, maybe we can start with the sdl support?

[magicmark]

@patrick91 to clarify are you suggesting implementing something like gql-tada but within mypy? or continue to use a build step? having trouble understanding the example

for the latter, I suppose I was imagining a query method using a generic (similar to useQuery in apollo web clients) - but curious to see what you had in mind

(and then we'd use something like gettext or an ast parser to grab the raw query strings from source, or .graphql files to pass them to the codegen - would be happy to upstream this logic since it feels generic/useful enough)

[patrick91]

@patrick91 to clarify are you suggesting implementing something like gql-tada but within mypy? or continue to use a build step? having trouble understanding the example

we probably need a build step, I don't think we can do something like tada in python just yet :(

we could make an LSP that also makes the pyi file though 🤔

[magicmark]

(cc @leszekhanusz)