This PR adds next package to ariadne_graphql_modules containing future API that supports both schema first and code first approaches to development

TODO

• [x] Fix build (rename type to type_ in class fields and function arguments?)
• [x] Feature parity with previous version (#30)
• [x] Compat with old API (#38)
• [x] MyPy plugin (#40)
• [x] Documentation (#39)

GraphQL features

• [x] enum
• [x] input
• [x] interface
• [x] scalar
• [x] type
• [x] union
• [x] Subscription

Hi @rafalp,

Could you please take a look at this PR? I’d love to hear your thoughts on it.

I’ve made some changes to the code structure to improve the deployment process. Inspired by Pydantic, I’ve moved the old version into a v1 folder and made the v2 version the official one.

Additionally, I’ve introduced the ability to inherit interface objects using (object, interface). This idea comes from the Mirumee team, allowing us to avoid code duplication when defining the schema. Here’s an example:

    class BaseEntityInterface(GraphQLInterface):
        id: GraphQLID

    class UserInterface(BaseEntityInterface):
        username: str

    class UserType(GraphQLObject, UserInterface):
        name: str

    class SuperUserType(UserType):
        is_super_user: bool

This will generate the following GraphQL schema:

        interface UserInterface implements BaseEntityInterface {
         id: ID!
         username: String!
       }

       interface BaseEntityInterface {
         id: ID!
       }

       type User implements BaseEntityInterface & UserInterface {
         id: ID!
         username: String!
         name: String!
       }

       type SuperUser implements BaseEntityInterface & UserInterface {
         id: ID!
         username: String!
         name: String!
         isSuperUser: Boolean!
       }

I know 301 changed files looks intimidating, but most of these are snapshot files (snapshots/*.yml). These are automatically generated by pytest-regression to store test outputs for regression testing. Since they’re auto-generated and just for verifying code correctness, there’s no need to review them closely.

As for the V1 module, it’s the same as before with only minor type-related tweaks to ensure backward compatibility with V2. The functionality hasn’t changed; it’s just been relocated in the project structure.

Examples of how to use the API will be included in the documentation that's currently being developed. For now, you can find usage examples in the tests.

My only worry is that v1 module change will be a nasty surprise to everyone who just updates GraphQL Modules to new version and expects it to work.

My only worry is that v1 module change will be a nasty surprise to everyone who just updates GraphQL Modules to new version and expects it to work.

I understand your concern, but the good news is that if I properly highlight this change in the release notes, the transition shouldn't be too much of an issue. It's actually a better solution than having everyone manually remove .next from their imports after maintaining the old version for a year. This way, we can ensure a smoother upgrade process for everyone.