Replies: 1 comment
-
A suggestion to overcome this issue would be by using graphql-federation. Create a public graphql service which includes all schemas/objects/resolvers which are required to be public. And extend on the public schema for the additional fields using graphql-federation so that the types can have more fields, more resolvers can be accessible. Afterwards you will have an endpoint for the public API and a seperate one for the federation API which combines the private and public part. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
I’ve recently started using TypeGraphQL to add GraphQL functionality to an Express server. I found answers to most my questions through the very nice examples you’ve put together, though I’ve got one remaining:
I would like to expose two different flavours of my API on two different endpoints, which in itself is not a problem, except that I would like to avoid duplicating code. As for resolvers I figures I could have a “public resolver” class which I could extend with “private” queries and mutators, using the first one to build the public schema and the second to build the internal one should do.
Though this would not allow me to add “private” fields to types without having public/private types concurrently in the schema.
I was wondering if there is another way to achieve this ? Note: I’m only looking at influencing schema generation and/or introspection, I would completely expect that I need to add authorisation to ensure security. I looked into customer decorator as they seemed to provide the right granularity, though it seems I can only have then influence API results, not schema generation or introspection.
Thanks in advance for any light you could shed on this. If needed I’d be happy to contribute to the project to achieve that in a generic manner.
Regards,
Denis
Beta Was this translation helpful? Give feedback.
All reactions