GraphQL and REST: compare needs, costs and access controls

Understand the request and its cost

This example uses a fictional schema: customer, orders and total must exist in the actual API. One request can aggregate data while triggering several server-side reads. REST can also provide tailored responses. A single HTTP endpoint is common in GraphQL, rather than mandatory for every architecture.

query RecentOrders($id: ID!) {
  customer(id: $id) {
    name
    orders(first: 5) {
      nodes { id total }
    }
  }
}

Compare a representative task

• Measure bytes, latency, errors and server work for the same screen, permissions and realistic data volumes.
• Check pagination, batched reads to limit N+1 behavior, caching strategy and isolation between accounts.
• Assess schema evolution, compatibility with older clients, observability and operating effort. Retaining REST may be the simpler choice.

Enforce rights and workload limits

Authenticate requests, then authorize objects and fields in business logic. Bound list sizes, depth, aliases, batched operations and estimated cost; request frequency alone does not describe workload. Hiding introspection does not replace these controls. Test denied access and partial responses too.

Primary references

• GraphQL — Learn [EN]
• GraphQL — Performance [EN]
• GraphQL — Security [EN]