Open gtamas opened 4 years ago
@gtamas I see what you mean. Historically, we have tried to avoid adding features like this because we always made the argument that you can simply remove the REST endpoints from the OAS, however it may be a maintenance nightmare for those who auto-generate OASs and want to use OtG in a production environment. I think we are starting to change our stance on this topic. I just wonder if it's a slippery slope.
I would like to hear the opinions of @ErikWittern and @wtrocki.
@Alan-Cha
OK please keep me posted about this. I would be happy to help implementing this, if you think it's a good idea.
Actually, I think there are many auto-generated OpenAPI schemas out there, so this might be useful for many people. In fact, our backend systems generate the OAS too.
I've been searching for exactly this capacity. The one blocker that I'm currently stuck on is that I'm unable to manipulate the resolvers in the graphql schema object created by createGraphQLSchema
.
If createGraphQLSchema
returned the type definitions and the generated resolvers separately, then users could manipulate them before building the schema and starting the graphql server.
Just a quick feature idea:
How about adding an option for blacklisting paths? This could be an array of simple objects:
Any path listed in this wouldn't be processed by OtG, so these operations would be simply ignored.
Use case
The OAS might contain REST endpoints that we don't want to expose through GraphQL for whatever reason, eg: security concerns, the endpoint is for internal use, risk of unwanted traffic increase via GraphQL etc. However, we cannot simply remove these from the OAS, since they still have to be usable as REST endpoints, Swagger needs to see them etc.
What do you think? I guess it would be easy to implement this and it might be useful.