A structured analysis of how complexity is distributed across four API architectural patterns: REST, GraphQL, Federated GraphQL, and WunderGraph's Fission. Using Tesler's Law of Conservation of Complexity as a framework, the post traces five core concerns (data fetching, security, caching, contract management, and governance) and shows how each moves rather than disappears as you shift architectures. REST pushes data fetching to clients and leverages infrastructure for security/caching. GraphQL centralizes fetching server-side but moves security and caching into application code. Federation distributes runtime concerns across teams but creates human governance bottlenecks. Fission inverts the design process to move governance from humans to design-time tooling, though it introduces its own tooling complexity. The conclusion is that architecture is about deciding where complexity lives, not eliminating it.

19m read timeFrom wundergraph.com
Post cover image
Table of contents
The ScenarioRESTGraphQLFederated GraphQLFissionThe Responsibility MapWhat This MeansHow WunderGraph HelpsReferences

Sort: