06API Design

GraphQL vs REST in practice

Same data requirements, different approaches. Select the tabs below to trigger real, rate-limited requests against a live Hot Chocolate (.NET) GraphQL server and observe the differences in payload size and round trips.

REST· classic resource endpoints
GET /api/... HTTP/1.1
Accept: application/json

click a tab above to fire the request

GraphQL· single endpoint, shaped query
POST /graphql HTTP/1.1
Content-Type: application/json
query {
  user(id: 94) {
    id
    name
    email
    avatar
    bio
    location
    createdAt
    lastLogin
    preferences {
      theme
      language
    }
    stats {
      posts
      followers
    }
  }
}

click a tab above to fire the request

“Symmetric case: when the client needs the full resource, both approaches perform similarly. The GraphQL 'data' envelope adds a negligible overhead.”

Things GraphQL doesn't fix for free

  • Caching is harder

    REST gets HTTP caching for free — URL + verb is the cache key. GraphQL needs a persisted-query layer or a client cache like Apollo/Relay to get close.

  • N+1 lives on the server now

    The waterfall moved from the network to your resolvers. Without DataLoader-style batching, one query can trigger dozens of database calls.

  • Schema is a contract

    Every field is a public API. Deprecation, versioning, and access control need real thought from day one, not when something breaks.

Stack

Hot Chocolate.NET 10Apollo ClientReact 19TypeScriptInMemoryCacheuseQuery / useMutationResult PatternSchema-first typingRate Limiting