Confused with making changes in application schema, generated model, resolvers codegen and Prisma's role

prisma

#1

Question: If I define a graphql schema at application server, different from or independent of Prisma datamodel, do I lose all the benefits of generated models, and graphqlgen generated resolvers?

I understand that this is more of a confusion from me, than a question, and I had asked something similar earlier too.

Also, correct me if I am wrong, but I understand that each Prisma service is a connector that knows how to talk to a certain DB and prisma generate gives us a model that abstracts DB queries in multiple such connectors for our application level resolvers.

Going by this, I believe that a model should be tailored from connectors (to abstract them is its job), like Prisma does (Prisma does that, right?). And that since model abstracts away any array of backend services, my application level schema/API should be independent of the model, because resolvers talk to model and the model could take care of any query to any connected backend resource. Application API is independent of models, right?

If so is the case, how do I add new types to application server schema, such as changing a type in Prisma datamodel (e.g. type AddressType) to an enum field on in the app schema? Any change would cascade, that is, relations such as AddressType <- Address <- User <- Post, so should I rewrite all of the schema here again, if not, what’s the right way to import from Prisma.graphql and make necessary overwrites? How should I use graphqlgen with this constraint?

Currently, I have an understanding that I should define an independent app schema with tool like graphql-code-generator to generate resolver signatures, where in resolvers I would use Prisma client to use the Prisma generated model via context param. What is wrong about this, or what are its constraints, if any? What is the most speedy approach to my problems?

If this post appears to you more of a confusion, that a query, it’s because I am confused! Please pull out some time to guide me, I am stuck in this spiral…

EDIT: I am reading this github post by tim and it confirms my assumptions as I see it. I am keeping it open since I need to fundamentally get this right!

EDIT2: Had quit graphqlgen after facing the (open) issue, where it got itself in an infinite loop. Reading its docs again, and realising again that I could define whatever schema at app server, plus a model file, and resolvers would be generated with Prisma context.


#2

When you have a prisma/graphq-yoga application, you really have two separate graphql apis which each have their own schema. We will call them application schema and prisma schema

It is quite common that the application schema be a subset of the prisma schema. This is why it is common to import part of the application schema from the prisma schema. Graphql-Import is a tool that helps with that.

Here is an example from a project of mine, where I use the prisma schema as the base for my application schema and then made the required changes.


#3

Thanks @BenoitRanque for your reply :slight_smile: I didn’t even know about override as an option. So, w.r.t. my case, could I override a type AddressType with enum AddressType, does this count as an override (I mean, enum and type have different meanings in graphql, right?)?

Also, as you have suggested, I could do import Query.*, * from "./Query.graphql" to add any new type as I please (that is, a type that is not already present in generated schema to be overridden), right? But, for these types, if I want graphqlgen to work, I only need to define model for them (interfaces basically), right?

Finally, do you prefer to fully decouple your application schema from generated one, or such a coupling is totally safe as codebase grows? [Prisma is generating a schema of 17k LOC, I am sure more than my career sum total :smile: ]


#4

Regading overrides: I’m not sure about overiding a type with an enum, but my guess it it should work without issue, simply use the same name.

Regarding decoupling: the generated schema is simply a starting point. You are not forced to update it, and you could feasibly not use a generated schema at all. From your application’s point of view, that schema file is no diferent than the others, and you could write it manually.

Realistically your application is probably tied to your datamodel, so it’s nice that is you add a field, you can generate the updated schema and be don with it, instead of generating/updating all the required types yourself (the multiple input types)


#5

@BenoitRanque Regarding that enum vs type override query, why do I not just try and see! :slight_smile: (Time to sleep right now though :slight_smile: )

With my limited experience, as I understand graphql’s schema first development approach (as I read) allows me to think of application schema from a front end agreement perspective, since I could be having many datamodels for multiple backends. I understand that you are saying that use what the generated schema has, and write in application schema whatever different I need (via override).


#6

Correct. By the way if you have multiple backends you can easily create a single application schema from multiple generated prisma schemas. Just make sure there are no overlaps in the names.


#7

That too makes sense @BenoitRanque I don’t have multiple backends for now, have some rest endpoints (third party APIs), but I can see that I could need multiple backends too in the future. I will move with this information and get back for help if needed. Thanks a lot for all your time and help :slight_smile:


#8

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.