Difference between Type GraphQL & Nexus might be helpful since I am guessing both solve the same problem❓
deadcoder0904
All 3 comments
I could write something up in the docs.
They do solve a similar problem in very different ways, one of the big differences is that Nexus can be used with JavaScript whereas (as far as I understand) TypeGraphQL relies heavily on specific guarantees of the TypeScript language and things like metadata reflection, etc.
Classes also aren't as flexible, composable, and reusable as objects and functions, as evidenced by React's move toward hooks. As a schema grows I believe Nexus' approach leads to better code re-use for fields with complex args, constructing object types with shared fields, creating higher-order type factories (still need to document this pattern), etc.
That's just my view though, some folks strongly prefer using classes and a decorator style approach. I think there's room for both styles of approaches, and perhaps there's room for collaboration or something Nexus can do to to bridge the gap here?
tgriesser
on 15 Feb 2019
Rather than using the decorator pattern I would love to see use of TypeScript interfaces for creating Nexus revolvers, as a third party library / plugin. Because composing via strings seems, I dont know, impossible to debug?
I can see it happening, and I cant wait! 🔥
expelledboy
on 27 Sep 2019
@tgriesser do you have a link to or a quick example for the higher-order type factories? Would be great to learn more 😄
jlarmstrongiv
on 4 Apr 2020
Related issues
saostad
·
3Comments
ryands17
·
4Comments
MathiasKandelborg
·
5Comments
deadcoder0904
·
6Comments
ecwyne
·
6Comments
Most helpful comment
I could write something up in the docs.
They do solve a similar problem in very different ways, one of the big differences is that Nexus can be used with JavaScript whereas (as far as I understand) TypeGraphQL relies heavily on specific guarantees of the TypeScript language and things like metadata reflection, etc.
Classes also aren't as flexible, composable, and reusable as objects and functions, as evidenced by React's move toward hooks. As a schema grows I believe Nexus' approach leads to better code re-use for fields with complex args, constructing object types with shared fields, creating higher-order type factories (still need to document this pattern), etc.
That's just my view though, some folks strongly prefer using classes and a decorator style approach. I think there's room for both styles of approaches, and perhaps there's room for collaboration or something Nexus can do to to bridge the gap here?