Hmm, this is a really good questions and would definitely require a bit more information about the customer relation to fully answer.
In a setup where you can deprecate fields and remove them after X weeks I think it could wor well - My impression is just not that enterprise works like that?
I would probably go the route of having fully versioned APIs in the specific setup (GraphQl or not) - which is something that would be a hassle with a tight coupling between the Prisma schema and the GraphQl schema as proposed.
Thinking about it, all the situations where I have successfully used GraphQL, there has been a relatively tight coupling between the database schema and the graphQl schema. Previously it has been Ecto + Absinthe + Zeus (Elixir on the backend).
You’re right that there will need to be long-term support of API versions (or at least the current one and maybe the previous one).
My instinct is to give the users the full objects and let them select the fields they want on their side. It’s less work on our side. Also I’m not sure about customer comfort with GraphQL.
Where GraphQL really shines is in the synthetic fields - the ones that are just too expensive to compute for all requests, but kind of make sense to have en the entity.
Most interesting applications have some type of properties of entities that transcent a static object.
In a setup where you can deprecate fields and remove them after X weeks I think it could wor well - My impression is just not that enterprise works like that?
I would probably go the route of having fully versioned APIs in the specific setup (GraphQl or not) - which is something that would be a hassle with a tight coupling between the Prisma schema and the GraphQl schema as proposed.
Thinking about it, all the situations where I have successfully used GraphQL, there has been a relatively tight coupling between the database schema and the graphQl schema. Previously it has been Ecto + Absinthe + Zeus (Elixir on the backend).