An Introduction to Federated GraphQL — and WunderGraph Cosmo
In an ideal version of this world, your monolithic backend would be modularized and factored into discrete services with well-defined boundaries. You’d have a GraphQL server (graphql-js, Apollo Server, graphql-yoga, etc.) for each backend, connecting to databases and other APIs to resolve the data they need to serve, and each frontend would use some implementation of a GraphQL client (Apollo Client, Relay, urql) for easy querying/mutating/caching data. Instead of taking advantage of GraphQL’s capability to consolidate data retrieval into a single request, you’re distributing the data-fetching logic across the client instead — querying large amounts of data from a bunch of different graphs, and then aggregating it into a cohesive view in the client layer. You’re needlessly complicating your client-side code, adding network overhead, introducing consistency issues (different parts of data being at different states), and …basically, undermining GraphQL itself.
Instead, let’s talk about federated GraphQL as a solution to this, and see how WunderGraph Cosmo can help you implement federated graphs that augment your modular, microservices-based development, help you scale up and move fast without breaking things — and if you’re coming from Apollo GraphOS? Migrate over with just one click. Federation — an architecture and specification created by Apollo — asks a simple question. What if you had a single, unified graph for all your data, seamlessly combining distributed services (with their own schema, server, and data) into a cohesive whole?
0 Comments