0

A client is sending inputs to our graphQL mutation that are not part of the schema because the inputs were removed. Eventually, they catch up and remove the inputs so they're not sending them anymore. In the meantime, I'd like to filter out those inputs so the client doesn't get an error breaking their integration.

Parse Phase parsingDidStart that I can use to validate input is in the schema before calling a mutation so I can filter it out?

To add more context, the client doesn't use the inputs directly in their app, the client acts as a funnel sending us users along with answers to some questions that we forward along to a third party to accept or reject. The 3rd party could reject the questions if we're not sending them over on the client's behalf which isn't ideal, but there's messaging and support around that use case vs an app crash.

Ideally, we'd like to be able to deprecate input values but that was just introduced into the GraphQL Allow deprecation of input values spec and not available yet.

Thank you! Laura

Laura
  • 139
  • 1
  • 11
  • 3
    Have a look here for some tips: https://stackoverflow.com/q/37397886/2557263. But the question I have is why to delete input fields? That's a breaking change. A better option would be to document them as "unused" or "obsolete" and ignore them, so clients won't break. If a breaking change is unavoidable be sure to clearly document a date where you'll publish it, so clients can update in advance. – Alejandro Jun 29 '22 at 18:02
  • @Alejandro thank you! I'll check that out. Ignoring them would work too if that's easier. We give them a list of fields to remove but our partners are slow to make those updates and in the meantime, they're still sending users to our app and if it breaks that's a bad experience for the end-user. I looked into deprecating inputs but it looks like that's not yet supported, recently added to the graphQL spec. – Laura Jun 29 '22 at 19:03
  • I'm not sure that will work because I'm trying to remove the inputs from the request to a mutation that is sent from a third party that I don't have control over. Can I call a query mutation from the parsingDidStart Apollo Server plugin? – Laura Jun 30 '22 at 00:43
  • @Laura Won't ignoring those input values also break their app functionality? – Bergi Jul 01 '22 at 21:52
  • @Bergi it's a bit complicated because we just forward along these inputs as the questions to a 3rd party to accept or reject the question sets. Any rejection from the 3rd party (a REST API) is handled manually anyway and is better than an app crash. Other than forwarding the questions along, the client doesn't use them. We have to make these changes to conform to the 3rd party API but it's a REST API so it's not as strict, and this client is only a subset of users using a very specific mutation with breaking inputs. I can update the question with more context. Cheers. :) – Laura Jul 01 '22 at 23:18

1 Answers1

0

After much digging, I figured out something I think will work after I ran across this issue 3169). The suggested approach is to use the exposed methods getVariableValues or buildExecutionContext to validate the variables in the parsingDidStart step before calling the execute. The part was unintuitive to me, I was expecting variables to be validated in the validation framework. This article also helped, particularly the part on who is responsible for what. https://www.apollographql.com/blog/graphql/error-handling/full-stack-error-handling-with-graphql-apollo/

Bad User input is calculated in the execution step, so that’s after parsingDidStart, and validationDidStart and even executionDidStart. Errors are added by executing in the buildExecutionContext as part of execute. I can then parse the errors and filter out the variables that should be ignored.

Good explanation of GraphQL internals... https://www.youtube.com/watch?v=IqtYr6RX32Q

Laura
  • 139
  • 1
  • 11