Type GraphQL vs Nexus

[deadcoder0904]

Difference between Type GraphQL & Nexus might be helpful since I am guessing both solve the same problem❓

[tgriesser]

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?

[expelledboy]

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! 🔥

[jlarmstrongiv]

@tgriesser do you have a link to or a quick example for the higher-order type factories? Would be great to learn more 😄

[BradyEdgar94]

I just started to pick up Prisma 2 and was looking for a solution to build my GraphQL alongside Prisma. I went back and forth between the two and chose Nexus basically for the same reasons described above. However, one thing I found with Nexus that I did not enjoy was how poorly the different packages for Nexus and Prisma worked together. The functionality was all good but there is a lot of conflict with their versioning and dropping old versions before new solutions are production-ready. The whole conflicting between these packages has really thrown me off Nexus so far.

[jlarmstrongiv]

I wholeheartedly agree with @BradyEdgar94’s assessment. After feeling burned by the upgrade path to Prisma 2, I am now using Python and Django with Graphene. As much as I would have preferred to stay in the TypeScript ecosystem, switching seemed like the most future-proof option.

[BradyEdgar94]

Quick update as per my last comment. I spent today switching from Nexus to Type-GraphQL and I can say Type-GraphQL has been a much better experience from the start. The model mapping for Prisma worked perfectly without any issue or confusion the first time around. I have also found make custom queries, mutations, and resolvers to be very straightforward. I may come back and try Nexus some other time when their development stuff is all sorted but at this stage, I feel comfortable recommending Type-GraphQL over Nexus from my experience.

There are a few pain points with Type-GraphQL compared to Nexus but they are minor. I still prefer function-based programming over class but it's not a big deal for defining a Graph API. I also find with all the decorators, it can add a fair bit of extra size and complexity to your files/syntax. Also if you're not familiar with Typescript, it will have a little bit of a learning curve compared to Nexus. All minor issues for me though.

Just my thoughts and recent experience with both of these :)

[jasonlimantoro]

When using an ORM, like TypeORM, alongside Type-GraphQL, the two have a really nice integration too. The only drawback I see with this combo (aside from the aforementioned Type-GraphQL issues above) is the fact that there is a coupling between the database model and the GraphQL API types. Some might argue that these two layers should, indeed, be coupled (to reduce duplication, right?), but as the project grows in complexity, this is less likely to be true as the two will diverge in some ways, whether you like it or not. This is where, I think, Nexus shines over Type-GraphQL since in Nexus, you have to define your API layer separately in addition to your ORM model. You do have to deal with a bit of duplication, but at the same time, you're effectively decoupling the two layers in the process. Also, I find the type completion along with the colocated schema and resolver in Nexus to be spot-on 👌 (you won't get the same experience with Type-GraphQL). This benefit is amplified when you have a lot of relations in each of your models because in Type-GraphQL, the field and resolver for that specific field are separated afaik, therefore for every relation field, you risk yourself forgetting to implement the field resolver after defining the field.

Additionally, the creator of Type-Graphql also made integration with Prisma 2 as well, which generates a whole bunch of CRUD operations (1-1 mapping with Prisma 2's rich APIs). Many-to-many relations are still not working (https://github.com/prisma/prisma/issues/4004) though, hope Prisma 2 team fixes the issue very soon.