How to handle array of objects which may or may not exist?

[Lexicality]

I'm having some problems fixing up an existing schema made by someone else and I'm not sure how to solve one particular problem involving data corruption.

I have some models on one service that have a data structure like

type ObjectOne {
	id: ID!
	# ... various fields
	otherObjectIDs: [ID!]!
}

however some of the objects referenced by otherObjectIDs do not exist. (Let's assume here that I cannot fix the database)

Currently this is implemented as

type ObjectOne {
	id: ID!
	# ... various fields
	otherObjectIDs: [ID!]!
	otherObjects: [ObjectTwo]!
}

and the resolver substitutes null in place for missing objects.

This works, but the user gets no error for it which can sometimes result in an entire array of null values if something fails for a different reason which is a problem.

I have discovered that I can work around this in an extremely ugly way by doing something like

type ObjectTwo {
	id: ID!
	name: String!
}

type ObjectTwoWrapper {
	id: ID!
	object: ObjectTwo
}

type ObjectOne {
	otherObjectIDs: [ID!]!
	otherObjects: [ObjectTwoWrapper!]!
}

export const resolvers: Partial<Resolvers> = {
	ObjectOne: {
		otherObjects: (parent) =>
			parent.otherObjectIDs.map((id) => ({
				id,
			})),
	},
	ObjectTwoWrapper: {
		object: (parent, _args, { dataSources }) =>
			dataSources.objectTwo.get(parent.id),
	},
}

and the resolver ObjectTwoWrapper.object is invoked once per ID in the list and if it throws an error that gets sent to the user correctly

However this is a breaking API change! How do I get the same behaviour without changing my API?

[trevor-scheer]

I'm going to ignore the wrapper approach for now, that's not really ideal and I think you can accomplish what you're after with a resolver change and no schema change.

I think what you're looking to do is throw an error for a single list item without blowing up the whole list. You can do that, you just need to throw an error from one of the field resolvers on the type of the list item. If you return null in your list, those resolvers won't run so you can't throw an error. If you return, say, an empty object instead, the resolvers will run and you can throw an error at that time.

Here's a sandbox which should demonstrate what I mean.

In the example, I provide 3 items in the list:

• One that's fine, no issues
• One that's an empty object, so it's missing the id
• One that's null

Notice for #2, I can throw an error from the Thing.id resolver which still results in a null Thing in the list, but there are errors for the client. For #3, the id resolver never runs, so I can't throw an error from there.

Run query:

{
  things {
    id
  }
}

It's also worth mentioning that the otherObjectIDs field is really an antipattern and is representative of "not thinking in GraphQL". Really you just want to ask for {otherObjects { id }} (read as: the id of each item from the list of otherObjects).

[Lexicality]

That's a very interesting solution. I don't like it, but I can see that it'd work. I can return something like { __error: new Error("uh oh") } and then make every non-null field throw that error.

My main problem is that I have a lot of objects which all have a lot of fields, and most of them are nullable. (Presumably because the person who wrote this initially was unaware that this was a thing)

Can I override the default field resolver somehow? The alternative is going to be using a schema mapper to override every single field which seems like a bad idea.

It's also worth mentioning that the otherObjectIDs field is really an antipattern and is representative of "not thinking in GraphQL".

Sums up this entire codebase tbh. I can't remove it, both because some legacy clients use it and because otherwise the typescript resolvers scream about undefined fields. I've slapped a lot of @deprecated directives around.

[trevor-scheer]

@Lexicality if this is a pattern throughout and you're looking to implement a convention for this like you suggested:

{ __error: new Error("uh oh") }

...the willResolveField plugin hook could be used to look for that and throw if it finds it that property on the source object. willResolveField is basically a middleware for your resolvers. I updated the codesandbox to illustrate.