Most microservice failures stem from invisible dependencies rather than architectural flaws. A taxonomy of seven coupling types is presented (domain, data, temporal, pass-through, common, contract, organizational), and GraphQL Federation's @requires directive is shown as a mechanism to make all of them explicit. With @requires, cross-service data dependencies move from hidden HTTP calls in application code into the schema itself, where they are validated at composition time, visible in query plans, and enforced at build time rather than discovered during production incidents. The post also covers @provides as a companion directive, warns against overusing it, and argues that correct service boundary design (one team, one service) is a prerequisite before any tooling can help.

16m read timeFrom wundergraph.com
Post cover image
Table of contents
The Taxonomy of Microservice DependenciesThe Real Problem: Implicit vs. ExplicitSo What Can We Do About It?A Brief Primer on GraphQL FederationHow @requires Makes Dependencies ExplicitThe Power of Explicit: What You Can See, You Can ManageField-Level Precision: Not Endpoints, FieldsA Note on @providesService Boundaries: The Root Cause Most Teams MissThe Industry Is Stuck on ImplicitConclusionFrequently Asked Questions (FAQ)

Sort: