

Now, if we’re considering implementing a GraphQL layer at the backend, it would only make sense to follow the one graph principle of GraphQL: this says that to maximize the value of GraphQL, we should have a single unified data graph that’s operating at the data layer of this product. This product would essentially have multiple teams responsible for maintaining different modules of the product. To summarize his point, let’s consider a very complex enterprise product. James Baxley III, the Engineering Manager at Apollo, in his talk here, puts forward the rationale behind choosing an independently managed federated set of services very well. Having said that, it can be challenging to follow this principle for an enterprise-level application on a single, monolith GraphQL server. One of the key principles of GraphQL involves having a single data graph of the implementing services that will allow the client to have a unified interface to access more data and services through a single query. With the thin layer of GraphQL middleware, the client has the ability to query the data more comprehensively than what’s provided by the usual REST APIs. GraphQL has revolutionized how a client queries a server.
