GraphQL, despite the name, isn't simply a query language. It's a comprehensive solution to the problem of connecting modern apps to services in the cloud. As such, it forms the basis for a new and important layer in the modern application development stack: the data graph. This new layer brings all of a company's app data and services together in one place, with one consistent, secure, and easy-to-use interface, so that anyone can draw upon it with minimal friction.
At Apollo, we've been building industry leading data graph technology since 2015, and we estimate our software is now used in over 90% of GraphQL implementations. Over the years, we've had thousands of conversations with developers implementing GraphQL at companies of all sizes. We want to share what we've learned, so we've distilled their experiences into a set of best practices for creating, maintaining, and operating a data graph. We present them here as 10 GraphQL Principles, broken out into three categories, in a format inspired by the Twelve Factor App.
Your company should have one unified graph, instead of multiple graphs created by each team.
Though there is only one graph, the implementation of that graph should be federated across multiple teams.
There should be a single source of truth for registering and tracking the graph.
The schema should act as an abstraction layer that provides flexibility to consumers while hiding service implementation details.
The schema should be built incrementally based on actual requirements and evolve smoothly over time.
Performance management should be a continuous, data-driven process, adapting smoothly to changing query loads and service implementations.
Developers should be equipped with rich awareness of the graph throughout the entire development process.
Grant access to the graph on a per-client basis, and manage what and how clients can access it.
Capture structured logs of all graph operations and leverage them as the primary tool for understanding graph usage.
Adopt a layered architecture with data graph functionality broken into a separate tier rather than baked into every service.