genql: RFC: breaking changes for v3

Ok, i found a new syntax that i like, i am currently implementing this syntax for v3, it should make it worth it for anyone currently using chain syntax to migrate to v3

const { query } = generateQueryOp({
    recursiveType: {
        __args: { requiredVal: ['ciao'] },
        value: 1,
        recurse: {
            ...everything,
            recurse: {
                value: 1,
                recurse: {
                    ...everything,
                    recurse: {
                        ...everything,
                    },
                },
            },
        },
    },
})

To pass args you will pass an __args field (similarly named like GraphQL __typename)

This has the benefits of

• removing difficult to type and refactor array syntax
• no need to pass [args] as const
• simplify the type selection generic type, making inference faster
• has same benefits of chain syntax (no need to use arrays, easy autocompletion to discover new fields, etc)
• it will be possible to add directive support in the future with a similar paradigm, like __directive: '@something', on scalar types too

@remorses At work we’ve been working with the generator and it has been a pleasant DX so far ~ 🚀

However, we’ve discussed about the possibility of having a different form factor from the array shape.

Instead of relying on the array position, we are currently drafting something like:

• use an object
• then, map the GraphQL Selection Set to a fields property inside such object
• and then, map the arguments, say, filters, and for mutations, inputs, into the input fields of the aforementioned object.(we decided to use input but args also makes sense in the example you provided in the code some comments above)

Something like this:

Note: customClient is the wrapper with the functionality (and typings we were drafting) mentioned above

I really want only one way to create queries for the next release

What is that you don’t like about the default query syntax? Maybe i can remove the use of the array and add an args field instead, something like this

client.query({
    getUser: {
        args: {
            id: 1,
        },
        address: {
            everything: true,
        },
        withArgument: {
            args: {
                id: 1,
            },
        },
    },
    scalarField: true,
})

I think that this way you get the best of both syntaxes

Hello all,

First, thank you for your work that made my life so easier working with GraphQL and Typescript. I am a huge fan of your value proposition with GenQL. Type generation coupled with chain syntax really feels like working with a TS ORM but through GraphQL ❤️

I definitely agree with the above mentionned points. Chain syntax is just way too handy. It enables many generic use cases etc. I would be very sad to see it go. It would make me refactor a lot of my code as well 😕

Personally I would prefer to unify things in the way of keeping only chain syntax. As an example: we initially planned to use Apollo Client integration with GenQL in our project, but we decided to fall back on the fetch implementation as soon as we realized it was not possible to use Apollo with the chain syntax…

I also agree on the benefits of a generated file size reduction if possible. Deno and Bun implementation are really not a priority for me neither.

What I would like to see in V3:

• Better subscription handling (glad to see it planned)
• Generated file size reduction (if possible)
• Higher level reusable types (ex: a reusable type for all the root arguments of a resolver / endpoint)
• Third-party client integrations with chain syntax (ex: Apollo)

Thank you for your time and consideration. Keep up the great work !🎉

Hey there!

Awesome news !! First off, I wanted to ask why we’re dropping the chain syntax? Personally, it was that syntax that really made me lean toward GenQL over Zeus. I find it to be much more natural and readable, and I’d be really sad to see it go. (And it will require a huge refactor on my end since I use that syntax everywhere, but that’s a secondary concern.)

I’m even wondering what would be the main point of using GenQL over Zeus, which is more popular and maintained if we’re dropping that syntax. I’m not super familiar with Zeus’s syntax, so let me know if I’m mistaken, but I don’t see any major differences anymore. I’d be really curious to hear your reasoning on this. Is it a technical limitation, or something else?

Next, the main pain point I have with GenQL currently is the generated types file. I’m working on a Hasura with around 30 tables, and as a result, I have a massive types file (40k~ lines). This causes huge slowdowns with IntelliSense in my IDE. I have reached a point where sometimes I have to wait ~2 seconds for my IDE to remove the red squiggly lines. And yet, I’m working on a powerful PC 😅

Do you think it would be possible to optimize this generated file? I’d have to look more into it, so stop me if I’m wrong, but it seems like there are a lot of duplicated types that could be merged together using generics or whatever, which could maybe help the TypeScript server be faster? I’ve noticed that you’re no longer generating the JS files that contained JS typeguards, which should already help a bit, I guess.

Another thing, not essential, but would also be super cool to have, is the ability to define aliases. As far as I know, this isn’t possible (let me know if I’m mistaken).

To finish off, I’d say that out-of-the-box support for Deno and Bun are not really priorities. I think 95% of users don’t care about that. Especially for Bun, which isn’t even production-ready yet. Now, I can understand that it’s a nice marketing argument, and you’re free to do what you want with your library, but in my opinion it’s totally secondary.

Thanks so much for your work on GenQL, and the new docs look great! Notaku seems really cool too, I might give it a try one day

It would be cool if when using the generate function as a library, if I can just get a string with all the generated code instead of having to write to disk first and then read that file. Not a big deal but more ergonomic for modifying the output in the way I’d like to (mostly to add imports for customized types at the top).