About GraphQL vs REST

When each wins, and the hidden costs of GraphQL at scale. Part of the DevTools Surf developer suite. Browse more tools in the Info / Guides collection.

Use Cases

• Architects deciding between GraphQL and REST for a new API layer
• Mobile developers evaluating GraphQL to reduce over-fetching on slow networks
• Teams with existing REST APIs considering a partial GraphQL migration
• CTOs assessing long-term maintenance costs of GraphQL at scale

Tips

• Read the 'when each wins' section to match your project's needs
• Check the hidden costs analysis before choosing GraphQL for a new API
• Compare the data fetching patterns for mobile vs web clients

Fun Facts

• GraphQL was developed internally at Facebook in 2012 by Lee Byron, Nick Schrock, and Dan Schafer, originally to power the Facebook mobile news feed.
• Facebook open-sourced GraphQL in 2015 and transferred governance to the GraphQL Foundation (under the Linux Foundation) in 2018.
• The N+1 query problem is GraphQL's most common performance trap — tools like DataLoader (created by Facebook in 2016) were built specifically to solve it.

FAQ

When does GraphQL win?

Mobile clients that want specific fields, aggregating many backend services, or when frontend teams need type-safe contracts with autocomplete.

When does REST win?

Simple CRUD on resources, public APIs used by many consumers, cacheable reads (REST + HTTP caching is excellent), or when the backend team is small.

What are GraphQL's hidden costs?

N+1 queries without DataLoader, complex authorization at field level, query complexity analysis to prevent abuse, and frontend overfetching when devs aren't careful.

Can I use both?

Yes — many teams have REST for public API and GraphQL for internal. Tailoring the interface to the consumer is often the right call.