Can apollo server return a partial success if one element of an array is invalid?

Question

Say I have a query that returns an array of Customer objects, each one having an id, name, and email, all of which are non-nullable. My resolver loads the data from some source, maybe a database or maybe a downstream system. Most of the data that comes back is fine, but maybe for some reason we're missing the email address for a single customer.

Currently if my resolver just returns the array of all known customers, including the dodgy one, then the entire operation will fail with something like:

{
  "data": {
    "customers": null
  },
  "errors": [{
    "message": "Cannot return null for non-nullable field Customer.email"
    // More error stuff here
  }]
}

I get that the validation is supposed to be strict, but now on my UI it fails to load the entire list of customers just because one of them is invalid. It makes it too easy for a single record to poison the entire database.

What I would like is a way to still return the error, but to also have the data field be populated with all of the other, valid Customer records. Is this possible to do with apollo server? Or do I need to manually validate all of the data before trying to return it from my resolver? That would be quite arduous as my real data structure is much more complex.

Answer 1

From this discussion, it seems there's no way to do exactly what I was asking (filter out the invalid records on the server side).

The right approach to this is to either:

1. Make the email field nullable, so the server can return every Customer, some of which may have incomplete data; or
2. Make the elements of the top-level Customer array nullable, so the server can return e.g. [customer1, null, customer3]

Option 1 means that the client gets access to more data on an error, so it could still show the rest of the customer's details even if the email is missing. However it makes the data structure less reliable as now anywhere that uses the email might need to do a null check.

Option 2 is a more aggressive failure, nulling out the entire customer because of a single bad field. But it makes it simpler for the client to filter out bad customer records at the top level, allowing the rest of the frontend code to be confident that every customer has an email address.

On that basis I think I prefer option 2.