Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Federated GraphQL is one logical GraphQL API assembled from several independently owned services. Each service, called a subgraph, defines the part of the graph it owns. A composition step combines those schemas into a supergraph, and a router exposes the supergraph to clients. The router validates a client operation, builds a query plan, fetches fields from the responsible subgraphs, resolves shared entities when necessary, and merges the results into one response.
Clients normally send requests only to the router. They should not discover or call subgraphs directly: keeping that boundary lets the router enforce the composed schema, authentication policy, and execution plan.
The pieces of a federated GraphQL system
Subgraphs
A subgraph is a GraphQL service owned by a team or bounded domain. An inventory subgraph might own product availability, while a reviews subgraph owns ratings and review text. Each subgraph can be deployed and evolved independently, provided its contribution remains compatible with composition rules.
A subgraph schema includes federation-specific additions. When it contributes fields to an entity, it must support the federation machinery needed to resolve that entity through Query._entities, whose specification is Query._entities(representations: [_Any!]!): [_Entity]!.
Recommended Free Tools
#1 Best Overall
Supergraph schema
Composition combines the subgraph schemas and federation metadata into a supergraph schema. The result records which service owns each field and how services can hand an entity from one service to another. The supergraph is an execution contract, not usually the endpoint clients call directly.
Router
The router serves the client-facing GraphQL endpoint. It uses the composed supergraph to validate operations, construct query plans, call subgraphs, and merge their payloads. Apollo describes this model as declaratively combining multiple APIs into a single federated GraphQL API and having the router intelligently distribute requests across those APIs.
What happens when a client sends a query
- One request arrives. The client sends a normal GraphQL operation to the router.
- Validation occurs. The router checks the operation against the API schema exposed by the supergraph. Unknown fields, invalid arguments, and type errors are rejected before downstream work begins.
- A hierarchical query plan is built. The planner identifies the subgraph that owns every requested field. Independent root fetches can run in parallel; dependent work waits for data from an earlier fetch.
- Root data is fetched. The router calls the subgraph that owns the operation’s root fields.
- Entities cross service boundaries. If another subgraph contributes fields to an object, the router carries the object’s
__typenameand key fields in an internal representation. _entitiesis called downstream. The receiving subgraph resolves those representations and returns the additional fields.- The response is merged. The router combines all payloads into the shape requested by the client, preserving GraphQL’s normal data and error structure.
For example, a client can request a product’s name and reviews in one operation. The Products subgraph returns the product and its upc. The router then sends a representation such as {"__typename":"Product","upc":"..."} to the Reviews subgraph, which resolves the review fields.
Entities and the @key directive
An entity is an object whose fields may be supplied by more than one subgraph. A subgraph marks an entity with @key(fields: "..."). The key is the field set another service needs to locate the same object.
Free tools Windows power users keep installed
One-click scans. No signup required.
A minimal two-subgraph example
The Products subgraph can own identity and core data:
type Product @key(fields: "upc") {
upc: String!
name: String!
}The Reviews subgraph can extend that entity:
extend type Product @key(fields: "upc") {
upc: String! @external
reviews: [Review!]!
}The exact federation syntax depends on the federation implementation and directives enabled by your platform, but the contract is the same: the downstream resolver receives representations containing __typename and every field required by an applicable key. Results must be returned in the same order as the representations.
Designing a good key
- Use a stable identifier that every participating service can resolve.
- Keep the key small; extra key fields increase payload size and coupling.
- Make the lookup highly available, because a key-resolution failure affects every request that crosses that boundary.
- Use one entity only when multiple services genuinely contribute fields. Do not mark ordinary value objects as entities just to share types.
Federation directives that describe ownership
Federation is declarative: schema directives communicate ownership and cross-service requirements to composition and the router.
| Directive | Purpose | Operational implication |
|---|---|---|
@key |
Declares the field set used to identify an entity. | The router can create representations for another subgraph. |
@external |
Indicates that a field is defined by another subgraph but referenced locally. | The local schema can use the field for keys or requirements without claiming ownership. |
@requires |
States that resolving one field needs additional fields from the owning subgraph. | The router includes those fields in the internal fetch plan. |
@provides |
Describes fields a relationship can supply from the current subgraph. | Composition can understand where a field is available along that path. |
@shareable |
Marks a field that can legitimately be resolved by more than one subgraph where supported. | Composition can distinguish intentional sharing from conflicting ownership. |
Composition should reject incompatible contributions before they reach production. Treat those checks as a schema-governance gate, not as a runtime discovery mechanism.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Reading a query plan
A query plan is a tree of execution steps. A simple plan may contain one fetch. A federated plan commonly contains a root fetch followed by a dependent entity fetch:
QueryPlan {
Fetch(service: "products") {
{
product(upc: "1") { __typename upc name }
}
}
Flatten(path: "product") {
Fetch(service: "reviews", requires: ["upc"]) {
{
... on Product {
__typename
upc
reviews { rating text }
}
}
}
}
}The syntax shown is illustrative rather than a universal serialization format. The important distinctions are:
- Parallel branches: independent root fields can be fetched at the same time.
- Serial dependencies: an entity fetch cannot start until its key fields exist.
- Fan-out: a list of entities may produce a large batch for
_entities. - Flattening: the router places downstream fields back into the original response path.
Inspect plans for unnecessary hops, repeated entity lookups, and unexpectedly wide selections. A client operation that looks like one request can still create several network calls and a substantial tail-latency risk.
How to introduce federation safely
- Map domain ownership. Assign each field and entity to a team that can operate and support it.
- Choose entity keys. Confirm that keys are stable, indexed, and available in every environment.
- Define subgraph schemas. Add only the fields a service truly owns; use federation directives for relationships and requirements.
- Compose in continuous integration. Publish a candidate supergraph and fail the build on ownership conflicts, invalid directives, or incompatible type changes.
- Run representative operations. Include high-cardinality lists, nested entity fields, authorization failures, and missing records.
- Inspect query plans. Look for avoidable serial fetches and fan-out before production traffic reaches the router.
- Instrument the whole path. Correlate router traces with subgraph traces so a slow downstream resolver is distinguishable from router overhead.
- Set failure policies. Define downstream timeouts, retry limits, and how partial data and errors should be exposed.
- Document compatibility. Record the federation directives and version supported by each subgraph, along with the publication and rollback process.
Performance, reliability, and security trade-offs
Latency and network hops
Federation can reduce client round trips, but it does not eliminate backend calls. A dependent entity fetch adds at least one hop, and nested lists can amplify work. Measure p50 and tail latency for real operations in your graph; there is no universal federation latency or cost figure that applies to every deployment.
Partial failures
A subgraph may time out, return authorization errors, or be unavailable while other fields succeed. Decide whether the router should return partial data with GraphQL errors, fail the whole operation, or apply a field-specific fallback. Retries need strict budgets because retrying a slow dependency can worsen an incident.
Entity resolver load
Entity resolution can resemble an N+1 problem when a list creates many downstream lookups. Batch representations, use bounded concurrency, and monitor the size and duration of _entities calls. Avoid putting expensive, highly volatile computations behind a key that appears in many lists.
Security boundary
The router is the intended client boundary. Keep subgraphs private to the router where possible, authenticate and authorize at the appropriate layer, and avoid exposing internal federation fields as a public API. Validate custom headers and propagated identity consistently across downstream calls.
Observability
Log a correlation identifier at the router and every subgraph. Capture the operation name, selected query plan, downstream timings, error class, and entity-batch size while applying your privacy policy. Without plan-level tracing, a single slow field can be difficult to distinguish from a slow entire operation.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Federation versus schema stitching
Both approaches present a unified graph while data remains in multiple services, but they place the integration work in different locations.
| Decision axis | Federated GraphQL | Schema stitching |
|---|---|---|
| Ownership model | Subgraphs declare ownership and relationships in federation metadata; the router composes them. | An integration layer combines or transforms schemas, often centralizing more mapping logic. |
| Release independence | Designed for independently owned services with composition checks. | Can work well when a central gateway controls integration, but changes may require coordinated transforms. |
| Runtime behavior | Router-generated plans use entity representations and _entities for cross-service fields. |
The stitched gateway executes the rules and delegation model defined by its stitching setup. |
| Governance | Composition makes ownership conflicts visible before publication. | Governance depends on the stitching toolchain and gateway review process. |
| Feature fit | Strong fit for domain-owned graphs and incremental decomposition. | Can be attractive when existing schemas need to be combined or when a required feature is not available in the chosen federation stack. |
Neither is universally superior. Compare team boundaries, composition workflow, query-plan complexity, failure behavior, tracing maturity, hosting cost, and required features. Subscriptions are one example where a stitching approach may be considered, so evaluate the operations your clients actually need.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common implementation problems and fixes
Composition fails with an ownership conflict
Cause: two subgraphs claim the same field without an allowed sharing declaration, or a field’s type and nullability disagree.
Fix: assign one owner, mark intentional sharing with the supported directive, or make the type definitions identical before publishing.
An entity fetch cannot resolve records
Cause: the representation lacks a required key field, the key is not indexed, or the downstream resolver does not preserve representation order.
Fix: verify the @key field set, inspect the router’s representation payload, add a bounded batch lookup, and return results in exactly the input order.
Queries are unexpectedly slow
Cause: serial dependencies, high fan-out, a slow resolver, or retries extending the critical path.
Fix: inspect the query plan, parallelize independent roots, reduce selection sets, batch entity resolution, and set explicit per-subgraph timeouts.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchClients receive partial data and errors
Cause: a downstream subgraph timed out, rejected authorization, or failed after another subgraph had already returned data.
Fix: classify errors, document field-level guarantees, and choose a deliberate partial-response policy instead of relying on default behavior.
A subgraph is reachable directly
Cause: network policy treats the subgraph as a public API.
Fix: route client traffic through the router, restrict inbound access to trusted router identities, and apply authentication consistently at the boundary.
Best Value
Capturing a visual record of GraphQL documentation
Teams sometimes need screenshots of a GraphiQL or API-documentation page for a runbook or release note. You can do that manually in a browser, but an API is easier to automate for a stable URL.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. Give it a URL and it returns PNG, JPEG, WebP, or PDF. Before capture it accepts the cookie or consent banner and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each cleanup step can be disabled. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents such as Claude and Cursor.
For a documentation page at https://your-router.example.com/docs, use the [API documentation] examples:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://your-router.example.com/docs -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://your-router.example.com/docs"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://your-router.example.com/docs' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);Free use includes 1,000 screenshots each month with no card. Paid plans start at $5 for 3,000 shots; yearly billing gives two months free, and every feature is included on every plan. Create a free ScreenshotNeo account.
When federation is a good fit
- Several domain teams need independent deployment and ownership.
- Clients benefit from one graph instead of coordinating calls to many APIs.
- Your organization can operate a router, composition checks, tracing, and schema governance.
- You have stable entity identifiers and clear rules for authorization and failure handling.
A monolithic GraphQL server can remain simpler for a small team or tightly coupled domain. Federation earns its operational cost when independent ownership and a unified client contract solve a real organizational problem.
Frequently Asked Questions
Do clients ever query a subgraph directly?
They should not in a federated deployment. The router is the client-facing boundary and the component intended to query constituent APIs.
What must an entity representation contain?
It contains __typename and every field required by at least one applicable @key. The receiving resolver returns entity objects in the same order as the input representations.
Does federation guarantee faster responses?
No. It can remove client-side round trips, but the router may perform several downstream calls. Measure the query plans and tail latency of your own graph.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesCan a federated graph return partial data?
Yes, depending on router and schema error policy. A downstream timeout or authorization error can leave other fields available, so define and document the behavior your clients should expect.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
