In trying to use more Redwood Resolver Types in our services, we noted something interesting and we’d like to discuss what the Redwood path on this should be.
We have a property in one of our models called path. In the prisma model, it is defined as:
path String?
It is actually a comma-separated string and in the sdl, it is defined as:
path: [String!]
The generated resolver type resolves as:
path: string
As the same property name is used in the Prisma schema and the graphQL schema, in this case, the Prisma schema takes precedence by the Redwood generated types. Obviously, this is incorrect and the immediate solution would be to either change the name of the property in the sdl file or generate custom resolver types.
However, what should be the documented Redwood take on this?
a. Should properties with the same name and different types be allowed between the Prisma model and graphQL model? Without delving into the Redwood internals, it is not obvious why this doesn’t work.
b. If allowed, should the graphQL type take precedence? (I would say so)
Note: This could easily morph into a bigger discussion about Redwood’s general assumption regarding a thin API business logic layer with minimal abstraction between the DB and the graphQL API. In some cases this is reasonable, but this is not always the case. There are other Redwood resolver type issues we are facing when graphQL types are not based on a Prisma model, but I’d like to start with this specific question first.
What are your thoughts on this?
