Differences between graphqlgen and graphql-code-generator

[dotansimha]

Hello! Congratulations on your new tool! I love the ideas and concepts behind it.

As the creator of graphql-code-generator, maintaining and leading a large community of contributors and companies behind it, I love seeing new and exciting ideas and libraries.
We have generators from us and the community for Typescript on the server, client, auto-generated components for React and Angular, MongoDB, Go, Dart, XSD and many more.
The idea is that it's very easy to customize or create a new template because of the way we wrote the core of the library.
I've skimmed around your code and open issues and wondered where do you see the difference between your library and ours?

The thread here would help me understand and improve our library for our community and possibility help you with new ideas and concepts from our existing library.
Maybe the question to start from is - For a new developer going into writing their first GraphQL server, what would make them choose one tool over the other?

I want to collaborate with you and learn as much as possible from your great effort and work and help grow the whole GraphQL community.

Thank you so much and here is for a great collaboration!

[schickling]

Hi @dotansimha! Thanks a lot for opening this issue and your thoughts. I really like what you're building with graphql-code-generator and I think it's awesome to see so many new tools leveraging the potential of code-generation in combination with GraphQL. 🙌

Before starting out with graphqlgen (or graphql-resolver-codegen as it was called before), we've certainly looked around and tried to compare existing tools. However, we came to the conclusion that it would be the best decision to start from scratch and evolve our API and functionality without too much influence of other existing tools. Most importantly, the goals we had for graphqlgen didn't seem to be compatible with existing tools without major tradeoffs.

Here are the biggest differences between graphqlgen and graphql-code-generator based on my current understanding:

1. Frontend/backend scope: graphqlgen is purely focussed on making it easier to build GraphQL servers and optimized for the use case of implementing GraphQL resolvers - not queries from the frontend. graphql-code-generator seems to be a very general tool that also supports generating code for frontend applications (React, Angular, ...) similar to the apollo-cli (formerly apollo-codegen).

2. Language scope: While graphql-code-generator supports multiple languages based on its templating engine, we've decided to solely focus on the JS ecosystem (i.e. TypeScript, Flow, Reason...). While I think there are benefits to creating a universal tool, I think it always comes at the expense of tradeoffs (both in terms of functionality & community acceptance). For a Gopher it will always feel "better" (aka more go-idiomatic) to use a tool that's "native" to the Go ecosystem. The same applies to other languages. This is why we've decided to build a tool that's as JS-idiomatic and optimized as possible instead of going broad.

3. API design & configuration: While many projects have the same goal/solving the same problem, what ultimately as important is: how. Changing the design of a tool (API, configuration, CLI output etc) is very difficult once it's been adopted by a lot of developers. While we're still actively iterating on the design of graphqlgen, we seem to have taken quite a different approach which would have been very hard to reconcile with graphql-code-generator. Ultimately it's up to the developer to decide what he or she likes better – it's very much a matter of opinion and personal taste. (Again related to a tool being universal vs language-idiomatic.)

Conclusion: graphql-code-generator is a more general tool, graphqlgen is more specific/optimized for building GraphQL servers in typed JS-based languages.

I hope this clarifies things. While I don't see a direct what how to collaborate between the projects, I'm sure there will be some mutual inspiration that ultimately makes both tools better. 🙂

[dotansimha]

@schickling thank you for your response. I want to clarify some thing and get to the details of what you said, because that way I can learn, I hope it's ok with you.

But before that, I think if you went through and looked around some other codegen implementations, a good best practice on Github is to list prior art libraries that were existing before you started your own.
Not only to be honest and give the feedback where it deserves, but it helps new developers to find the best tool for them.

as for you answer:

1. You said graphql-code-generator is focused on frontend frameworks. that is completely not true 🙂 actually our most used template is the Typescript backend template! the fact that we have a better frontend templates then apollo-cli doesn't mean we don't have the best template for backend developers. our backend template is being used by huge Enterprises and companies for all over the world! I wonder if you can demonstrate how graphql-code-generator is lacking things on the backend?
2. When I started graphql-code-generator my main focus was Typescript and Javascript. I still built it in a way that anyone can build their own templates and many from the community actually have. but for me, is the owner and main contributor of the library, the focus was and always has been Typescript and Javascript. I wonder if you can show me an example where you think the implementation is not good for those use cases?
3. When you talk about API design and configuration, can you explain what exactly are the differences and how would they can hard to reconcile into graphql-code-generator? what in your personal taste different and why do you think I wouldn't want to add or change graphql-code-generator? have you ever asked me or opened a single issue on graphql-code-generator with any proposal?

I'm sorry you came up with the conclusion above, because I believe you could have saved a lot of time for you and your users if you would just start a conversation.
I would appreciate a real, honest answer with shortcoming you really found on our library instead of a general answer without details because that is the only way I can really learn and the only way people from the community can really understand the difference.

I hope we can leave this issue open as I'm looking forward for a real collaboration, I believe Prisma is doing an amazing job promoting GraphQL and me and the community looking up to you in leading this community in the right way.

[hinsxd]

I like both libraries, using Prisma in my first graphql project, and if I become a more experienced developer I would definitely switch from prisma to some advanced solutions, like Postgraphile.
To me, Prisma (or former graphcool) seemed to focus too hard on promoting GraphQL as well as getting people to use their solutions without knowing. For example, they have some repos under graphql-boilerplates to get newcomers to use their prisma boilerplates without even knowing prisma is in charge of the repo. This is actual scam.

Yes they did a good job in Prisma, Graphql-yoga, etc, but it makes me feel fooled when Prisma made you think we were using "industry standard best practice" then you grew up and found out that I was "forced" to use the whole Prisma ecosystem. And thanks Prisma for training me to dig into the dependencies and check if prisma is installed by default.

[koenpunt]

To share my experience;

After using graphqlgen successfully for a while, I started to getting issues with newer releases. Eventually the amount of issues and api changes forced me to use my own fork. By the time all my PRs, which were supposed to fix the issues I had, got merged, new issues had came up, and I still had to use my own fork.

While looking for alternatives I found graphql-code-generator, which I then found out was actually around for quite a bit longer.

Updating my projects to use graphql-code-generator was a very easy task, since the signature of a resolver is defined by graphql-js, the generated types were actually quite similar.

I'm not saying everyone should switch, but I just want to clarify that in the end there are no major differences in the generated code.

And as @dotansimha already asked, it would be nice to get some insights in why this library was created, and how it's supposed to better/different than graphql-code-generator.

As far as I know the only thing graphqlgen does different (not mentioning all the thing graphql-code-generator does more), is that it actually parses typescript files to locate interfaces, whereas graphql-code-generator requires an explicit mapping.