I require that any GraphQL API ships a published, versioned schema that we govern like any other contract, with consistent naming, deliberate types, and a clear boundary on what the graph exposes. A GraphQL endpoint without a governed schema is just a query surface that drifts, and consumers end up depending on fields we never meant to guarantee. I insist on this at design time because GraphQL gives consumers enormous flexibility, and that flexibility only stays safe when the schema behind it is held to a standard rather than accreted feature by feature. Every GraphQL API should treat its schema as the contract, reviewed and maintained with the same care we give an OpenAPI.
GraphQL Schema Governed
Strategies
APIs Use the Right Protocol for the Job
I want us to stop treating REST as the answer to every problem and instead pick the protocol that actually fits the job in front of us. When the interaction is event-driven we describe it with Asyn...
Experiences
Interoperability
Interoperability is the experience of APIs, systems, and data working together without heroic effort. It is built on shared standards, common schema, and predictable contracts that let one system t...
Consistency
Achieving consistency in the design, delivery, and maintenance of HTTP APIs across an enterprise is a significant challenge—one that often complicates API operations. Small differences, such as var...
Lifecycle
design_services Design Design
Design is where the human experience of an API is won or lost. I work design-first, shaping the paths, schema, errors, and naming in the contract before development begins, so that consistency is b...
