kenstott
commented
5 days ago The extensions field in a GraphQL response is designed for any additional data that might enrich the response. Think of it as a flexible space for metadata, performance stats, tracing information, or anything else that doesn't neatly fit into data or errors. It's intentionally broad to allow for a variety of uses. In the spirit of the GraphQL standard, Plugins should allow for augmentation of a response, particularly for extensions. That's the whole point of the design of the GraphQL response.
Similarly, for errors - but less important - it could be valuable to augment the errors if the error is related to the plugin operation. For example, "Unable to do XYZ...because...".
Augmenting or modifying the data has the fewest use cases—or maybe even argues for a different design (like an NDC proxy/plugin as an alternate).
However, data masking could be a use case and incorporated into the plugin design if data modification is allowed. It's a universal security policy - not a data source issue.
Another good use case would be "sampling". I don't really want all the data I asked for returned. I want a random sample.
I would use headers as way to invoke an optional plugin like the sampling use case. Plugins should be able to see all headers passed into the request.
Component
Is your proposal related to a problem?
This is the forum for users to provide comments on the DDN engine plugin feature.