ErrorType and ErrorDetail enums in single unified graph

[jandrade1]

Hi,

First of all, thank you for contributing the DGS framework to the open source community. It has truly made Java GraphQL service development much easier than before. It's also great to see it is a very active and well supported project from the beginning.

We are in the process of building a single unified graph for our company (One Graph) using the Apollo platform and federation. As we're still going through the process of adding more services to it, we've realized that DGS is adding ErrorType and ErrorDetails enums to the schema by default, which I understand is needed to support the TypedError as described in the docs. Using Apollo's vocabulary, these become value types in the federated schema. A potential problem I see is that if these enums ever change, we're going to face composition errors in the one graph unless all DGS services are updated to the latest DGS framework version.

From the Netflix blog posts I know that federation is also being used internally with a single graph. What are the recommendations to deal with this potential issue? I haven't found a way to disable the custom error handling (GraphQLError interface) that DGS provides and just revert to the standard GraphQL Java functionality.

Thanks!

[paulbakker]

Correct, Netflix is using the federation spec as well - we have an in-house built gateway and tooling, but the the specification is the same as Apollo (we collaborate with them on the spec as well).

We have a schema registry where all the individual schemas for DGSs are registered. The registration of a schema is a separate step in our deployment process. The tool we use to register schemas takes the schema for a DGS for registration, but does not register any schemas brought in by libraries, such as the error types.

The error types (and we have some other common types) are registered separately. Updating such types requires coordination, to make sure the existing DGSs are still compatible with the updates. In practice this means you really only ever want to do backwards compatible changes on these types.

[jandrade1]

@paulbakker thanks for the insight on how you're doing things internally, very helpful. We're registering schemas with the registry by using introspection, so everything shows up there, including those things brought in by libraries. Are you using the local schema file instead? I suppose that could be one solution.

It's interesting that you mention you register these common types separately. That's something we can consider as well to avoid conflicts between various services having different definitions of the same type. Either way, coordination is key (and tricky) as you said. It does give me some confidence though that you're keeping backwards compatibility in mind for these common types.

To my original question, and in case we want to consider this, is there a way to disable this custom error handling in DGS?

[paulbakker]

We register schema files explicitly, not using introspection.
For the shared types there is an "owner" of these types who is responsible for registering them to the composed schema. That way the shared types aren't controlled by the lifecycle of an individual DGS.

For your question about disabling: no, that's not possible currently. We're using the Java types directly in the default error handling code.

[jandrade1]

Ok, thanks @paulbakker!