-
Notifications
You must be signed in to change notification settings - Fork 538
A way to post-process the response #36
Comments
A nasty hack that I'm currently using to achieve this:
|
Still, although this hack allows me to sanitize the error messages, it doesn't give me an easy way to access the parsed query and variables from request body / query string. Ideally I'd like to do something like:
|
Those use cases sound like things we should support, but post-processing the response is not how I would prefer them implemented. The goal of this package is to create a standardized http interface for GraphQL, which post-processing could easily circumvent. I'll propose some paths forward:
graphql-js could already use a comprehensive logging interface, regardless of if it is accessed via http. I'd like to focus a logging interface on graphql-js itself, and just make that easy to interface via express-graphql.
Similar to the above. Sanitizing sensitive info in errors seems like an issue regardless of the access mechanism.
This just seems like the right thing to do, let's standardize that.
Could you elaborate on this? What custom headers are you planning to send? |
Turns out this was already the current behavior, but there were some other underspecified error codes which should now be correct as of 546191d |
Yes, I agree now that post processing probably isn't the best way to approach this. If logging errors and sanitizing them from responses could be baked directly into graphql-js, that would fully solve my use case.
Actually, this was just something I grabbed from another issue - seemed like something the post processing could also fix. |
I have a use case where my GraphQL resolver hits another HTTP service, which returns certain headers for data like pagination. I'd need to forward those headers to the GraphQL client that made the initial request. Is that currently supported without @mnylen's hack? |
@vitosamson How would you know which field the pagination headers applied to? |
you're right - I realized that limitation after I posted the comment. I wound up wrapping paginatable types so that they return both the list and the pagination data, and my HTTP resolvers just grab the headers from the response and add them onto the returned data. A query winds up looking like |
@vitosamson - you should check out https://facebook.github.io/relay/docs/graphql-connections.html where there are in depth docs on best practices for pagination. @mnylen - I think you're right that the best solution here is to allow GraphQL.js the ability to operate on errors to do this sort of thing. Tracking that in graphql/graphql-js#284 That said, there are still some errors that occur within this package, so having the ability to sanitize at the last step is totally reasonable. |
This provides the ability for a custom error function, as requested in #36, so that outgoing errors can be sanitized or expanded. Adds test cases to illustrate.
This provides the ability for a custom error function, as requested in #36, so that outgoing errors can be sanitized or expanded. Adds test cases to illustrate.
Anybody can show an example of how to do this:
I wasn't sure if closing the issue meant it was addressed and if it's possible to do this now. |
@guikubivan I just proved it out locally not sure if it is a good idea. It doesn't look bad to me but I would love feedback from anyone. graphqlHTTP(async (request, response) => ({
formatError: (error: GraphQLError) => {
response.status(400);
... A more real life example would do something like: import { formatError, GraphQLError } from 'graphql';
graphqlHTTP(async (request, response) => ({
formatError: (error: GraphQLError) => {
const { originalError } = error;
// add custom error logic
if(isValidationError(originalError) {
response.status(400);
}
return formatError(error);
})) |
Would be nice if there was some way of post-processing the response. Some use cases:
The text was updated successfully, but these errors were encountered: