5 ms·
In my experience, nothing other than nullable DB fields should be nullable in the GQL schema. Everything else like inter-service problems, auth problems, etc, s
by merrywhether 2y ago
In my experience, nothing other than nullable DB fields should be nullable in the GQL schema. Everything else like inter-service problems, auth problems, etc, should be modeled as “result boxes” via union types (somewhat equivalent to Maybe/Optional types). This lets your schema model possible failure cases via strong types without ambiguity and results in resilient front-end code.
Note that the error types added to the union should only be as granular as relevant to the client. Most places will be just Foo | FooNotFound | FooError because your UI doesn’t care why there was an error and you don’t want to unnecessarily leak backend info when it’s not relevant.
I wish this was more strongly recommended in the GQL org docs, because so many people learn it the hard way and migrating is not easy.