Good morning/afternoon/evening - I’m in the middle of moving my prisma1 API to prisma2 and I could use some guidance. I’ve reviewed all the docs, but I can’t quite map the old files to the new ones. I’ve taken a hybrid approach, where I created a mysql database from scratch and had prisma introspect it to create the

schema.prisma

, making tweaks to the db here and there until the prisma models look right. I’d like to minimize changes to my graphql schema and resolvers. I’m now at the point where I want to integrate prisma 2 with apollo, but I still need to create the typeDefs…? I was using prisma-binding and I can’t decide whether to do the SDL-first approach or use Nexus. Which is more popular? SDL-first seems more straightforward, but requires manually writing a new resolver for each grapqhl type… and resolvers for nested queries too…? Nexus seems like a more-natural transition away from prisma-binding, but the syntax is confusing. Any suggestions/recommendations?

We’re going through the same migration right now. I’m playing around with https://paljs.com/generator to get the SDL, which will basically be the least distance from prisma1 and give you most of the same stuff for free (seemingly), but I’m curious to hear recommendations as well

I think I still want to go the SDL route, but I’m honestly not entirely sure what I need to do to connect the

schema.prisma

and the typedefs

Hey Craig 👋 have you seen the the guide that explains the upgrade process from

prisma-binding

to an SDL-first approach?

but I’m honestly not entirely sure what I need to do to connect the 

schema.prisma

 and the typedefs

The "connection" between the Prisma schema and the GraphQL typeDefs are effectively your resolvers which are implemented using Prisma Client.

I was using prisma-binding and I can’t decide whether to do the SDL-first approach or use Nexus. Which is more popular?

This really depends on your personal preferences, lots of folks like the SDL-first approach (and it's probably the most popular in the JS ecosystem overall). If you're a fan of TypeScript, you could consider switching to Nexus since it works really well with TypeScript 🙂

@nikolasburk Thanks for the reply. I did read that and I’m still a bit confused. I have something like 35 types, many of which have a few relations (up to 10 in some cases) - manually writing resolvers for all of these relations is a little daunting. I thought the generated models would be able to help in some way, but I guess that’s just describing the database I guess I’d like to know what the pros and cons of Nexus are. Will that help me avoid having to manually write all these relation resolvers?

Will that help me avoid having to manually write all these relation resolvers?

Nexus itself won't help you with this per se as it's "just" a GraphQL schema library. However, there is an integration library for Prisma Nexus, the

nexus-plugin-prisma

which would solve this problem. Unfortunately there's another however though: This plugin is currently being rewritten and will have a different API soon. So, as for the state of tooling today there isn't really an option that helps you with the rewrite of the relation resolvers 😞 if you can wait 2-3 more months, the plugin will most likely be in a state where this is available again with a new API.

If the current

nexus-plugin-prisma

plugin would get me where I need to be, I’m fine having to upgrade later (as long as there is feature parity) this is my third time rewriting this app 😆 I finally get everything the way I want it, but now I need to upgrade everything from prisma 1 to prisma 2…. I get that this ecosystem is solving a hard problem and it’s obvious that a lot of work has been put into documentation, but man… the upgrade fatigue is real! 😅

What do you mean with "reducers" exactly? 🤔 afaik reducers are a concept from Redux in React frontends, if that's what you're asking about I don't think Nexus helps with that in any way...

@nikolasburk my bad, I meant resolvers

Can you elaborate a bit on what you mean with "handle writing of the resolvers"? Resolvers are a core component of any GraphQL server, no matter if it's SDL-first or code-first (e.g. with Nexus). So either way, you'll need to write these resolvers yourself and no schema library will do that for you 🙂 does that help?

Yes, it does help. I saw in the Nexus examples that some fields have a

resolve

function, but that doesn’t seem to be necessary for all

objectType

s. I’ll refer to the Nexus docs instead of nagging you. Thanks for the help!

Feel free to continue asking here as well 😄 (or even post your questions as GitHub discussions, that way they get answered in public and others will be able to benefit from the answers in the future too – I'm sure lots of people wonder the same things as you!)