Whether you are a large company or a single developer, we all want to know the best way to design an effective architecture – the schemas, services, folders, and so on. We find ourselves asking “Should we start with a modular monolith? Should we use microservices?”

These early architectural questions are important because they affect so many aspects of the way we work, making it easier or harder to divide work, understand the code, and scale-up in the future.

Before we can explore some of the more nuanced, technical topics, we need to learn some basics ways to think about a federated architecture.

In this post, we’re going to learn what federated architecture is and why we would want to use it.

What is a federated architecture in GraphQL?
When developing a GraphQL monolith, the architecture is straightforward. Clients talk to your GraphQL monolith, and that monolith connects to the various data sources you have. The GraphQL server determines what data sources to interact with based on the incoming query and the necessary resolvers. We typically represent the details of some parent type or fields in a downstream resolver using some bit of code in the project.

Each GraphQL server provides a portion of the schema in the overall graph in a federated architecture. We call these GraphQL servers subgraphs. We can combine these subgraphs through metadata defined in their schemas to establish relationships in the graph: