Validating Relationships in a Federated Graph

We’re starting to define relationships in our federated graph and I’ve been thinking a lot about data validation around mutations.

Let’s say we have a Products subgraph and a Reviews subgraph. When we create a mutation to add a review to a product… how do we validate that the product exists before adding the review? These subgraphs are completely separate microservices with their own data stores. Obviously we don’t want to grant access to the Reviews service to query Products data directly.

There’s got to be a smarter way to handle this than firing a separate GQL query from the Reviews subgraph to the Products subgraph, right? We’re currently not allowing subgraphs to query each other so that would mean actually going back through the gateway. I’ve also just straight up considered skipping validation altogether, which maybe for this instance isn’t that big of a deal but down the road we will absolutely want to validate that the other end of the relationship exists before creating entities.

How are folks doing this elegantly?

I would avoid going across multiple subgraphs for your mutations. You can have just one top level mutation createReview which accepts the product id and review content.

As for the validation, this is no different than if you were in any other microservice or REST land. There are many ways in which you can do data validation. You could have a simple endpoint you can call from the Reviews GraphQL service to check if an id is valid, you could submit the review data to some event stream so you can do the validation outside of the GraphQL cycle, or you could submit the data to the DB and have jobs that go back later and clean up mismatching ids.

There are many options but I would keep those concerns out of GraphQL and think about how you solve it at a larger scale at your company.

1 Like