Support for GraphQL requests with partial results

Thanks for this great library! It’s a pleasure to use. While integrating it I ran into an issue which might be caused by lack of understanding on my side.

Is your feature request related to a problem? Please describe.

When using GraphQL requests which for instance load different parts of data such as

query MyQuery {
   myOrders {
      total
   }
   myProfile {
      name
   }
}

then this query can partially fail. In the example above the myOrders could be resolved while the myProfile can fail and be null. The resulting response could be something like

{
   data: {
     myOrders: {
        total: 42
     },
     myProfile: null
   },
   errors: [{
      path: 'MyQuery.myProfile',
      extensions: { code: 'foo' }
   }]
}

I don’t see a way to support this case via msw and the graphql mocking system. The errors context to how I read it’s code terminates the request. While the data context seems to be a shorthand for json.data(). As a result I can’t use both as in ctx.data and ctx.errors. While ctx.json is not exposed when using graphql. Mocking the request via rest feels cumbersome as matching the query is hard.

Describe the solution you’d like

Either the errors on ctx does not terminate the request and allows for combination with data or json is exposed on the context when using graphql.

[kettanaito]

This has been implemented in https://github.com/mswjs/msw/pull/403. Will be released in the next minor version of msw.

Thank you, @tdeekens, for a superb work on this! 🎉

[emmenko]

I’m not sure exposing the json method is what we want here.

I like the fact that graphql/rest handlers expose only a set of methods that make sense to their respective APIs. GraphQL has a very well-defined and strict spec for the response format (data and error) and allowing people to just pass any arbitrary JSON feels out of place.

As a user, as I suggested before, I would imagine to have a dedicated method for covering the use case of partial results. This has some advantages:

• like for data() and errors(), it’s very clear what the intent is
• it’s easier to type, as using such dedicated method requires you to define both data and errors objects
• it fits with the GraphQL format, as partial results is something specified in the spec

Just my 2 cents…