GraphQL is quickly becoming the preferred approach for working with APIs. It is a query language for APIs, and is designed to give users more insight and understanding into the data inside their APIs.

According to GraphQL platform provider Apollo, it’s also so much more than 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,” the company wrote.

RELATED CONTENT: How GraphQL is competing with REST

While GraphQL itself is an open-source project, this week’s SD Times featured project looks at Principled GraphQL: a set of best practices for implementing and scaling GraphQL. Principled GraphQL provides 10 best practices split into three focus areas: integrity, agility, and operations.

According the project, the 10 principles are:

  1. One graph: There should only be one unified graph for your company. Each team should not have multiple graphs
  2. Federated implementation: The implementation of that one graph should be dedicated across multiple teams
  3. Track the schema in a registry: Organizations should have a single source of truth of registering and tracking the graph
  4. Abstract, demand-oriented schema: The schema should act as the abstraction layer
  5. Using an Agile approach to schema development: The schema should be built incrementally and based on actual requirements
  6. Iteratively improve performance: Performance management should be a continuous, data-driven and adaptive process
  7. Use graph metadata to empower developers: Developers should be provided with information about the graph throughout the entire development process
  8. Access and demand control: This should be on a per-client basis and you should be able to manage what the client can access
  9. Structured logging: This should be used as a tool for understanding graph usage
  10. Separate the GraphQL Layer from the Service Layer: Instead of baking in layers at every service, you should adopt a layered architecture with graph data functionality broken into tiers